Они очень хорошо ладят и не служат той же цели.
вступление
Большой спор «ловушки и контекст - или 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 позволяет создавать хранилище, представляющее глобальное состояние. Этот магазин содержит данные о вашем состоянии. Чтобы вы могли получить доступ (прочитать) эти данные внутри компонента, вам необходимо:
- Оберните свое приложение в Provider HOC (компонент высшего порядка, который имеет доступ к ссылке на магазин).
- Подключите компонент к магазину и укажите, на какие фрагменты данных магазина вы хотите подписаться.
Каждый раз, когда данные в состоянии изменяются (с использованием и отправкой действий), подключенные компоненты уведомляются, и 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 и хуки (плюс контекст) - друзья, а не враги. Комбинация того и другого также часто бывает хорошим решением. Все это инструменты. Есть веские причины использовать их, и есть веские причины не использовать их.
Существует много неправильных представлений об управлении состоянием в целом.
Надеюсь, мне удалось внести некоторую ясность.
Спасибо за ваше время!
Жерар ван дер Пут
Источники
- Https://blog.isquaredsoftware.com/presentations/2020-10-state-of-redux
- Https://redux.js.org/faq/general#when-should-i-use-redux
- Https://changelog.com/posts/when-and-when-not-to-reach-for-redux
- Https://blog.isquaredsoftware.com/2019/07/blogged-answers-gotits-on-hooks/
- Https://kentcdodds.com/blog/prop-drilling
- Https://daveceddia.com/context-api-vs-redux/