Узнайте, как создавать чистые, быстрые и простые в обслуживании компоненты React.

Я знаю — это цель каждого программиста (по крайней мере, я на это надеюсь).

И, на мой взгляд, это умение отличает хорошего программиста от превосходного программиста.

Самое приятное то, что он никогда не заканчивается по-настоящему, потому что всегда есть что-то новое, что можно изучить и улучшить.

Следование этим советам может упростить жизнь не только вам, но и вашим товарищам по команде.

Я видел, как команды разработчиков разрабатывают руководство по стилю, в котором они устанавливают ключевые принципы написания кода.

Если вы спросите меня, это блестящая концепция.

Среди них были:

  • использовать функциональные компоненты (например, стрелочные функции)
  • Не следует использовать встроенные стили.
  • сохранить хорошую структуру импорта (сначала импорт третьих сторон, затем внутренний импорт)
  • Перед фиксацией кода отформатируйте его.

И тому подобное.

Конечно, вы могли бы подробно рассказать об этом. Это решает ваша команда.

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

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

Я считаю, что это значительно улучшает командную работу и производительность.

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

Устраивайтесь поудобнее, найдите что-нибудь для заметок и получайте удовольствие!

Создайте эффективную структуру папок.

Сопровождаемость и гибкость требуют от вас структурирования файлов и каталогов в приложении React.

Правильная структура папок зависит от сложности вашего приложения и размера вашей команды.

В результате окончательного решения нет.

Тем более, что это широко спорный момент, который также зависит от личных вкусов.

Однако со временем были разработаны некоторые лучшие советы для разных размеров программного обеспечения.

Этот выдающийся пост в блоге охватывает 5 различных размеров приложений и предлагает полезные советы по организации ваших файлов и папок.

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

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

Ведение структурированного заказа на импорт

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

Они также могут быть перепутаны с внешним импортом сторонних пакетов и внутренним импортом, таким как другие компоненты, служебные функции, стили и многое другое.

Пример из реального мира (вырезано):

Вы, несомненно, в курсе того, что здесь происходит.

Различить сторонний и местный (внутренний) импорт сложно.

Они не организованы и кажутся распределенными.

Улучшенная версия:

Структура более гладкая, и намного проще разграничить внешний и внутренний импорт.

Конечно, вы можете улучшить его, используя больше именованных импортов (если это возможно! :)).

Это позволяет вам импортировать все компоненты из material-ui в одну строку.

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

Внутренний → Внешний (модули сторонних узлов) → Встроенный (например, реагировать).

Вы можете делать это каждый раз самостоятельно или нанять линтера.

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

Исследуйте шаблоны компонентов более высокого уровня.

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

Но это не все.

Понимание различных шаблонов является отличной отправной точкой.

Но самым важным аспектом является то, что вы понимаете, когда какой шаблон использовать для какой ситуации.

У каждого шаблона есть определенная цель.

Например, шаблон составного компонента позволяет избежать ненужного просверливания множества уровней компонентов.

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

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

Есть много разных мнений о том, хорошо это или плохо.

Если я начинаю передавать реквизиты более чем через два уровня компонентов, я пытаюсь придумать лучший способ/шаблон.

Правда повышает эффективность разработки и делает разрабатываемые компоненты более надежными и гибкими.

Наличие таких шаблонов в вашем наборе инструментов отделяет вас от других разработчиков React.

Я настоятельно советую вам провести исследование, но этот курс Udemy был весьма полезен для меня.

Используйте линтер и следуйте его инструкциям.

Линтер может помочь вам не только в сохранении ваших зависимостей в уникальном порядке импорта.

Обычно это помогает вам создавать лучший код.

ESLint полностью настроен, когда вы используете приложение create-react-app, но вы также можете создать его полностью самостоятельно или расширить правила, которые были до правила.

Линтер проверяет код JavaScript, который вы пишете, и предупреждает вас об ошибках, которые вы, скорее всего, увидите, если запустите код.

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

Одно дело иметь линтер, но совсем другое — следовать его указаниям.

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

Могут быть ситуации, когда это имеет смысл, но, по моему опыту, они крайне редки.

Еще одним важным преимуществом является возможность настройки средств проверки стиля. Это очень полезно для команд.

Вы можете легко комбинировать ESLint с чем-то вроде JSPrettify, если вы договорились о некоторых рекомендациях о том, как вы пишете свой код и как он должен быть структурирован.

Протестируйте свой код.

Я понимаю, что тестирование, вероятно, не ваше любимое занятие как разработчика.

Таким я был раньше.

Поначалу это казалось бесполезным и болезненным занятием.

Это может быть правдой в краткосрочной перспективе. Но в долгосрочной перспективе — особенно по мере расширения приложения — это важно.

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

В ручном тестировании людьми нет ничего плохого, и его не следует полностью избегать.

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

Это может занять много времени и привести к ошибкам.

Вы уже думаете о том, как структурировать свой код, чтобы пройти этот тест, пока разрабатываете тесты.

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

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

Например: «Что должен делать этот конкретный компонент? Какие важные пограничные случаи могут возникнуть, которые я должен проверить? Могу ли я очистить компонент так, чтобы он служил только одной цели? …”

Наличие видения кода, который вы собираетесь создать, также поможет вам сосредоточиться на реализации этого видения.

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

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

При правильной настройке это может сэкономить ваше время и усилия в будущем.

Изучите раздел Тестирование в документации React, посмотрите несколько руководств по тестированию в React и просто начните писать свое первое небольшое TDD-приложение или добавляйте тесты в приложение, над которым вы сейчас работаете.

Следует использовать машинописный текст (или использовать реквизиты и типы реквизитов по умолчанию)

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

Затем нам пришлось построить проект клиента поверх него, а Typescript уже был встроен.

У меня и моих товарищей по команде не было опыта работы с TypeScript, потому что мы все пришли из ванильного JavaScript.

После нескольких недель работы над этим проектом мы решили, что TypeScript — это не преимущество, а скорее бремя для нашего рабочего процесса.

Мы также не получали всех преимуществ, потому что мы определили все с типом any для подавления предупреждений Typescript.

В результате мы решили удалить TypeScript из проекта и придерживаться нашего проверенного ванильного JavaScript.

Сначала это работало гладко, но по мере того, как наш проект усложнялся, появлялось больше ошибок.

Поэтому мы сомневались в своем решении полностью отказаться от TypeScript.

Но такие ситуации случаются и дают нам важный опыт на будущее.

Этот сценарий вдохновил меня на обзор TypeScript, который я изучал в свободное время.

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

TypeScript имеет много преимуществ, таких как статическая проверка типов, улучшенное завершение кода в вашей среде IDE (IntelliSense), более удобный интерфейс для разработчиков и обнаружение ошибок типов при написании кода — и это лишь некоторые из них.

С другой стороны, это может вызвать некоторые трудности, потому что, если вы не знакомы с языками с жесткой типизацией (такими как Java или C#), поначалу это может быть трудно понять.

Но я могу сказать, что изучение и применение этого стоит затраченных усилий.

Вот хорошая статья, которая предоставит вам обзор преимуществ и недостатков использования Typescript в приложениях React.

А вот руководство по написанию кода TypeScript для ваших приложений React.

Могут быть причины, по которым вы не хотите использовать TypeScript в своем проекте React.

Используйте ленивую загрузку и разделение кода.

Если вы провели какое-то время в мире JavaScript и React, вы, скорее всего, сталкивались с концепцией объединения.

Для тех из вас, кто впервые слышит это слово, вот что говорится в официальной документации React:

Большинство проектов React будут использовать такие инструменты, как Webpack, Rollup или Browserify, для «объединения» своих файлов.

Объединение — это процесс отслеживания импортированных файлов и объединения их в один файл: «пакет».

Затем этот пакет можно связать с веб-страницей, чтобы сразу загрузить полное приложение.

По сути, это фантастическая стратегия, но когда ваше приложение расширится, это вызовет проблемы.

Ваш пакет также начинает расти.

Особенно при использовании больших сторонних библиотек, таких как three.js.

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

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

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

Наиболее популярные упаковщики, такие как Webpack, Rollup и Browserify, поддерживают это.

Тот факт, что вы можете создавать различные пакеты и загружать их динамически, является огромным преимуществом.

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

В этом случае вы не покупаете весь магазин, а затем выбираете из него бананы, яблоки и хлеб.

Вас интересует только часть диапазона. Так зачем же все покупать?

Это заняло бы гораздо больше времени и обошлось бы намного дороже.

Я считаю, что важно знать о потенциальных проблемах, которые могут возникнуть по мере расширения вашего приложения, и о том, что существуют способы решения таких проблем.

Ознакомьтесь с документацией React для получения дополнительной информации.

Организуйте многократно используемую логику в настраиваемые хуки

Согласно документации React,

Хуки позволяют нам повторно использовать код с отслеживанием состояния без необходимости менять форму.

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

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

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

Вы оборачиваете в него логику, и вам нужно только вызвать хук как функцию в ваших компонентах.

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

const ScreenDimensions = () => {
  const [windowSize, setWindowSize] = useState({
    width: undefined,
    height: undefined,
  });
  
  useEffect(() => {
    function handleResize() {
      setWindowSize({
        width: window.innerWidth,
        height: window.innerHeight,
      });
    }
    window.addEventListener('resize', handleResize);
    handleResize();
    return () => window.removeEventListener('resize', handleResize);
  }, []);
  
  return (
   <>
     <p>Current screen width: {windowSize.width}</p>
        <p>Current screen height: {windowSize.height}</p>
    </>
  )
}

Как видите, решение довольно простое, и нет ничего плохого в том, чтобы определить его таким образом.

Теперь самое сложное.

Представьте, что мы хотели бы использовать точную логику в другом компоненте, где мы будем отображать другой пользовательский интерфейс (один для смартфонов и один для настольных компьютеров) в зависимости от текущего размера экрана.

Конечно, мы могли бы просто скопировать логику, вставить ее, и все готово.

Но это не очень хороший совет, как вы могли знать из принципа DRY.

Если мы хотим изменить нашу логику, мы должны сделать это в обоих компонентах.

А когда мы вставляем нашу логику в еще большее количество компонентов, она становится менее удобной в сопровождении и более подверженной ошибкам.

Итак, что бы вы обычно делали в ванильном проекте JavaScript?

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

Это именно то, чего мы добьемся с помощью хуков.

Это не что иное, как функции JavaScript, но с некоторыми особенностями React, потому что они используют хуки React.

Итак, что бы вы сделали в типичном проекте JavaScript?

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

Именно это мы и будем делать с помощью хуков.

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

Давайте посмотрим на наш уникальный хук:

const useWindowSize = () => {
  const [windowSize, setWindowSize] = useState({
    width: undefined,
    height: undefined,
  });
  
  useEffect(() => {
    function handleResize() {
      setWindowSize({
        width: window.innerWidth,
        height: window.innerHeight,
      });
    }
    window.addEventListener('resize', handleResize);
    handleResize();
    return () => window.removeEventListener('resize', handleResize);
  }, []);
  
  return windowSize;
}

Давайте просто назовем это внутри нашего компонента ScreenDimensions:

const ScreenDimensions = () => {
  const windowSize = useWindowSize()
  
  return (
   <>
     <p>Current screen width: {windowSize.width}</p>
        <p>Current screen height: {windowSize.height}</p>
    </>
  )
}

Это позволяет нам просто вызывать пользовательский хук из любого другого компонента и сохранять возвращаемое значение (текущий размер окна) в переменной, которую мы можем использовать внутри компонента.

const ResponsiveView = () => {
  const windowSize = useWindowSize()
  
  return (
   <>
     {windowSize.width <= 960 ? (
          <SmartphoneView />
        ) : (
          <DesktopView /> 
        )}
    </>
  )
}

Правильно обрабатывать ошибки.

Многие разработчики игнорируют и недооценивают важность обработки ошибок.

Это кажется ошибкой с самого начала, как и многие другие лучшие советы.

Вы хотите, чтобы код работал, и не хотите «тратить» время на размышления об ошибках.

Однако по мере того, как вы набираете опыт и видите ситуации, в которых лучшая обработка ошибок могла бы сэкономить вам много энергии (и драгоценного времени), вы понимаете, что наличие надежной обработки ошибок внутри вашего приложения важно в долгосрочной перспективе.

Особенно когда приложение в сервисе.

Но что означает обработка ошибок в мире React? Есть несколько частей, которые играют роль.

Один из них — отлавливать ошибки, другой — правильно обрабатывать пользовательский интерфейс, а третий — правильно сообщать о них.

Заключительные слова

Это было очень весело, не так ли?

Я изо всех сил старался выбросить из своих мыслей все, что накопилось за это время.

Моя цель при написании этого поста — поделиться с вами своим опытом, чтобы помочь вам избежать сложных моментов во время обучения и прогресса React.

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

Я хотел бы услышать все, что вы считаете нужным добавить в этот пост.

Помните, что речь всегда идет об изменении того, что полезно для вас.

Поэтому не принимайте вещи как должное, а подумайте, что может быть полезно в вашей ситуации.

Тогда просто добавьте его в свой список лучших советов.

Вы также можете подписаться на меня на Medium.

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

Так что определенно не стесняйтесь говорить со мной.