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

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

Разработка программного обеспечения достаточно сложна, пожалуйста, не усложняйте себе задачу.

Вместо этого работайте с умом, с этими пятью советами, которые спасут вас в любой среде — независимо от того, являетесь ли вы: индивидуальным разработчиком, работающим над личными проектами, хаотичным «нам нужны рок-звезды!» стартап или компания с несколькими разрозненными командами, работающими над монорепозиторием.

Спойлер:"Используйте TypeScript!" сюда не входит, но если вы цените свое здравомыслие, учтите, что это по умолчанию правило, когда вы готовы отказаться от приложений ToDo.

1. Используйте Bit, чтобы в полной мере воспользоваться возможностью компоновки компонентов React

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

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

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

«Это еще одна библиотека пользовательского интерфейса?»

Нисколько!

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

2. Используйте дизайн-систему

Быстрый вопрос: если ваши веб-сайты/веб-приложения теперь будут просматривать тысячи пользователей, а не сотни, что вам нужно больше: самый эффектный CSS и самая гладкая анимация или дизайн, который можно поддерживать? повторяется постепенно и легко отлаживается?

Хитрый вопрос. Эти две цели не исключают друг друга.

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

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

Если вы используете Bit, создание тем с токенами дизайна становится еще проще. Вы можете просто взять один из многих компонентов тем, которые используют шаблон Provider (собственный ThemeProvider с открытым исходным кодом Team Bit достаточно хорош), чтобы создать контекстно-зависимую тему, используя только токены дизайна в качестве входных данных, предоставить ее всепоглощающему компоненты, заключая их в Provider, и вуаля, у вас есть система тем для всего приложения, в которой темы поддерживают горячую замену.

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

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

Если вы используете такую ​​библиотеку, как SWR или react-query, делайте то же самое, на этот раз для каждого запроса.

Это делает ваши сетевые запросы модульными, гарантируя, что они будут простой заменой, если вы когда-нибудь решите изменить библиотеки HTTP (от простых axios/fetch до response-query, RTK и т. д.). ).

💡 Еще лучше то, что вы можете поделиться ими с Bit, чтобы другие могли использовать ваши хуки через диспетчер пакетов по своему выбору.

4. Не управляйте состоянием, которым вы не должны управлять

Чтобы понять этот момент, спросите себя, что такое «состояние» React. Просто данные, описывающие текущее состояние системы, верно? Это означает, что, вообще говоря, может быть два разных вида состояния.

  1. Данные, которые вы создаете и генерируете самостоятельно для описания внутреннего устройства вашего приложения — логическое значение, которое отслеживает, открыто ли модальное окно или боковая панель, объекты для несохраненных данных формы и т. д.
  2. Данные, которые вы извлекаете асинхронно через API (их больше, но давайте пока ограничимся этим определением), которые описывают внутреннее состояние сервера или базы данных, из которой вы их извлекаете. Вы всего лишь заимствуете эти данные и, возможно, даже не видите их самую последнюю версию, поскольку за это время она могла быть изменена другими.

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

Пример сценария: получение списка задач с вашего сервера и предоставление пользователю возможности обновить/удалить/пометить их как завершенные в пользовательском интерфейсе. Чего выне должны делать, так это управлять извлеченными данными с помощью запросов GET/POST к серверу при каждой отдельной операции, что было бы невероятно медленным и вводило бы все ошибки и непреднамеренное поведение.

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

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

💡 Для управления состоянием клиента вы хотите использовать хуки React useState/useReducer на уровне компонентов и Context API (совет для профессионалов: придерживайтесь этого для значений, которые в основном являются статическими) или третий- библиотека управления партийным состоянием, такая как Zustand или Redux на уровне приложения. Для управления состоянием сервера/кэшем используйте такие библиотеки, как SWR, apollo или react-query.

5. Оптимизированная структура проекта — ключ к успеху

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

  1. Структура файлов/папок, позволяющая мгновенно просматривать кодовую базу для любого, кто хочет взглянуть на код, будь то новый сотрудник или опытный разработчик. Один из подходов состоит в том, чтобы организовать компоненты по функциям, а не просто сбрасывать их кучу в общий каталог «компоненты».
  2. Достаточно очевидные и интуитивно понятные соглашения о коде, поэтому всем, кто работает над вашим проектом, даже не придется читать руководство, чтобы начать работу. Вот почему TypeScript позволяет так легко работать над программным обеспечением, например, в команде. Код сам по себе становится вашей документацией.
  3. Структура кодовой базы, которую легко понять и создать локально во время разработки. Вот почему архитектура монорепозитория с несколькими пакетами является отличной отправной точкой (если ваш API не является общедоступным), поэтому у вас есть все вышеперечисленное. плюс общие типы, общие библиотеки и преимущество одного запроса на извлечение для каждой функции. Кроме того, когда каждая функция абстрагируется в свою независимую вещь и пакет, ваш импорт становится более понятным с первого взгляда: import { Component } from ‘@project/ui/thing’ вместо import { Component } from ‘../../../components/thing’.
  4. Код, оптимизированный для рефакторинга. Не стремитесь к идеальному коду, который никогда не дает сбоев. Вместо этого создавайте более надежные системы безопасности на случай неудачных сбоев. Пишите код, который не связывает зависимости и логику настолько тесно, что фактически прибивает их к полу, превращая даже мысль о рефакторинге в кошмар.

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

«Совершенство — враг хорошего»

Сегодня мы много говорили о подводных камнях, с которыми вы столкнетесь при масштабировании проектов, но TL;DR по мере расширения вашего приложения просто таковы:

Перестаньте думать о проектах как о тесно связанных монолитах, а вместо этого думайте о них как о комбинации независимых строительных блоков, которые имеют свой собственный набор функций, которые затем можно спроектировать вместе интуитивно понятным и легко модифицируемым способом. Это то мышление, которое продвигает Bit, превращая веб-разработку в игру с Lego.

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