React Context vs React Redux, когда я должен использовать каждый из них?

React 16.3.0 был выпущен, и API контекста больше не является экспериментальной функцией. Дэн Абрамов (создатель Redux) написал хороший комментарий здесь об этом, но это было 2 года, когда контекст был еще экспериментальная функция.

Мой вопрос, по вашему мнению/опыт, когда следует использовать React Context Over React Redux и наоборот?

Ответ 1

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

Как писал Марк Ериксон в своем блоге:

Если вы используете 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-интерфейсом контекста

Ответ 2

Если вы используете Redux только для того, чтобы избежать передачи реквизитов глубоко вложенным компонентам, тогда вы можете заменить Redux на Context API. Именно для этого случая использования.

С другой стороны, если вы используете Redux для всего остального (наличие контейнера с предсказуемым состоянием, обработка логики вашего приложения вне ваших компонентов, ведение истории всех обновлений состояния, использование Redux DevTools, Redux Undo, Redux Persist, Redux Form, Redux Saga, Redux Logger и т.д.), Тогда нет абсолютно никакой причины для замены Redux на Context API.

И лично я считаю, что расширение Redux DevTools - это удивительный, недооцененный инструмент отладки, который оправдывает само использование Redux. Но это только мое мнение. :)

Рекомендации:

Ответ 3

Единственными причинами использования Redux для меня являются:

  • Вам нужен глобальный объект состояния (по разным причинам, например, отладка, настойчивость...)
  • Ваше приложение будет или будет большим и должно масштабироваться для многих разработчиков: в таком случае вам, вероятно, нужен уровень косвенности (т.е. система событий): вы запускаете события (в прошлом), а затем люди, которых вы не знаете в своем организация может их слушать

Вам, вероятно, не нужен уровень косвенности для всего вашего приложения, поэтому прекрасно сочетать стили и использовать локальное состояние/контекст и Redux одновременно.

Ответ 4

Я предпочитаю использовать 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 в любом случае.

Ответ 5

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

С: Когда использовать Redux?