Мнение о всестороннем рассмотрении Redux vs. Context API

Примерно за последний год я столкнулся с несколькими мнениями, предполагающими, что экосистема React рекомендует отказаться от Redux в своих проектах в пользу перехода к современному React с использованием Context API. Несколько эпизодов на React Podcast упоминались как таковые (с такими понятиями, как вы уже перенесли свой Redux в Context?), И было опубликовано несколько статей, которые иллюстрируют эту точку зрения. Я слышал от выпускников учебного лагеря, чьи инструкторы поспешили изучить содержание Redux в своей учебной программе, потому что оно было слишком сложным и люди его больше не используют. Кроме того, я слышал, что это мнение распространилось на совершенно нового разработчика-самоучки, когда он начинал новый проект в нашей компании:

«Я думал, что люди отошли от Redux в пользу Context…» - анонимный разработчик-самоучка.

Я сам даже предположил, что, возможно, Thunks, инструмент для создания асинхронных вызовов действий, устарел - что я больше не думаю, благодаря Redux Toolkit и некоторым неудобствам, которые я с тех пор испытал при использовании только пользовательских хуков в проектах. Честно говоря, я думаю, что мы все были в восторге от новых функций React и подумали: Это будущее! Они классные и дают много полезного. Но избавление от Redux не входит в их число.



Являются ли Thunks устаревшими?
Почему хуки React-Redux могут заменить необходимость в Thunks в ваших проектах React. javascript.plainenglish.io



Возможно, такое мнение возникло из-за нескольких противоречивых заголовков без действительно глубокого анализа, но Redux не мертв. На самом деле, я думаю, что это актуально как никогда. Конечно, я не собираюсь официально отказываться от этой темы. Это может не сработать для каждого проекта. Фактически, Дэн Абрамов, создатель Redux, предположил, что, возможно, вам не нужен Redux в вашем проекте в статье 2016 года. Но для моей организации я нашел несколько причин, по которым мы в обозримом будущем будет продолжать использовать Redux. Будем надеяться, что новые разработчики реагирования тоже учтут это, вместо того, чтобы просто согласиться с недавними настроениями вокруг Context API.

Характер моей работы позволяет мне создавать множество новых приложений с разным уровнем сложности. Это дает мне, возможно, несколько уникальное представление о том, что полезно, а что нет. Я воспользовался возможностью в то время, когда у меня сразу появилось много новых проектов, чтобы протестировать различные реализации управления состоянием, чтобы помочь моей организации определить, куда мы тратим свое время и что действительно было полезно для поиска ошибок. и построение надежно продуманных решений. Эти варианты включали создание приложений с:

  • Только useState крючки (попытка спроектировать таким образом, чтобы избежать как можно большего бурения опор).
  • Полностью ванильная реализация Redux.
  • Только Context API.
  • Реализация Redux Toolkit.

Я обнаружил, что даже в моих приложениях, которые должны были быть небольшими, неизбежно возникали случаи ползучести и краев области видимости, что в конечном итоге делало их более крупными и сложными. Одно из основных преимуществ Context API заключается в том, что он проще и имеет больше смысла для небольших приложений. Но после этого опыта я бы сказал, что мифического «маленького приложения» не существует.

Вдобавок разработчики из моей команды, которые впервые взяли Context, начали сталкиваться с ошибками, связанными с его реализацией с изменяемыми переменными. Реорганизация их кода, чтобы сделать его безопасным и неизменяемым, в основном привела к повторной реализации Redux API (с помощью функций редукторов), но без использования замечательных инструментов Redux Dev Tools. Серьезно, Redux Dev Tools настолько хороши, что мне никогда не нужно использовать точку останова или console.log при отладке. Не стоит отказываться от возможности отследить каждое отправленное действие, вручную отправлять новые действия в живом приложении, точно отслеживать, откуда было отправлено действие в вашем коде, и видеть полное состояние и различие состояний для каждой отправки. «простота» Context API.

С точки зрения простоты - основная причина, по которой Context API считается более простым, чем Redux, связана с сокращением шаблонного кода. Однако безопасно реализованное приложение Context не имеет гораздо меньшего количества шаблонов, чем Redux. И в наши дни Redux Toolkit значительно сократил количество шаблонов. Redux Toolkit - большое отличие в этой дискуссии. Я, вероятно, наткнулся на него позже в игре, чем должен был, но его относительная простота по сравнению с ванильной реализацией Redux в основном полностью отключает аргумент Context API.

TL;DR

  1. Не существует такого понятия, как «маленькое приложение», в котором должен проявить себя Context API.
  2. Redux Dev Tools не стоит отказываться от незначительного сокращения шаблонного кода.
  3. Redux Toolkit снижает сложность реализации Redux до уровня сложности Context API.

Заключение

Redux, на мой взгляд, не только не мертв - он актуален как никогда. С добавлением Redux Toolkit возможности управления состоянием, связанные с Redux, стали лучше, чем когда-либо. Новые функции, представленные в Redux Toolkit, такие как RTK Query, кажутся довольно убийственными (я еще не пробовал, но очень хочу). Люди, вносящие свой вклад в Redux Toolkit, проделали такую ​​хорошую работу, что моя организация будет уделять пристальное внимание этой библиотеке в обозримом будущем, поскольку мы рассматриваем их как лидеров мнений в отрасли.