что такое стейт менеджер
React State Management в 2020
Нужны ли нам еще стейт менеджеры, такие как Redux и MobX?
Jan 26, 2020 · 3 min read
Введение
Внедрение React Hooks, безусловно, изменило взгляд на управление состоянием.
До того, как у нас появилась эта возможность, было сложно разделить логику состояния между компонентами. Теперь это так же просто, как сделать абстрактный хук (например: useUserLogin).
В связи с этим возникает вопрос, зачем нам еще нужны стейт менеджеры? В этой статье я опишу процесс принятия решений о том, где хранить состояние и поделюсь своим мнением о том, нужны ли нам еще стейт менеджеры в 2020 году.
Что изменилось?
Так как мы опред е ляли состояние до хуков? В принципе, было два варианта: определение локального состояния в компоненте или использование структуры управления состоянием для установки его в качестве глобального состояния (например, MobX / Redux).
Локальный стейт (до хуков)
Допустим, наше состояние не обязательно должно быть глобальным, но мы, возможно, захотим повторно использовать то, как мы определяем локальное состояние в нескольких компонентах.
В приведенном выше примере мы, возможно, захотим повторно использовать настройку состояния загрузки и ошибки — до Hooks это было невозможно. Единственный вариант, который у нас был, это сделать его многоразовым с Redux. В Redux каждый компонент, который хотел искать пользователей, мог просто отправить экшен (searchUsers()) и прослушать, как изменится глобальное состояние.
Однако использование этого глобального состояния (Redux/MobX) приводит к нескольким проблемам:
Есть решение: React Hooks!
К счастью, команда React представила хуки в React 16.8. С того дня стало возможным разделить логику состояния между несколькими компонентами.
В приведенном ниже примере мы теперь можем поделиться поведением при загрузке и ошибках:
Однако, хуки не являются панацеей. Хранение состояния в хуке не означает, что оно становится синглтоном, где состояние привязано только к одному компоненту. Существуют определенные области применения, где мы можем захотеть сохранить только один экземпляр состояния (например, получение информации о пользователе только один раз). Именно здесь менеджеры состояний доказывают свою ценность.
Как решить, где хранить состояние?
Теперь, когда можно разделить логику состояния между компонентами, как мы решим, сохранять ли состояние в компонентах (локально) или в системе управления состоянием (глобально)?
Ниже представлено изображение моего процесса принятия решений.
В чем польза стейт менеджеров?
Теперь мы знаем, когда следует выбирать между глобальным и локальным стейтом. Но зачем нам все-таки использовать стейт менеджеры в 2020 году?
Вот список преимуществ:
Заключение
Как мы можем заметить, React Hooks изменили отношение к популярным стейт менеджерам. С момента их появления стало проще делить логику состояния между компонентами.
Тем не менее, хуки не являются «серебряной пулей», и нам все еще могут понадобиться стейт менеджеры. Это не означает, что нам нужно сохранять каждое состояние в глобальном масштабе — в большинстве случаев лучше сохранять его на уровне компонентов. Перемещение состояния в Redux/MobX должно осуществляться только тогда, когда это действительно необходимо.
Насколько вообще нужны менеджеры состояний?
Я был на собеседовании в уездную галеру N, меня спросили про менеджер состояний Redux. Зачем он нужен, и тд и тп.
Я ответил что не использую менеджеры состояний, а юзаю чистый React. По скольку я до этого встречался и с другими менеджерами состояний. У меня возник вопрос.
А зачем они вообще нужны JS фреемворкам?
Где я должен 100% использовать менеджер состояний иначе фронт загнется?
Я смотрел подкаст, с на котором обсуждалась тема менеджера состояний, и этот подкаст подвел к тому что менеджер нужен лишь для типизации.
Я пишу под React, использовал Vue, и так же Angular. Я сталкивался с менеджерами состояний, и всерьез не понимаю области их применимости.
Стейт менеджер нужен для консистентного управления состоянием приложения, внезапно.
Если вы не пользуетесь менеджером состояния в реакт-приложении, то либо используете контекст (вот хорошее объяснение, почему на проде так делать не нужно), либо пишете заведомо неподдерживаемое приложение. Ну или ваше приложение — это игра в крестики-нолики с двумя полями в стейте корневого компонента.
Большие приложения нельзя писать без стейт-менеджера — это выльется в огромную неподдерживаемую кучу спагетти.
Redux используется как «глобальная переменная», в которую можно положить и взять из любой точки приложения.
Вот в этой статейке более подробно расписано.
Нигде вы не должны использовать 100% менеджер состояний. У него на мой взгляд два назначения:
1) Отделить данные от компонентов, чтобы не прокидывать данные через(или в) 10 дочерних компонентов
2) Унифицировать доступ и запись к данным, это удобно. Все данные и структура их хранения в одном месте, запись происходит одними и теми же экшинами, а не как Год на душу положит. И получение данных из одного источника с одним именем, а не как взбредет в голову создателю нового компонента.
Такая форма стала дефакто основной в вэб-разработке. Кому-то она нравится, кому-то нет, но необходимости в конкретном проекте использовать менеджер, а тем более конкретный менеджер, нет и не будет.
Упираешься в сложность поддерживать код. На маленьких проектах с простой логикой пойдет и просто чистый реакт. С ростом проекта и тем более если проект делают несколько программистов, то поддерживать код становиться сложно. Особенно в react, где код вместе с версткой читать такой код сложно. Второй момент это разделение логики и представления. В своих проектах я использую redoor.
Просто подключить:
А акшенсы просто лежат отдельно в фале в виде:
angular-ngrx-data — state management и CRUD за пять минут
На сегодняшний день ни одно большое SPA приложение не обходится без state management (управления состоянием). Для Angular по данному направлению есть несколько решений. Самым популярным из них является NgRx. Он реализует Redux паттерн с использованием библиотеки RxJs и обладает хорошим инструментарием.
В данной статье мы кратко пройдемся по основным модулям NgRx и более детально сосредоточимся на библиотеке angular-ngrx-data, которая позволяет сделать полноценный CRUD со state management за пять минут.
Обзор NgRx
Детально про NgRx можно почитать в следующих статьях:
Кратко рассмотрим основные модули NgRx, его плюсы и минусы.
.
Подключение в модуль
Использование в компоненте
NgRx/store-devtools — позволяет отслеживать изменения в приложении через redux-devtools.
NgRx/effects — позволяет добавлять в хранилище данные, приходящие в приложение, такие как http запросы.
Подключение эффекта в модуль
NgRx/entity — предоставляет возможность работать с массивами данных.
Что в итоге?
Мы получаем полноценный state management с кучей плюсов:
— единый источник данных для приложения,
— состояние хранится отдельно от приложения,
— единый стиль написания для всех разработчиков в проекте,
— changeDetectionStrategy.OnPush во всех компонентах приложения,
— удобная отладка через redux-devtools,
— легкость тестирования, т.к. reducers являются “чистыми” функциями.
— большое количество непонятных на первый взгляд модулей,
— много однотипного кода, на который без грусти не взглянешь,
— сложность в освоении из-за всего выше перечисленного.
Как правило, значительную часть приложения занимает работа с объектами (создание, чтение, обновление, удаление), поэтому для удобства работы была придумана концепция CRUD (Create, Read, Update, Delete). Таким образом, базовые операции для работы со всеми типами объектов стандартизированы. На бэкенде это уже давно процветает. Многие библиотеки помогают реализовать данную функциональность и избавиться от рутинной работы.
В NgRx за CRUD отвечает модуль entity, и если посмотреть пример его реализации, сразу видно, что это самая большая и наиболее сложная часть NgRx. Именно поэтому John Papa и Ward Bell создали angular-ngrx-data.
angular-ngrx-data
angular-ngrx-data — это библиотека-надстройка над NgRx, которая позволяет работать с массивами данных без написания лишнего кода.
Помимо создания полноценного state management, она берет на себя создание сервисов с http для взаимодействия с сервером.
Рассмотрим на примере
Подключение в приложение
Только что мы получили сгенерированное API для работы с бэком и интеграцию API с NgRx, не написав при этом ни одного effect, reducer и action и selector.
Разберем более подробно то, что тут происходит
Константа defaultDataServiceConfig задает конфигурацию для нашего API и подключается в providers модуля. Свойство root указывает, куда обращаться за запросами. Если его не задать, то по умолчанию будет «api».
Константа entityMetadata определяет названия сторов, которые будут созданы при подключении NgrxDataModule.forRoot.
Путь к API состоит из базового пути (в нашем случае «crud») и имени стора.
Например, для получения пользователя с определенным номером путь будет такой — «crud/user/
Для получения полного списка пользователелей в конце имени стора по умолчанию добавляется буква «s» — «crud/users».
Если для получения полного списка нужен другой роут (например, «heroes», а не «heros»), его можно изменить, задав pluralNames и подключив их в NgrxDataModule.forRoot.
Подключение в компоненте
Для подключения в компоненте необходимо передать в конструктор entityServices и через метод getEntityCollectionService выбрать сервис нужного хранилища
Для привязки списка к компоненту достаточно взять из сервиса свойство entities$, а для получения данных с сервера вызвать метод getAll().
Также, помимо основных данных, можно получить:
— loaded$, loading$ — получение статуса загрузки данных,
— errors$ — ошибки при работе сервиса,
— count$ — общее колличество записей в хранилище.
Основные методы взаимодействия с сервером:
— getAll() — получение всего списка данных,
— getWithQuery(query) — получение списка, отфильтрованного с помощью query-параметров,
— getByKey(id) — получение одной записи по идентификатору,
— add(entity) — добавление новой сущности с запросом на бэк,
— delete(entity) — удаление сущности с запросом на бэк,
— update(entity) — обновление сущности с запросом на бэк.
Методы локальной работы с хранилищем:
— addManyToCache(entity) — добавление массива новых сущностей в хранилище,
— addOneToCache(entity) — добавление новой сущности только в хранилище,
— removeOneFromCache(id) — удаление одной сущности из хранилища,
— updateOneInCache(entity) — обновление сущности в хранилище,
— upsertOneInCache(entity) — если сущность с указанным id существует, она обновляется, если нет — создается новая,
— и др.
Пример использования в компоненте
Все методы angular-ngrx-data делятся на работающие локально и взаимодействующие с сервером. Это позволяет использовать библиотеку при манипуляциях с данными как на клиенте, так и с использованием сервера.
Логирование
Для логирования необходимо заинжектить EntityServices в компонент или сервис и использовать свойства:
— reducedActions$ — для логирования действий,
— entityActionErrors$ — для логирования ошибок.
Переезд в основной репозиторий NgRx
Как было объявлено на ng-conf 2018, angular-ngrx-data в ближайшее время будет перенесен в основной репозиторий NgRx.
Стейт-машина в Angular: учимся использовать правильно
Для начала давайте проясним, что же такое стейт-менеджеры. Если вы оказались здесь, следовательно, знаете о них хотя бы в общих чертах. Примерное описание звучит следующим образом:
Паттерн State Machine предназначен для создания объектов, поведение которых варьируется в зависимости от состояния. При этом для клиента создается впечатление, что изменился класс объекта. Таким образом, назначение предлагаемого шаблона совпадает с таковым для паттерна State, однако область применимости и степень гибкости последнего уже.
Главная идея заключается в том, что объект находится в одном из нескольких сменяемых состояний и может по-разному реагировать на одни и те же события, которые с ним происходят. Набор этих состояний и переходов между ними предопределён и конечен.
Больше материала по теме читайте тут. Это старая статья, но, кроме интересного паттерна в ней прилагается список литературы о конечных автоматах и управлению состояниями в инженерном деле и математике.
Как используют стейт-машины
Сфера применения стейт-машин специфична — это переключатели, реализующие смену состояний, например, в играх, или управляющие переключением различных механизмов программ, например коннект или дисконнект соединения с сетью. Кроме этого, стейт-менеджеры используют, например, для управления состоянием сети блокчейн.
На фронтенде их регулярно используют в качестве хранилища данных с CRUD’ом и шиной событий для относительно безопасного общения частей приложения между собой, для хранения токена или данных пользователя с доступом к ним во всём приложении, или всевозможных списков (страны, языки, валюты и прочее). Это не всегда соответствует области применения стейт машин и в таких случаях целесообразнее использовать более подходящие инструменты.
Плюсы и минусы
Итак, давайте рассмотрим преимущества и недостатки использования стейт-машин в контексте фронтенд-приложений.
Какие мы получаем преимущества:
Теперь давайте посмотрим на проблемы, которые мы приобретаем взамен:
Ну хорошо. Так как же правильно использовать стейт-менеджер?
В первую очередь нужно уяснить, что механизм управления состояниями становится ядром вашего приложения. Не программа его использует, а наоборот — он пускает корни в приложение и паразитирует на его ресурсах. Из этого следует вывод — вы связаны архитектурой, которую навязывает стейт-машина, подходит она для вашей бизнес-логики или нет. Критически важно определить степень ее необходимости в проекте еще на начальном этапе, иначе впоследствии вы будете страдать на сопровождении или удалять ее из уже готового кода, как сорняк, что дорого и тяжело, вплоть до переписывания всего проекта целиком.
Далее перед тем, как писать код, проанализируйте требования к проекту, взвесьте все за и против, определите действительно ли вашему проекту требуется именно управление состояниями. Важно так же учитывать целесообразность — область применения менеджеров состояний довольно специфична и не широка, как это можно понять из описания в начале статьи. Чаще, требуется только Store или Event Bus, альтернатив которым полно в сети или которые можно легко написать самостоятельно, и они не будут диктовать условия вашей архитектуре, но гармонично в неё впишутся.
Теперь рассмотрим случаи использования стейт-машин, в которых они действительно будут кстати. Это уместно, например, в знаменитом пасьянсе «Косынка», где состояние изменяется и фиксируется каждый раз, когда карта перекладывается на новое место. Или в игре в кости, где у кубика 6 граней, а с программной точки зрения 6 состояний. Так же стейт-машина полезна в случаях, когда предполагается большое количество состояний и множество триггеров, чтобы эти состояния менять. Здесь без стейт-машины сложно управлять изменениями и сохранять их чистыми.
Если не требуется управлять состояниями, использование стейт-менеджера усложнит ваше приложение, не давая ничего, что нельзя получить другими способами.
Перенесемся на момент в мир векторной иллюстрации. На картинке изображены два практически одинаковых шара, но с одним большим «НО» — оба шара созданы разными способами.
Интервью c Max Stoiber и Сергеем Лапиным: Выбираем state management решение для React.js
В преддверии конференции HolyJS мы поговорили с Максом Штойбером (одним из организаторов React.js Vienna Meetup, создателем react-boilerplate, принимавшим участие и в создании Carte Blanche) и Сергеем Лапиным (членом программного комитета HolyJS) и обсудили, как выбрать state management решение.
Redux, MobX, Relay или другая реализация Flux? Практические рекомендации и лучшие практики.
Макс Штойбер
– Макс, привет! Для начала коротко представься и расскажи о себе.
– Привет! Меня зовут Макс Штойбер, я Open Source разработчик, работаю в компании Thinkmill. Мы делаем всякие прикольные штуки вроде KeystoneJS, разрабатываем веб- и мобильные приложения, вносим свой вклад в улучшение User Experience.
– Звучит круто! Расскажи, как давно ты всем этим занимаешься, когда открыл для себя React, и в каких проектах участвовал?
– Хмм, кажется, я с React’ом уже примерно 2,5 года. Когда я начинал, Flux считалась самой «горячей» темой в мире! Пожалуй, наиболее известные проекты, в которых я принимал участие, это KeystoneJS, react-boilerplate и sharingbuttons.io.
От Flux к Redux
– Думаю, что теперь у читателей сложилось впечатление о том, кто перед ними. Как ты знаешь, наша основная тема сегодня — это «React Redux на длинных дистанциях: нужен ли он в больших проектах?». Давай начнем с того, что ты думаешь о концепции Flux и какие реализации успел попробовать на сегодняшний день.
– Я очень люблю Flux! Думаю, это восхитительная идея — сделать поток данных однонаправленным.
Это настолько упрощает работу с состоянием приложения и облегчает жизнь, что сложно поверить, что когда-то было иначе. Flux прекрасно масштабируется для приложений любых размеров, позволяет интуитивно разбивать работу с состоянием в соответствии с бизнес-логикой разных частей приложения. Сложно переоценить эту концепцию, когда необходимо «дробить» части проекта и распределять их между членами команды. Сначала я использовал оригинальный Flux, но переключился на redux почти сразу же после его релиза.
– Что ты думаешь о redux в целом? Как относишься к необходимости писать кучу boilerplate кода?
– Я использую redux везде и обожаю его. Я совсем не против писать boilerplate код, более того, мне очень нравится, что вся логика описана явно и не происходит никакой «магии». Redux изменил мой подход к разработке React-приложений. Сейчас я группирую файлы по принципу того, какие фичи они реализуют. Когда мне нужно изменить или дополнить какую-то фичу, я просто ищу соответствующую папку и вижу всю картину сразу без необходимости производить поиск по всему проекту и вспоминать, где у меня что.
О работе со State и о будущем
– Как ты работаешь со стейтом? Например, нормализуешь ли ты данные, которые к тебе приходят от back-end’ов, разворачиваешь Array в Map’ы, используешь ли Immutable?
– Оу, кажется, у вашего сайта очень техническая аудитория. Да, ты все правильно сказал: это лучшие практики на текущий момент. Могу добавить лишь селекторы. Я использую reselect, чтобы мои компоненты могли абстрагироваться от структуры стейта и получали данные в удобном для них виде.
– ОК, с Redux все более или менее ясно. Давай обсудим две другие реализации Flux: MobX и Relay. А также, что ты думаешь о будущем state management решений?
– У меня нет опыта применения MobX в крупных проектах, но он выглядит достаточно многообещающе, и я не раз всерьез рассматривал его в качестве альтернативы redux-у. Если же говорить про Relay, то это прекрасное решение, но с одним большим недостатком: твой back-end должен быть в формате GraphQL. Честно говоря, недавний опрос лишь подтвердил мое ощущение, что рынок решений по работе со стейтом уже сложился, и ситуация вряд ли сильно поменяется в ближайшем будущем.
Если не любишь «магию», то redux — твой выбор
– Если бы я пришел к тебе с вопросом: «Привет, Макс! Я собираюсь сделать новый крупный проект и не знаю, какую state management библиотеку выбрать», что бы ты посоветовал?
– Хороший вопрос. Если твой back-end умеет GraphQL, то можно брать Relay (или Apollo Client), не задумываясь. С MobX и redux выбор несколько сложнее. Если ты любишь экспериментировать и готов потратить немного времени, чтобы вся твоя команда изучила новое решение, то выбор MobX кажется оправданным, по крайней мере, я слышал много хорошего про него в последнее время. Ну, а если ты не любишь «магию», тебя поджимают сроки или ты хочешь поскорее запустить свой проект в продакшн, то redux — твой выбор.
– Что ж, спасибо за твой совет! Я знаю, что ты скоро приедешь в Москву на конференцию HolyJS. О чем ты планируешь рассказать?
– Я буду рассказывать про offline. С помощью этой технологии веб-приложения смогут приблизиться к нативным приложениям. Если коротко, то ServiceWorkers позволяют разработчику определять, что должно делать его приложение или плохом интернете или его отсутствии. Это совсем молодая технология, поэтому устоявшихся решений еще толком нет, но sw-precache, sw-toolbox и webpack offline-plugin выглядят многообещающе.
– Макс, спасибо за твое время! До встречи на конференции!
– Спасибо за интересные вопросы, до встречи в Москве.
Интервью брал @YuryDymov
Сергей Лапин
— Привет, Сергей. Представься, пожалуйста, и расскажи читателям о том, чем ты занимаешься?
— Привет! Меня зовут Сергей Лапин. Я фрилансер, делаю проекты исключительно на React JS и в основном использую Redux. Сейчас уже третий проект делаю на нем. По совместительству один из организаторов HolyJS и SPB Frontend.
Почему Flux-Redux?
— Расскажи, почему именно Flux и Redux? Почему ты выбрал именно этот подход для создания клиентских приложений?
— Основное, чем хорош этот подход — однонаправленный поток данных. Любое состояние системы при таком подходе определяется последовательностью этих action (действий). Теоретически это означает, что если мы дадим Flux эту последовательность, то на выходе мы получим искомое состояние системы. Но самое важное, что просто выведя эти экшены в консоль, легко понять, что вообще происходит. Это имеет огромный эффект для дебага.
Мы не можем получить этот лог событий в традиционных MVC/MVVP и прочих системах, потому что мы неявно меняем модель, дергая те или иные методы. Также модели могут влиять на другие модели, это все вызывает каскад изменений UI, и понять, что от чего зависит, и поддерживать это все становится очень трудно. Поэтому, если хочется поменять состояние, мы бьем себя по рукам. Теперь, будь добр, создай экшн и передай его через Dispatcher, который в системе единственный.
Redux также предлагает думать о приложении, как о начальном состоянии модифицированном последовательностью действий.
Чем Redux лучше?
— Хорошо. Но чем тогда Redux лучше других Flux’ов и State контейнеров?
— Важно понимать, что Redux — это не совсем Flux. Его основное отличие в том, что в Redux нет в явном виде Dispatcher и Store’ов. Хранилища слились в одно большое хранилище. Также Redux умеет диспатчить экшены (создавать события). Стало меньше самостоятельных сущностей. Но самое главное, что однонаправленный поток данных остался.
Одна из ключевых идей Redux — редюсеры (The Reducers). Ничто не взаимодействует с состоянием напрямую. Вместо этого каждый кусочек копируется, а затем все кусочки объединяются в новый объект состояния. Редюсеры передают свои копии обратно корневому редюсеру, который «склеивает» копии вместе для формирования обновлённого объекта состояния. Потом главный редюсер передаёт полученный таким образом объект состояния обратно в хранилище, а хранилище делает его новым «официальным» состоянием.
Если у вас небольшое приложение, можно использовать только один редюсер, который делает копию объекта состояния и его изменения. Если же приложение большое, то может понадобиться целое дерево редюсеров. Это еще одно отличие между Flux и Redux. Во Flux хранилища не обязательно связаны друг с другом и они имеют плоскую структуру. В Redux редюсеры находятся в иерархии и она может иметь столько уровней, сколько потребуется.
Это не единственное отличие Redux от Flux. Создатель Redux Данил Абрамов хотел улучшить Flux, но в тоже время сохранить предсказуемость, которую даёт эта архитектура. У него получилось.
— Почему ты отдаёшь предпочтение Redux, а не другим реализациям Flux, MobX?
Сейчас Redux уже очень популярен, можно сказать – мейнстрим: у него отличная документация, огромная экосистема. Это в каком-то смысле конструктор ЛЕГО. У Redux есть множество точек для расширения: Middlewares, Enhancers, HighOrderReducers и т.д.
Например, Middlewares. Если взять обычный Redux из npm, то там нет никакого решения для асинхронной работы с данными. Даешь ему action, получаешь новый стейт и UI, за один «тик» все синхронно. Но ведь так в реальном мире не бывает, нам надо сходить в сеть, забрать что-то из базы данных и это может вызвать еще какую-нибудь асинхронщину. Бизнес-логика в основном и состоит из такой вот асинхронщины. Тут магию делает Мiddleware, они работают в принципе один в один как в Koa.
Для работы с асинхронностью есть много комьюнити-решений:
Похожая история с Enhancers и HighOrderReducers — центральное хранилище дает много возможностей для контроля.
Опыт работы с Redux
— У тебя уже большой опыт работы с Redux. Какие у него есть проблемы и ограничения? С какими трудностями столкнулся ты в процессе разработки проектов?
— Например, у меня был проект — платформа для обучающих курсов. Это приложение на React, в котором много виджетов для работы с изображениями, графиками, графами и т. д. По сути, это миниприложения, каждое из которых имеет свою логику, свой цикл релиза, и самое главное — свой стейт, который всем остальным не особо интересен.
Обычно с Redux и React не возникает проблем с производительностью, но если вложенность компонентов велика, то, прокидывая все изменения через центральное хранилище, начинаешь чувствовать задержку. В результате пришлось синхронизировать эти стейты с Redux’ом довольно хитрым образом. Был забавный эксперимент с Redux’ом внутри Redux’а.
Есть такая концепция — контейнеры и презентационные компоненты. Довольно долго я считал, что промежуточный стейт это зло. Компоненты стоит делать максимально чистыми и все хранить в Redux. Теперь я так не считаю.
Например, зачем любое изменения в форме диспатчить наверх? Только атмосферу так греть… Нужен промежуточный стейт. Я не большой фанат классов, поэтому с помощью recompose оборачиваю stateless в statefull component’ы. Это позволяет не переписывать существующий код в классы.
— Какие ошибки часто совершают в Redux начинающие разработчики?
– Люди забывают, что reducer’ы должны всегда создавать новый объект. Распространённая ошибка забывать, что spread не делает глубокого мерджа:
Также часто зашивают очень много логики в контейнеры. Её лучше выносить в Action Creator’ы: там их проще компоновать и можно достать текущий стейт у Redux.
А ещё лучше нормализовывать стейт.
— Есть ли у тебя какие либо советы из разряда «Best Practices» для разработки в Redux?
– Прежде всего, не стоит слепо копировать чужие проекты. Можно взять какой-то boilerplate и на скорую руку решить задачу, но потом нужно разобраться, что вы собственно взяли. Выкинуть то, что не нужно, и понять, как работает то, что вы оставили.
Так как Redux многословен, есть соблазн сэкономить пару строк кода и вынести что-нибудь куда-нибудь. Лучше не делать этого сразу. Во-первых, наверняка есть опенсорсное решение и лучше взять его, чем создавать велосипед. Во-вторых, наиболее повторяющиеся паттерны прослеживаются со временем, и это хороший способ выявить главных кандидатов на рефакторинг.
С течением времени вы можете перерастать те или иные подходы, выкидывать одни Мiddleware, использовать другие. Через год можно не узнать проект, хотя это будет тот же Redux. Это, как мне кажется, и есть самое крутое в нем — способность приспосабливаться к требованиям проекта.
HolyJS
— И расскажи напоследок о конференции HolyJS. Чем ты там занимаешься?
– Я в программном комитете, мы отбираем и прослушиваем доклады для конференции, сам выступать не буду.
– Спасибо за ответы!
Также в рамках конференции HolyJS (регистрация) можно будет послушать следующие доклады: