React 16.3.0 был выпущен, и API контекста больше не является экспериментальной функцией. Дэн Абрамов (создатель Redux) написал хороший комментарий здесь об этом, но это было 2 года, когда контекст был еще экспериментальная функция.
Мой вопрос, по вашему мнению/опыт, когда следует использовать React Context Over React Redux и наоборот?
Поскольку Контекст больше не является экспериментальной функцией, и вы можете напрямую использовать Контекст в своем приложении и отлично подходит для передачи данных глубоко вложенным компонентам, для которых он предназначен.
Как писал Марк Ериксон в своем блоге:
Если вы используете Redux только для того, чтобы избежать передачи реквизита, контекст мог бы заменить Redux - но тогда вам, вероятно, не понадобилось Redux.
Контекст также не дает вам ничего подобного
Redux DevTools
, возможности отслеживать ваши обновления состояния,middleware
для добавления централизованной логики приложений и других мощных возможностей, которые позволяетRedux
.
Redux
намного мощнее и предоставляет большое количество функций, которые Context Api
не предоставляет, также как упоминалось как @danAbramov
React Redux использует контекст внутри, но он не раскрывает этот факт в публичном API. Поэтому вы должны чувствовать себя намного безопаснее, используя контекст с помощью React Redux, чем напрямую, потому что, если он изменится, бремя обновления кода будет на React Redux, а не на вас.
Его до Redux для фактического обновления его реализации, чтобы придерживаться новейшего контекстного API
Последний API-интерфейс Context может использоваться для приложений, где вы просто будете использовать Redux для передачи данных между компонентами, однако приложение, использующее централизованные данные и обрабатывающие API-запрос, в Action Action, использующие redux-thunk
или redux-saga
все равно нуждается в сокращении. Кроме того, у этого редукта есть другие библиотеки, такие как redux-persist
которые позволяют сохранять данные хранилища в localStorage и регидратироваться при обновлении, что API контекста по-прежнему не поддерживает.
Как отметил @dan_abramov в своем блоге, вам может не понадобиться Redux, у этого редукса есть полезное приложение, например
- Сохраняйте состояние в локальном хранилище, а затем загрузите его из коробки.
- Предварительно заполните состояние на сервере, отправьте его клиенту в формате HTML и загрузите его из коробки.
- Сериализуйте действия пользователя и присоедините их вместе с моментальным снимком состояния к автоматическим отчетам об ошибках, чтобы разработчики продукта
могут воспроизводить их, чтобы воспроизвести ошибки.- Передавайте объекты действия по сети для реализации совместной среды без существенных изменений в написании кода.
- Поддерживайте историю отмены или реализуйте оптимистичные мутации без существенных изменений в написании кода.
- Перемещение между историей состояния в процессе разработки и переоценкой текущего состояния из истории действий при изменении кода a la TDD.
- Обеспечьте возможности полного контроля и управления инструментами разработки, чтобы разработчики продуктов могли создавать собственные инструменты для своих
Программы.- Предоставляйте альтернативные интерфейсы при повторном использовании большей части бизнес-логики.
С этими многочисленными приложениями слишком скоро можно сказать, что Redux будет заменен новым API-интерфейсом контекста
Если вы используете Redux только для того, чтобы избежать передачи реквизита до глубоко вложенных компонентов, вы можете заменить Redux на API Context
. Это точно предназначено для этого варианта использования.
С другой стороны, если вы используете Redux для всего остального (имея предсказуемый контейнер состояний, обрабатывая логику вашего приложения за пределами ваших компонентов, сохраняя историю обновлений состояния, используя Redux DevTools, Redux Undo, Redux Persist, Redux Form, Redux Saga, Redux Logger и т.д.), Тогда нет абсолютно никакой причины заменять Redux на API Context
.
Рекомендации:
Единственными причинами использования Redux для меня являются:
Вам, вероятно, не нужен уровень косвенности для всего вашего приложения, поэтому прекрасно сочетать стили и использовать локальное состояние/контекст и Redux одновременно.
Я предпочитаю использовать redux с decux-thunk для создания вызовов API (также используя Axios) и отправки ответа на редукторы. Это чисто и легко понять.
Контекстный API очень специфичен для части реакции-редукта о том, как компоненты React подключены к магазину. Для этого реакция-редукция хороша. Но если вы хотите, поскольку Context официально поддерживается, вы можете использовать API контекста вместо response-redux.
Таким образом, вопрос должен быть Context API vs react-redux, а не Context API vs redux. Кроме того, вопрос немного упрям. Поскольку я знаком с реакцией-редукцией и использую ее во всех проектах, я буду продолжать ее использовать. (У меня нет стимула меняться).
Но если вы изучаете редукс только сегодня, и вы его нигде не использовали, стоит предоставить Context API выстрел и заменить response-redux своим пользовательским кодом контекстного API. Может быть, это намного чище.
Лично речь идет о знакомстве. Нет ясной причины выбирать одну из них, потому что они эквивалентны. И внутренне, реакция-редукция использует Context в любом случае.
duix
npm. Это всего лишь простой менеджер состояний с обратными вызовами, который очень легко реализовать. Просто чтобы быть ясно: я создатель.