Они очень хорошо ладят и не служат той же цели.

вступление

Большой спор «ловушки и контекст - или Redux». Если вы разработчик React, то наверняка слышали об этом. И вы могли сформировать свои собственные мысли об этом.

Я давно хотел написать свое осознанное мнение по этому поводу. Итак, начнем.

Я предоставлю список источников, которые использовались в конце этой статьи, чтобы дать вам некоторый контекст.

Давайте двигаться дальше!

Redux

Redux, контейнер с предсказуемым состоянием для JS-приложений, был опубликован в июне 2015 года. Дэн Абрамов сделал первую фиксацию, помеченную тегом версии v0.2.0 . Он стал очень популярным в первые годы своего существования. Одна из причин этого заключалась в том, что с помощью Redux можно было предотвратить так называемое бурение опор (что, кстати, не обязательно плохо).

Redux используется примерно в 50% всех приложений React, включая Twitter, Slack и Spotify (источник: Марк Эриксон, октябрь 2020 г.).

Марк Эриксон является автором, например, react-redux v7 и Redux Toolkit, и у него более 15 тысяч подписчиков в Twitter.

Redux позволяет создавать хранилище, представляющее глобальное состояние. Этот магазин содержит данные о вашем состоянии. Чтобы вы могли получить доступ (прочитать) эти данные внутри компонента, вам необходимо:

  1. Оберните свое приложение в Provider HOC (компонент высшего порядка, который имеет доступ к ссылке на магазин).
  2. Подключите компонент к магазину и укажите, на какие фрагменты данных магазина вы хотите подписаться.

Каждый раз, когда данные в состоянии изменяются (с использованием и отправкой действий), подключенные компоненты уведомляются, и Redux определит, нужно ли повторно визуализировать компонент, посмотрев на mapStateToProps.

Крючки и контекст

React 16.8 представил хуки в феврале 2019 года, спустя небольшой год после обновления интерфейса context с выпуском React 16.3 в марте 2018 года.

Хуки «позволяют использовать состояние и другие функции React без написания класса». Например, ловушка ueState дает вам возможность иметь локальное состояние внутри функционального компонента:

Обратите внимание, как мы упомянули, что это местный штат. Другие компоненты не имеют возможности получить доступ к значению count без внесения изменений в MyComponent. Таким образом, используя только useState, мы не получаем глобального состояния, как в случае с Redux.

Но для этого есть решения, и одно из них - c ontext. И это очень похоже на то, что делает Redux. «Однофайловый» пример (обычно этот код распределяется по нескольким файлам):

Результат:

Обратите внимание на сходство между Redux, с одной стороны, и хуками и контекстом, с другой. Оба используют HOC провайдера, и оба имеют способ подключения компонента к данным глобального состояния (соответственно, функция connect и ловушка useContext).

Сравнение Redux, хуков и контекста

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

Постараемся ответить на оба вопроса.

1. Достигают ли они того же?

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

И когда вы получите немного больше данных в глобальном состоянии, вы можете рассмотреть возможность использования useReducer вместо useState. И вы были бы правы, ответ был бы да, они достигают того же. Затем вы должны выбрать наиболее интуитивно понятное решение, для которого вам нужно будет написать как можно меньше шаблонного кода: хуки и контекст. Это мнение мы часто видим и слышим в Интернете.

Но держись!

А как насчет больших приложений React? А как насчет более сложных приложений с сотнями, если не тысячами, компонентов и очень обширной структурой данных глобального состояния, часто разделенной на несколько выделенных хранилищ?

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

Спойлер: в случае более крупных приложений ответ - нет, они не достигают того же.

2. Почему мы видим такие сильные мнения в Интернете?

Прежде всего, посмотрите ответ в параграфе выше. Люди быстро приходят к выводу, что «ловушки и контекст» - это все, что им нужно, и отклоняют Redux. А кто знает? Возможно, их приложения работают очень хорошо, используя только ловушки и контекст. Так что их мнение было бы справедливым.

Но в то же время могут быть очень веские причины для предпочтения Redux (или предпочтения комбинации и использования лучшего из обоих миров); кое-что, что мы скоро рассмотрим.

И, кроме того, онлайн-мнения, которые мы видим в социальных сетях, - это лишь (небольшая) подмножество всех мнений всех разработчиков в мире. И они склонны к негативу: «Продукт A не хорош!» или «Решение B намного хуже, чем решение C, по причинам X и Y!» . Когда люди недовольны или недовольны, у них быстрее возникает потребность в самовыражении.

Я убежден, что огромное количество разработчиков используют Redux каждый день, и они очень довольны этим.

Но их потребность выразить это удовлетворение далеко не так сильно, как потребность людей поделиться своим неприятным опытом.

Название этой главы - «Сравнение Redux с хуками и контекстом». Но желать сравнивать их неправильно начинать с. Их нельзя сравнивать, потому что они разные по сути.

Посмотрим почему.

Когда использовать что

Во-первых, велики шансы, что Redux вам не понадобится. Что вас устроят хуки и контекст. Как сказал Дан Абрамов:

Не используйте Redux, пока у вас не возникнут проблемы с vanilla React.

Цитата, которая использовалась в другом контексте (без каламбура), подходит и в этом случае:

Если вы не уверены, что он вам нужен, он вам и не нужен.

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

И этим чем-то еще может быть Redux (или MobX, Recoil и т. Д.).

Веские причины начать использовать Redux по словам Марка Эриксона, - это когда вы хотите:

  • иметь предсказуемые обновления состояния
  • оптимизировать производительность рендеринга
  • сохранить логику вне дерева компонентов
  • делиться логикой на разных платформах
  • использовать DevTools
    (Redux DevTools загружается более 100 тысяч раз в неделю)
  • использовать промежуточное ПО, чтобы подключаться к обновлениям состояния
  • иметь специальную настраиваемую экосистему управления состоянием

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

Если вы когда-нибудь изучали тему рендеринга на стороне сервера (я даже написал об этом книгу!), Возможно, вы знаете, насколько важной может быть возможность синхронизировать состояния между сервером и клиентом.

Но я повторяю еще раз: во многих случаях Redux не нужен.

Заключение

Redux и хуки (плюс контекст) - друзья, а не враги. Комбинация того и другого также часто бывает хорошим решением. Все это инструменты. Есть веские причины использовать их, и есть веские причины не использовать их.

Существует много неправильных представлений об управлении состоянием в целом.
Надеюсь, мне удалось внести некоторую ясность.

Спасибо за ваше время!

Жерар ван дер Пут

Источники