От автора: начиная новый проект React, всегда полезно составить несколько рекомендаций, которым вы и ваша команда будете следовать, чтобы сделать код масштабируемым. В этом посте я поделюсь с вами некоторыми идеями, полученными за годы использования React, которые помогут вам определить собственное руководство проекта.
Определите, как организовать состояние в локальном и глобальном состояниях
React — это библиотека, которая управляет пользовательским интерфейсом на основе его текущего состояния. Как разработчик, ваша задача — организовать, где хранить состояние, составляющее приложение. Некоторые разработчики предпочитают хранить каждую часть данных в хранилище redux, чтобы отслеживать все доступные состояния.
Но действительно ли вам нужно отправлять действие менеджеру состояний, чтобы открыть или закрыть простое раскрывающееся меню? И нужно ли другим частям приложения знать о значении контактной формы? Значения формы обычно недолговечны и используются только компонентом, который отображает форму.
Вместо того, чтобы использовать Redux для отслеживания каждого состояния внутри приложения, лучше сохранить какое-то состояние локальным, чтобы избежать чрезмерных затрат на разработку приложения. Как правило, вы можете задать следующие вопросы:
Остальным частям приложения нужны эти данные?
Вам нужно иметь возможность создавать дополнительные производные данные на основе этих исходных данных?
Используются ли одни и те же данные для управления несколькими компонентами?
Есть ли для вас ценность в возможности восстановить это состояние до заданного момента времени (например, отладка во времени)?
Вы хотите кэшировать данные (т. е. использовать то, что находится в состоянии, если оно уже есть, вместо повторного запроса)?
Вы хотите, чтобы эти данные были согласованными при горячей перезагрузке компонентов пользовательского интерфейса (которые могут потерять внутреннее состояние при замене)?
Компоненты, использующие локальные состояния, более независимы и предсказуемы.
Узнайте о преимуществах тестирования и сделайте это с самого начала
Суть написания тестов автоматизации заключается в том, что в определенный момент невозможно протестировать проект React вручную, не затрачивая значительного количества времени и ресурсов.
Начиная проект, очень легко оправдать пропуск написания тестового кода, потому что ваша кодовая база относительно мала. Если в приложении React есть только пять-десять компонентов, автоматизация написания действительно кажется рутинной работой без явной выгоды. Но когда у вас более пятидесяти компонентов и у вас есть несколько компонентов более высокого порядка, тестирование проекта вручную может занять целый день, и даже в этом случае могут незаметно закрасться ошибки.
Да, написание тестового кода поможет вам сделать его более модульным. Да, это поможет вам быстрее находить ошибки и защитит от сбоев в производственной среде. Но автоматическое тестирование в конечном итоге помогает развивать проект, когда ручное тестирование больше не может подтвердить, что код работает должным образом.
Но вы не можете сразу написать тестовый код, если не привыкли к этому. Вот почему нужно начинать с самого начала. Если вы не знаете, с чего начать, то начните с интеграционного теста, потому что самая важная часть тестирования — это проверка правильности совместной работы компонентов.
Используйте инструменты, которые помогут в масштабировании
Обычно вам не нужно добавлять много инструментов в проект React в начале приложения. Но поскольку мы говорим о масштабировании приложения React для большой кодовой базы, я бы сказал, что вам нужно использовать все инструменты, которые помогут вам.
Prettier и ESLint потребуются для обеспечения единообразия кода между членами команды и уменьшения синтаксических ошибок. Всегда полезно включать мощные служебные библиотеки, такие как React Router, date-fns и response-hook-form.
Добавление TypeScript и Redux может быть отложено до тех пор, пока ваше приложение не станет склонным к ошибкам ввода, а части приложения снова и снова потребуют одного и того же состояния, которое вам необходимо сделать глобально доступным.
Внедрение управления состоянием с самого начала не требуется, потому что React уже думает о том, как лучше всего управлять состоянием.
Bit (Github) для управления и совместного использования компонентов как независимых строительных блоков. Это означает, что вы тестируете и визуализируете каждый компонент изолированно. Это гарантирует, что впоследствии будет легче поддерживать и повторно использовать его.
Более того, при использовании Bit в проекте, Bit source управляет каждым компонентом независимо (наряду с SCM проекта), что означает, что компонент (совместно используемый Bit.dev) может поддерживаться полностью независимо от проекта (т. е. путем «импорта» компонента из Bit.dev, изменив его и «отправив» обратно в общую коллекцию)
Да, и вы также можете использовать Next.js вместо Create React App для запуска проекта.
Эти инструменты помогут вам поддерживать большую базу кода React, но имейте в виду, что каждый добавляемый инструмент будет повышать уровень сложности проекта. Пожалуйста, изучите все, прежде чем принимать решение о внедрении этого инструмента в свой стек.
Правильно организуйте файлы проекта
Один из лучших советов, которые я узнал по масштабированию приложения React, заключается в том, что систематизация файлов проекта и их правильное именование могут ускорить прогресс. Некоторые разработчики обычно пишут index.js в качестве основного файла в каталоге компонентов, например:
Организация компонентов с помощью index.js
Это кажется разумным, потому что когда вы импортируете компоненты в другие файлы, выражение становится просто таким:
import Button from '../components/Button';
Но подумайте, когда вы открываете их рядом в редакторе кода:
index.js везде
Честно говоря, все эти index.js кого угодно запутают. Но если вы переименуете эти файлы index.js в имя компонента, оператор импорта будет выглядеть немного некрасиво:
import Button from '../components/Button/Button';
Моя команда наконец остановилась на том, чтобы иметь и файл, названный на основе компонента, и файл index.js, который экспортирует компонент:
Добавление файла компонента рядом с index.js
Мы также помещаем CSS и файл модульного теста в каталог компонентов. Таким образом, каждый каталог компонентов может быть автономным компонентом.
Автономный компонент
Создайте свою библиотеку компонентов пользовательского интерфейса / логики
Не следует откладывать создание библиотеки компонентов до тех пора, когда ваш проект достигнет своих больших размеров. Вы можете постоянно обмениваться компонентами в процессе работы. Каждый раз, когда создается новый компонент, используйте Bit, чтобы отслеживать его и делиться с коллекцией компонентов вашей команды на Bit.dev или на собственном сервере.
Как упоминалось ранее, (действительно) независимые компоненты намного проще поддерживать, а когда они совместно используются и задокументированы, их намного проще использовать повторно.
Библиотека компонентов предназначена не только для компонентов пользовательского интерфейса. Логика тоже должна быть включена — в случае React, как кастомные хуки (по большому счету).
Заключение
Всегда помните, что создание приложения React в масштабе — сложная задача, требующая от вас принятия лучшего решения как для потребителей, так и для разработчиков. В конце концов, лучшая практика — это та, которая подходит и для ваших пользователей, и вашей команды.
Хотя вам всегда придется экспериментировать с инструментами и методами для масштабирования проекта React, я надеюсь, что советы, которыми я поделился выше, будут вам полезны.
Автор: Nathan Sebhastian
Источник: https://blog.bitsrc.io
Редакция: Команда webformyself.