5 главных уроков, извлеченных при создании приложений React

Недавно я выступил на конференции с докладом «Уроки, которые я извлек при создании приложений React». Я подумал, что это хорошая беседа, которую нужно задокументировать как сообщение в блоге. Итак, мы здесь.

В этом посте я расскажу о своих 5 лучших уроках по созданию приложений React за последние годы. Давайте сразу приступим.

Урок 1: Используйте функциональные компоненты

Компоненты классов в React — это история прошлого. Компоненты класса сбивают с толку людей и машины. Вот мои основные причины, почему вы должны начать использовать функциональные компоненты для своих приложений React.

Почему функциональные компоненты?

• Легче учиться и писать.
• Меньше кода.
• Легче поддерживать и тестировать.
• Наличие хуков внутри функциональных компонентов.

Hook — это специальная функция, которая позволяет вам подключаться к функциям React внутри функциональных компонентов.

Поэтому, если вы только начинаете изучать React, вам не нужно беспокоиться о компонентах класса. Вы можете напрямую изучить функциональные компоненты. Если у вас уже есть приложение React, просто убедитесь, что в дальнейшем вы пишете свои новые компоненты как функциональные компоненты.

Примечание. Имейте в виду, что React по-прежнему поддерживает компоненты класса, поэтому вам не нужно переписывать компоненты класса в функциональные компоненты.

import React, { useState } from "react";
const YesNoButtonComponent = () => {
  const [button, setButton] = useState("");
  const onButtonPress = (buttonName) => {
    setButton(buttonName);
    console.log(buttonName);
  };
  return (
    <div>
      <button onClick={() => onButtonPress("Yes")}>Yes</button>
      <button onClick={() => onButtonPress("No")}>No</button>
     </div>
  );
};

В приведенном выше примере вы можете увидеть функциональный компонент React в действии, используя хук useState!

Будущее React — за функциональными компонентами!

Урок 2: Разбирайте компоненты — когда это необходимо!

Каждый компонент представляет собой строительный блок, который является многократно используемой частью пользовательского интерфейса. Если сложить их все вместе, получится полноценное приложение.

Вот простая стратегия, которой я следую, когда мне нужно разбить компоненты внутри приложения.

Когда я разбираю компоненты?

• Управление состоянием становится кошмаром!
• Проблемы с производительностью при повторном рендеринге компонента или приложения.
• Читабельность кода страдает.
• Работа с несколькими разработчиками над кодовой базой становится сложной задачей.
• Тестировать компонент сложнее.

Если вы столкнулись с какой-либо из перечисленных выше проблем, рекомендуется начать разбивать компонент на более мелкие компоненты. Не существует жесткого правила относительно того, насколько большим или маленьким должен быть ваш компонент React. Если вы заметили какую-либо из вышеперечисленных проблем, это предупреждающий знак о том, что компонент должен быть меньше.

Урок 3: TypeScript спасает жизнь!

В последний год или около того я переключил свои проекты на TypeScript. Тогда я не осознавал, насколько улучшится мой опыт разработчика с этим переключателем.

Вот несколько главных причин, по которым я считаю, что TypeScript спасает жизнь:

• Выявляйте проблемы на ранней стадии во время компиляции.
• Intellisense является точным.
• Легче рефакторить код.
• Читаемый код.
• Легче поддерживать и тестировать.
• Качественная документация с TSDoc.

type HeadingProps = {
  title: string;
  bold: boolean;
}
export const Heading = ({ title, bold }: HeadingProps) => {
  return (
    <div>
      {bold ? "Bold Title: " : "Regular Title: "}
      {title}
    </div>
  );
};

В приведенном выше примере вы можете увидеть TypeScript в действии. Компонент Heading принимает реквизиты title и жирный шрифт типа HeadingProps. В любое время мы вызовите компонент Heading, мы должны будем передать ему все реквизиты с соответствующими типами. Ваша IDE выдаст ошибку, если вы пропустите prop или передадите prop неправильного типа, как показано ниже.

Это довольно круто при разработке компонентов React, чтобы получать мгновенную обратную связь во время кодирования.

Урок 4: Начните с локального состояния!

Часто, когда запускаются проекты React, разработчики сразу думают, что им как-то нужна внешняя библиотека управления состоянием. Нередко команды настраивают Redux/MobX/XState или аналогичные библиотеки, когда начинают создавать приложение React.

Я бы рекомендовал начать с локального состояния для вашего приложения React и принимать решения по управлению состоянием по мере роста вашего приложения. Часто вашему приложению действительно не нужны сложные решения для управления состоянием. Так зачем привозить всю добавленную массу библиотек, если от них можно избавиться?

Вот рабочий процесс, которому вы можете следовать, пока ваше приложение растет:

1. Сначала начните с локального состояния: когда вы начинаете создавать приложение, сохраняйте состояние локальным для каждого компонента. И этого может быть достаточно в большинстве случаев, и вы можете использовать хук useState для управления состоянием.

2. Передача состояния через реквизиты: если дочернему компоненту требуется доступ к состоянию от родителя, его можно передать через реквизиты от родительского к дочернему компоненту.

3. Поднимите состояние вверх: могут быть ситуации, когда компоненту, не являющемуся дочерним, требуется доступ к данным из другого компонента. В этом сценарии можно использовать концепцию поднятия состояния вверх до общего родительского компонента.

4. Используйте контекст.Контекст предназначен для обмена данными, которые являются глобальными для дерева компонентов React. Если вы хотите избежать передачи определенных реквизитов через несколько уровней компонентов, используйте контекст. Контекст обычно используется для таких данных, как демографическая информация, тема и т. д., которые необходимы большинству компонентов.

5. Если всего вышеперечисленного недостаточно, используйте внешнее управление состоянием:Если вы испробовали все вышеперечисленные методы, а состояние вашего приложения все еще растет, и вы считаете, что использование внешнего управления состоянием может принести пользу решение; затем пойти на это. Существует множество опций, таких как Redux, MobX, XState и т. д., которые вы можете добавить в свое приложение.

Урок 5: Тестируйте, тестируйте и еще раз тестируйте!

И последнее, но не менее важное: протестируйте свой код! После того, как вы будете следовать всем другим рекомендациям в React, ваш код будет легко тестировать. Существуют различные типы тестирования, которые вы можете проводить с вашим приложением React, и я рекомендую их все.

Модульные тесты

Jest — самый популярный фреймворк для модульных тестов. Существуют и другие фреймворки, такие как Mocha, которые вы можете использовать. Модульное тестирование — это самая простая форма тестирования, позволяющая тестировать наименьшие единицы кода.

Тесты компонентов

Все в React является компонентом и следует подходу, основанному на компонентах. Ваши компоненты представляют собой отдельные многоразовые блоки, которые можно эффективно тестировать. Эта форма тестирования очень важна в React.

Библиотека тестирования React Кента С. Додда — это легкое решение для тестирования компонентов React. Он предоставляет простые утилиты для тестирования React DOM, которые поощряют передовой опыт тестирования. Многие команды успешно тестировали свои компоненты с помощью этой библиотеки. Проверьте это, если вы этого не сделали.

Автоматизированные сквозные тесты

Этот тип тестирования в основном проверяет приложение в целом. Он имитирует, как пользователь будет щелкать приложение и тестировать его в браузере. Самый популярный и простой в использовании фреймворк для сквозного тестирования JavaScript (или всего, что работает в браузере) — Cypress. Я использовал Cypress для тестирования интерфейсных приложений, и его установка и запуск очень просты. Это повлечет за собой тестирование в реалистичной среде браузера, и я настоятельно рекомендую включить эти тесты в ваше приложение React.

Заключение

Ну это накрутка! Надеюсь, вам понравилось читать эту статью об уроках, которые я усвоил, работая с React за эти годы. При разработке приложений React нет установленных правил. React сам по себе является гибкой библиотекой, дающей разработчикам свободу принимать решения. Со свободой приходит ответственность, и именно это делает React интересным для меня.

Если вам понравился этот пост, не забудьте поделиться им со своей сетью. Вы можете подписаться на меня в твиттере @AdhithiRavi, чтобы получать больше обновлений.

Эта статья изначально была опубликована на https://programmingwithmosh.com/

Ссылки:

• Когда разбивать компоненты — Кент Си Доддс
• Реакция мышления

Я автор, спикер и основатель Surya Consulting, Inc.

На своих курсах Pluralsight я обучил более 75 000 студентов таким темам, как React Native, GraphQL и Cypress.

Ссылка на мои курсы:

https://app.pluralsight.com/profile/author/adhithi-ravichandran