[Перевод] Альтернативы Redux в 2021 году
Предположим, вы создаёте или планируете создать React-приложение и вам нужен некий механизм для управления состоянием этого приложения. Если так — это значит, что вам есть из чего выбирать. В сфере инструментов для управления состоянием React-приложений, после её взрывного роста в 2014 году, наблюдается определённое спокойствие. Но в нашем распоряжении, несмотря на это, всё ещё имеется множество решений — от стабильных и проверенных временем, до сверхсовременных.
Все уже давно привыкли к тому, что библиотека Redux является лидером рынка, но, благодаря работе над React и развитию конкурирующих решений, сейчас можно подобрать что-то такое, что будет лучше Redux.
В этом материале мы рассмотрим несколько подходов к управлению состоянием React-приложений, применение которых позволит быстро создавать приложения, код которых будет понятным, которые будет легко поддерживать и тестировать.
№1: стандартные возможности React
Прежде чем мы перейдём к обсуждению множества инструментов, готовых помочь вам в управлении состоянием приложений, полагаю, стоит осветить одну горячую тему. А именно, речь идёт о том, что в состав библиотеки React уже входит всё, что нужно для управления состоянием приложений. Тому, кто пойдёт таким путём, не потребуется никаких дополнительных библиотек.
Когда библиотека Redux пребывала на вершинах славы, множество команд разработчиков помещало в хранилище Redux абсолютно всё. Туда попадали сведения о том, какой именно выпадающий список открыл пользователь, о том, на какой странице приложения он находится, и даже о том, что он ввёл в поле формы. Это, в ретроспективе, очень нехороший подход. Даже если идея централизации всего, что представляет собой состояние приложения, выглядит привлекательной (это применяется, например, в архитектуре Elm), её реализация часто, в большинстве проектов, выглядит как нечто неоправданно сложное и ненужное.
Всё дело в том, что большая часть данных, представляющих состояние приложение, не нуждается в глобальном хранении. Такие данные, в основном, отлично себя чувствуют в useState, или в useReducer, или в пользовательском хуке, близком к компонентам. Компонент может передавать свойства дочерним компонентам одного-двух уровней вложенности, можно, чтобы облегчить себе жизнь, создавать собственные контексты. В некоторых случаях применение такого подхода ограничивают соображения производительности, но таких случаев немного и встречаются они редко.
В результате — прежде чем вы серьёзно займётесь поиском продвинутых инструментов для управления состоянием приложений — подумайте о том, чтобы воспользоваться стандартными инструментами React.
№2: React + SWR или React Query
В те времена, когда я только начал применять React, мне нужно было, в основном, пользоваться состоянием приложений в разных частях этих приложений. Например — если я загружал некие данные, мне не хотелось, в течение определённого периода времени, загружать их снова. Библиотека Redux и то, что часто называют «санками» (thunks), давали мне простой механизм решения подобных задач. Главный минус тут — большие объёмы шаблонного кода.
Большая часть тех данных, которые нужно использовать в разных частях приложения, подпадает под две категории: серверный кеш и глобальное состояние. Серверный кеш, или данные, которые были загружены с сервера, размещённые в некоей системе управления состоянием, и через некоторое время загружаемые повторно, могут быть отделены от глобального состояния, в том смысле, что они не относятся к данным, генерируемым пользователем.
В наши дни существует несколько библиотек, позволяющих наладить работу с серверными кешами. Самым популярным решением такого рода является React Query, а лично мне больше всего нравится SWR. Оба эти инструмента обладают очень похожими API. Они позволяют кешировать запросы к серверу и отличаются продуманными стандартными установками, влияющими на перезагрузку данных в фоновом режиме. Они позволяют настроить всё, что нужно, под требования конкретного проекта и, например, использовать в запросах одни и те же ключи доступа вроде токенов OAuth. Надо отметить, что сведения о ходе загрузки и об ошибках представлены в них в виде логических флагов или с использованием механизмов suspence и error boundaries (если, конечно, вы пользуетесь версией React, которая всё это поддерживает).
Используя одну из этих библиотек для управления всем серверным состоянием, состояние, не имеющее отношение к серверному, можно поддерживать через контексты или через механизмы управления локальным состоянием. В большинстве случаев после того, как налажено управление серверными кешами, надо решить не так уж и много вопросов по управлению тем, что осталось.
№3: Redux Toolkit
Многие разработчики серьёзно вложились в изучение и использование Redux. И это не случайно. Библиотека Redux отличается отличными вспомогательными инструментами, в ней реализован чёткий поток данных, идущих в одном направлении, она имеет очень хорошую документацию. Есть ли способ применить существующие знания Redux и вспомогательные инструменты этой библиотеки, но при этом избавиться от шаблонного кода и от прочих неудобств, характерных для самой библиотеки Redux?
Такой способ есть. Это — RTK, или — Redux Toolkit — библиотека, авторы которой имеют чёткое представление о том, «что такое хорошо», позволяющая упростить работу с Redux-кодом и сделать эту работу менее «шаблонной». В этой библиотеке используются соглашения для упрощения редьюсеров и асинхронных взаимодействий сущностей, для облегчения задачи создания хранилищ. А библиотека immer даёт нам очень простой и быстрый механизм внесения изменений в состояние приложения.
RTK — это инструмент, который по-настоящему освежил Redux-сообщество. Им активно занимаются те же люди, которые поддерживают Redux. Если вы являетесь сторонником подхода к управлению состоянием, реализуемым в Redux, то RTK — это, определённо, лучшее, что поможет реализовать этот подход в 2021 году.
№4: Recoil
Recoil — это новое решение для управления состоянием приложений от Facebook. Эта библиотека всё ещё находится в активной разработке. Создавалась она специально для React, её применение серьёзно облегчает работу.
Каждый фрагмент общего состояния называется «атомом» (atom). Атомы можно комбинировать с селекторами, пересчёт которых выполняется только при изменении атомов. Асинхронность — это стандартный механизм библиотеки, поэтому любое обновление состояния может быть независимым от сеансов взаимодействия с сервером или от того, что происходит в веб-воркерах. Атомы можно упорядочивать с использованием любых структур данных (деревьев, графов и так далее). Другими словам, Recoil — это мощная библиотека.
К Recoil подготовлена очень хорошая документация, а API этой библиотеки начинает становиться по-настоящему стабильным. Если вам, при работе с данными, используемыми в разных частях приложения, нужна высокая производительность, то вам, определённо, стоит взглянуть на Recoil.
Измерение производительности фронтенд-приложений
Мониторинг производительности реальных веб-приложений способен оказаться непростой и трудозатратной задачей. В её решении вам может помочь OpenReplay — первый опенсорсный инструмент для мониторинга производительности. Он позволяет воспроизводить все действия пользователей и демонстрирует поведение приложения при возникновении каких-то проблем. Работа с OpenReplay — это что-то вроде наблюдения за действиями пользователя с открытыми инструментами разработчика браузера.
OpenReplay позволяет воспроизводить проблемные ситуации, собирает сведения о JS-ошибках и мониторит производительность приложений. Мы предлагаем плагины для захвата состояния Redux- и VueX-хранилищ, а так же — для исследования Fetch- и GraphQL-запросов.
Работа с OpenReplay
Инструменты для управления состоянием, которые достойны упоминания
Управление состоянием приложений — задача непростая. Существует, помимо вышеупомянутых, множество других инструментов, направленных на упрощение решения этой задачи. Вот — ещё пара таких инструментов, на которые могут взглянуть те, кто ищет новые способы управления состоянием React-приложений.
▍MobX
Библиотека MobX существует уже много лет. Ей пользуются тысячи команд разработчиков во всём мире. Подход к управлению состоянием, реализованный в MobX, предусматривает «наблюдаемость» всего, что попадает в состояние. Подробности об этом можно почитать в документации к библиотеке.
▍Overmind
Библиотека Overmind демонстрирует ещё один новый подход к управлению состоянием, применение которого упрощает оркестрацию довольно сложных мутаций состояния. Один из моих любимых онлайн-инструментов — CodeSandbox — использует Overmind, и о том, как этот инструмент работает, нельзя сказать ничего плохого. Если ваши задачи по управлению состоянием приложения действительно сложны — возможно, вам подойдёт именно Overmind.
Итоги
Выбор инструментов для управления состоянием React-приложения — это одно из самых важных решений, принимаемых разработчиком. Он может решить применить стандартные механизмы React, может остановиться на самых известных, проверенных временем библиотеках, или может выбрать нечто сверхсовременное, такое, что кажется именно тем, что ему нужно.
Разработчику, принимающему подобное решение, стоит подумать о том, кто будет работать с его кодом, об их компетентности, о том, насколько сложны задачи, которые планируется решать с помощью приложения, и о том, что за приложение он хочет создать. Стоит подумать и о том, сколько будет стоить переход на новый инструмент в том случае, если тот, что выбран изначально, себя не оправдает.
Лично я склоняюсь к стандартным средствам React с добавлением SWR. Я несколько месяцев работал с Recoil. Подход к управлению состоянием, реализованный в этой библиотеке, мне тоже нравится. Что бы вы ни выбрали, очень важно ещё и то, чтобы вам удобно было бы этим пользоваться.
Какими инструментами для управления состоянием React-приложений вы пользуетесь?
