Начало проекта «с нуля» — это время, когда необходимо принять важные решения. Это может быть довольно сложной задачей, особенно если вы не знакомы с определенной технологией. Поэтому эта запись в блоге призвана помочь вам сделать правильный выбор, когда дело доходит до использования ReactJS для вашего пользовательского интерфейса.

ИСТОРИЯ

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

ПЕРВЫЕ ШАГИ

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

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

После некоторых исследований нам удалось сузить наш выбор до 2 из них:

Честно говоря, оба шаблона удовлетворяли наши потребности, но после тщательного рассмотрения мы решили использовать CRA, в основном из-за его долгосрочной поддержки. Его также довольно легко настроить и начать разработку. Тот факт, что Facebook постоянно обновляет шаблон и предоставляет доступ к новейшим функциям, которые может предложить ReactJS, также нельзя игнорировать. Тем более что обновления выходят достаточно часто и постоянно вносятся полезные улучшения.

АРХИТЕКТУРНЫЙ ВЫБОР

ReactJS сам по себе является просто библиотекой, отвечающей за отображение данных. Теперь нам нужно было погрузиться в возможные архитектурные варианты, которые мы могли бы использовать. Три основных варианта, которые мы могли бы сделать, основываясь на нашем предыдущем опыте и исследованиях, были следующими: 1. Redux 2. GraphQL 3. React Context API. комбинировать с ReactJS и даже друг с другом. За всеми ними стоит большое сообщество, поэтому любые проблемы, с которыми вы можете столкнуться, быстро решаются, а функционал постоянно улучшается и запускается. Лучшие практики, руководства, варианты использования и хорошие примеры доступны повсюду, поэтому даже с небольшим опытом вы сможете достичь своих целей. В нашем конкретном случае у нас был опыт работы с Redux, и мы были уверены, что сможем предоставить лучшее решение, используя подход, в котором мы компетентны. Почему мы не перешли на GraphQL? Несмотря на нашу очевидную тягу к новому и интересному, в данном конкретном случае мы решили придерживаться знакомого мира Redux и обеспечить качество при эффективном управлении временем. Я, однако, дам свои скромные мысли и рекомендации, как выбрать то, что лучше для вашего экземпляра.

1. РЕДУКС

Во-первых, Redux можно использовать с ReactJS, но этим дело не ограничивается — это универсальный паттерн, основанный на FLUX, который также можно использовать с Angular или другими интерфейсными фреймворками. Часть работы, которую выполняет Redux, заключается в том, чтобы быть контейнером управления состоянием или, проще говоря, — есть дерево объектов, называемое «хранилищем», которое позволяет вам обмениваться данными между всеми компонентами вашего приложения. У вас есть только один «магазин» или «единственный источник правды», что имеет некоторые преимущества. Но Redux не просто решает проблему управления состоянием, поскольку у React уже есть решение для этого. Он скорее вводит этот однонаправленный рабочий процесс, который упрощает отладку и проверку состояния приложения.Плюсы:

  • Повторное использование данных. Многие компоненты могут повторно использовать одни и те же наборы данных в разных модулях вашего приложения. Например, могут быть фиксированные наборы данных, такие как языки, страны, категории, которые редко меняются, или компоненты, которые могут быть изменены только в том случае, если изменение доступно.
  • Однонаправленный поток. Использование Redux обеспечивает один и тот же однонаправленный поток для всех данных в нашем приложении, что делает его более предсказуемым.
  • Умное структурирование данных. Распределяя все данные в нашем приложении, Redux заставляет нас тщательно структурировать наше хранилище данных и более разумно подходить к повторному использованию этих данных.
  • Журналирование и сохранение данных. «Единый источник достоверной информации» предоставляет такие преимущества, как упрощенное ведение журнала данных и событий или сохранение данных во всем приложении. Данные в хранилище неизменяемы и могут быть обновлены только с помощью чистых функций (действий).
  • Отладка с перемещением во времени. Позволяет записывать выполнение запущенного процесса, а затем воспроизводить его позже — как в прямом, так и в обратном направлении. Отладка с перемещением во времени (TTD) помогает нам легче отлаживать проблемы, позволяя нам «перематывать» сеанс отладчика, вместо того, чтобы воспроизводить проблему, пока мы не найдем ошибку. Это легко достигается с помощью расширений, доступных для основных браузеров.
  • Разделение ответственности — Redux также разделяет логику нашего приложения на действия, редьюсеры и хранилище. Это помогает нам придерживаться принципа единой ответственности.

Минусы:

  • Кривая обучения. Трудно сказать, какова кривая обучения Redux, поскольку она зависит от предыдущего опыта программиста. Концепцию не так сложно понять, но, как и все остальное в этой отрасли, после изучения теоретической части вы должны научиться печатать пальцами, чтобы действительно почувствовать, с чем вы имеете дело. Итак, я считаю, что быстро справиться с Redux может быть непросто, особенно если вы стремитесь к качеству.
  • Сложность. В конечном итоге вы можете использовать библиотеку, которая добавляет сложности и потребует дополнительной подготовки при разработке новой функции. Многие команды включают Redux без особой необходимости. Это довольно сложный конечный автомат, который полезен только в определенных случаях.

Вердикт: Правильное масштабирование с помощью Redux не является проблемой, если лучшие методы кодирования на любом языке применяются ко всем частям шаблона Redux — действию, создателям, редюсерам и хранилищу (структуре). Суть в том, что вам не нужно так сильно беспокоиться о масштабируемости, а не о том, чтобы ваш код был чистым и удобным в сопровождении, что само позаботится о масштабируемости.

2. ГРАФИКЛ

QL в названии означает язык запросов. GraphQL — это абстракция, которая стоит между клиентом и сервером (REST API). Он состоит из двух частей: реализация на клиенте, которая генерирует запрос, который позже преобразуется реализацией GraphQL на стороне сервера в понятные запросы в зависимости от того, откуда будут извлекаться данные (API .NET REST, MS SQL Server и т. д.). ). Основная идея заключается в том, что клиенту (в нашем случае ReactJS) вообще не нужно знать конечные точки API. Вместо этого ему предоставляется схема данных. Затем вы можете выполнять запросы к схеме, чтобы получить только те данные, которые вам нужны. Это означает, что API, который мы будем прятать за GraphQL, должен быть хорошо спроектирован. Теперь, если у вас нет опыта разработки таких API или вы новичок в GraphQL, с ограниченным временем для запуска вашего официального проекта, это может быть не предпочтительным вариантом. Всегда лучше иметь какой-то фиктивный/тестовый проект, который позволит вам сделать несколько ошибок и извлечь из них уроки.Плюсы:

  • Устранение распространенных проблем с REST API. Вы можете легко позаботиться о конечных точках, таких как /users/12/friends/workspace/colleagues, и упростить их до схемы данных.
  • Оптимизация производительности сети. Обычно при получении данных из API требуется несколько запросов https для сбора всех необходимых данных. Каждый из этих запросов имеет некоторую задержку до получения ответа, но с GraphQL у вас могут быть вложенные запросы, которые выполняются как пакет и возвращают в ответ только необходимые данные — ни больше, ни меньше.
  • Схема данных со строгой типизацией — GraphQL проверяет тип передаваемых параметров и пропускает неверный запрос. Это может показаться не таким уж большим преимуществом, но на один неверный запрос меньше нагрузки на сервер.
  • Слабая связь между клиентом и сервером. Вы можете заменить и клиент, и сервер, даже если они об этом не подозревают.
  • Оптимизация разработки — при использовании Redux вы должны создавать модифицированные действия, редукторы, затем фильтровать и преобразовывать только те данные, которые вам нужны из запроса. Принимая во внимание, что с GraphQL вы просто создаете запрос, который идеально соответствует тому, что вам нужно, в виде структурированных данных, и вам не нужно обходить решение, добавляя и изменяя различные файлы.
  • Обратная совместимость. В случае наличия новой версии приложения с другими конечными точками у вас не возникнет проблем с получением данных, запрошенных из ваших старых запросов.

Минусы:

  • Кэширование HTTPS не является вариантом — REST API был разработан с учетом преимуществ протокола https, в то время как GraphQL пропускает некоторые из этих преимуществ, например кэширование запросов GET.
  • Возможность раздувания сервера. Сервер GraphQL может легко раздуться, если его не поддерживать должным образом. Это, однако, может произойти и в обычном случае.
  • Шаблонный код — при добавлении без необходимости в Redux появляется много шаблонного кода.

Вердикт: ReactJS с GraphQL, вероятно, является самым новым и причудливым стеком, с которым вы можете работать в области ReactJS. Если вы стремитесь к масштабируемости и ремонтопригодности проекта в сочетании с более быстрой разработкой на стороне клиента, вам подойдет GraphQL. Вам не нужно знать документацию API, только те точные данные, которые вам нужны в соответствии со схемой запроса, ни больше, ни меньше. GraphQL мог бы объединить в себе несколько API-интерфейсов GraphQL, что заметно упростило бы работу фронтенд-разработчиков. И последнее, но не менее важное: у GraphQL есть большая среда с открытым исходным кодом, в которой постоянно растет сообщество.

3. РЕАКТИВНЫЙ КОНТЕКСТ API

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

  • Доступность. Контекст в основном используется, когда данные должны быть доступны многим компонентам на разных уровнях вложенности. Это то, для чего вы частично используете Redux.
  • Никаких дополнительных зависимостей. Он аккуратно решает ваши проблемы, поскольку отличается меньшим весом и более высоким уровнем производительности.
  • Простота внедрения. Это готовое и простое в тестировании решение для управления и обмена глобальным состоянием между несколькими компонентами.

Минусы:

  • Ограниченные функциональные возможности. Поскольку это самый простой строительный блок, когда дело доходит до управления данными, его API и возможности иногда считаются ограниченными по сравнению, скажем, с Redux.
  • Затрудненное повторное использование компонентов. Применяйте его с осторожностью, так как это затрудняет повторное использование компонентов, а чрезмерное использование может сделать код беспорядочным из-за глобального состояния.
  • Нет таких инструментов, как Redux. Следить за изменениями состояния проще с Redux из-за громоздкого и однонаправленного потока и инструментов, чего здесь нет.

Вердикт: контекст React не является заменой Redux. Он решает проблему с глобальным состоянием, но Redux не только в этом. Кроме того, они не исключают друг друга. Перейдите на следующий уровень с Redux или GraphQL, если то, что вы разрабатываете, становится неподдерживаемым при таком подходе.

ЗАКЛЮЧЕНИЕ

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

Одна из самых больших функций кода Redux — обрабатывать новые вызовы API и формировать новые данные определенным образом. Однако вам, вероятно, не нужна половина этого кода. В большинстве клиентских приложений GraphQL заменяет необходимость в библиотеках управления состоянием, поскольку он снижает сложность, уменьшает объем кода и формирует данные в соответствии с вашим пользовательским интерфейсом.

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

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

Что бы я посоветовал при принятии решения об архитектуре — просто KISS (будь проще, глупец)! Если вам понадобится дополнительная консультация, вы можете в любое время обратиться к нам, чтобы узнать, как мы можем оказать вам дальнейшую поддержку в построении перспективной архитектуры.