Уильям Хилл — старший инженер-программист в Meroxa с опытом работы в качестве инженера полного стека и инженера DevOps. Его опыт включает в себя создание приложений для экспертов в области нераспространения, климатологии и баскетбольной аналитики. Уильям является сторонником увеличения разнообразия в области вычислительной техники путем найма и обучения инженеров из недостаточно представленных групп.
Допустим, вы хотите проверить счет игры на ESPN.com. Вы нажимаете на поле счета, ожидая увидеть результаты для этой конкретной игры. Однако отображаемые данные относятся к другой игре.
Несоответствие между запрошенными данными и данными, отображаемыми на странице, может быть связано с неправильным управлением состоянием, которое не позволяет вашему приложению React синхронизировать состояние между несколькими компонентами. Чем больше растет ваше приложение, тем сложнее становится эффективно управлять глобальным состоянием.
В React есть несколько стратегий управления глобальным состоянием. Однако не все варианты созданы одинаковыми для каждого варианта использования. Выбор глобальной стратегии управления состоянием — важная, но сложная часть создания приложения. Независимо от того, работаете ли вы над новым проектом или рефакторингом приложения, вам необходимо взвесить компромиссы в отношении сложности, тестирования и инструментов.
Сегодня мы сосредоточимся на плюсах и минусах трех популярных стратегий управления глобальным состоянием для разработчиков React:
- Реагировать на контекст
- Редукс
- Отдача
Говоря словами паршивой овцы : вы можете получить с этим, или вы можете получить с тем. Выбор ваш. Эта статья вооружит вас знаниями, чтобы сделать этот выбор.
Мы рассмотрим:
- Реагировать на контекст
- Редукс
- Отдача
- Выбор стратегии: на практике
Реагировать на контекст
React Context — это комплексный подход к глобальному управлению состоянием. Он не требует использования каких-либо внешних зависимостей, поскольку является частью собственного API React.
Совместное использование состояния между компонентами и приложением React очень просто:
- Определите объект контекста.
- Оберните дерево компонентов поставщиком контекста.
Результат: все, что вложено в этот контекст, может получить доступ к данным внутри него.
Хотя контекстный API React может быть хорошим выбором для довольно простых приложений, в нем меньше оптимизаций для управления сложными фрагментами данных.
Контекст может хранить только одно значение, в отличие от неопределенного набора значений (каждое из которых имеет своих потребителей). Передача объекта в контекст обеспечивает некоторую гибкость для ограничения одного значения. Однако это может не решить ваши проблемы, поскольку ваше управление состоянием становится все более сложным.
Можно определить несколько контекстов, обертывающих дерево компонентов, но определение и использование нескольких контекстов может быстро запутаться. Кроме того, вы можете столкнуться с проблемами производительности по мере роста вашего приложения, поскольку контекст может вызывать частые и ненужные повторные рендеринги, поскольку все компоненты в дереве повторно рендерятся при изменении состояния.
При правильном использовании контекстный API React является мощным решением для управления состоянием, несмотря на его ограничения при работе с высокой частотой изменений состояния.
Плюсы контекста React
- Встроенная стратегия, не требующая внешних зависимостей
- Эффективен для относительно небольших приложений
Минусы контекста реакции
- Ограниченная способность управлять сложными фрагментами данных
Redux
Redux — это библиотека JavaScript с открытым исходным кодом, которая может интегрироваться с любой инфраструктурой пользовательского интерфейса. Несмотря на то, что Redux не был разработан специально для React, он является одним из самых популярных решений для управления состоянием React. Это потому, что Redux очень эффективен в управлении сложностью.
Redux хранит все глобальное состояние приложения в дереве объектов внутри одного хранилища. Действия, которые происходят в приложении, могут быть отправлены в магазин. Оттуда функция редуктора получает новое состояние приложения, используя предыдущее состояние и действие, которое было отправлено, как показано на этом рисунке потока приложения React-Redux:
Я думаю о Redux как о подходе к кухонной раковине. По мере того, как ваше приложение React требует все более сложных манипуляций с состоянием и управления, Redux может справиться со всем этим гораздо эффективнее, чем React Context. В то же время Redux усложняет кодовую базу и обслуживание кода. Это может означать крутую кривую обучения для разработчиков.
К счастью, у Redux большое сообщество и достаточно ресурсов для поддержки обучения разработчиков. Redux Toolkit может помочь вам справиться со многими проблемами, с которыми вы столкнетесь, предоставляя набор лучших практик.
Вопрос в том, стоит ли эта кривая обучения для вашего варианта использования. Вам нужна возможность управлять сложными фрагментами данных? Для относительно небольших и простых приложений библиотека Redux может оказаться излишней. Для крупных корпоративных приложений вы можете потратить дополнительное время на изучение и внедрение Redux.
Плюсы
- Эффективен при сложном управлении состоянием React
- Имеет полезные инструменты разработки для разработки и отладки
- Имеет возможность рендеринга на стороне сервера
Минусы
- Может иметь значительную кривую обучения
- Первоначальная настройка может быть сложной (хотя Redux Toolkit помогает упростить ее)
- Может иметь больше шаблонного кода, чем другие подходы
Recoil
Recoil — это экспериментальная библиотека управления состоянием, разработанная Meta (теми же людьми, которые разработали React). В результате API Recoil и стиль кодирования очень хорошо сочетаются с ядром React.
Recoil позволяет вам создать граф потока данных, который течет от атомов (общее состояние) через селекторы (чистые функции) и вниз к вашим компонентам React. Селекторы преобразуют это состояние синхронно или асинхронно. Определение состояния является инкрементным и распределенным, что делает возможным разделение кода.
В качестве продолжающегося мета-эксперимента Recoil находится на переднем крае решений для глобального управления состоянием. Однако его экспериментальный характер может быть и недостатком. Разработчики постоянно учитывают отзывы и корректируют методы и API Recoil. Это означает, что пользователи могут столкнуться с критическими изменениями. Кроме того, образовательные ресурсы для поддержки пользователей Recoil ограничены.
Плюсы
- Имеет аналогичный API для локального состояния React.
- Полезно, если у вас есть большое количество взаимозависимых компонентов
Минусы
- Нестабильный API из-за того, что он экспериментальный
- Не поддерживает промежуточное ПО
Выбор стратегии: на практике
Предыдущая компания, в которой я работал, использовала Redux в качестве стратегии управления состоянием. Я испытал эту вышеупомянутую кривую обучения на собственном опыте. Пока я разбирался в Redux, мы также вели беседы на высоком уровне об управлении глобальным состоянием. Должны ли мы использовать другой подход?
Мы начали с оценки того, почему мы использовали Redux в первую очередь. Отчасти причина в том, что мы использовали старую спецификацию React. В результате у нас не было доступа к хукам React, позволяющим использовать состояние и другие функции React без написания классов.
Ситуация изменилась, когда мы обновили нашу версию React и получили доступ к хукам React. Это открыло возможности помимо Redux. Наша команда обсудила компромиссы стратегий, которые мы рассмотрели сегодня.
React Context
Это может работать для нескольких изолированных частей нашего приложения React. Но в целом наше корпоративное приложение слишком сложное. Будет больше проблем, чем пользы, если обернуть наше дерево компонентов в несколько контекстов.
Recoil
Этот вариант привлекателен, потому что он находится на переднем крае и хорошо поддерживается Meta. Однако факт остается фактом: Recoil очень новый, поэтому в библиотеку часто вносятся изменения, которые могут привести к сбою нашего приложения. Стоит ли инновация, лежащая в основе Recoil, неизбежных кардинальных изменений?
Redux
Ориентация на то, как мы используем Redux, — это тяжелая работа. Однако эта стратегия надежна и позволяет нам эффективно управлять несколькими состояниями. Теперь, когда у нас есть возможность использовать подход, основанный на ловушках, мы можем изучить возможность отказа от Redux, чтобы упростить нашу кодовую базу. Но сейчас имеет смысл сосредоточиться на том, как мы можем использовать Redux более разумно.
Ключевым выводом из этого процесса является то, что выбор правильной стратегии управления глобальным состоянием начинается с понимания вашего варианта использования. Спроси себя:
- Какова сложность вашего приложения?
- Как это может измениться в будущем?
Не существует универсального решения для управления глобальным состоянием. Кроме того, стратегия, которая работает сегодня, может оказаться не лучшим выбором через полгода.
Вы можете получить с этим, или вы можете получить с тем. Выбор ваш. Компромиссы, которые мы здесь обсудили, основанные на глубоком знании вашего варианта использования, помогут вам сделать осознанный выбор.
