state management что такое
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 должно осуществляться только тогда, когда это действительно необходимо.
Biscuit-store — еще один взгляд на state-management в JavaScript приложениях
Приветствую дамы и господа! В этой статье я расскажу о JavaScript библиотеке Biscuit-store.
Описание
Основные цели статьи
Рассказать о biscuit-store и его целях;
Провести сравнение с другими подобными инструментами;
Дать краткий обзор функционала.
Здесь я не буду погружаться под капот, а лишь проведу краткий обзор.
Плюсы biscuit-store
Стремление к простоте исполнения;
Стремление к единому подходу;
Асинхронность из коробки;
Простое расширение через Middleware;
Гибкая модульная архитектура;
Оптимальное соотношение размера библиотеки и количества функций;
Характеристики
Вес core – 18Kb, Gzip: 6.2кб (скомпилировано в CommonJs);
Вес react модуля – 6.8, Gzip: 2.0кб;
Вес adapter модуля – 9.6, Gzip: 3.5кб (скомпилировано в CommonJs);
Проверено в браузерах:
Mozilla firefox 40+;
Включена поддержка TypeScript.
Для чего создавалась эта библиотека и зачем она нужна?
Чтобы понять мотивы создания библиотеки, надо посмотреть на существующие популярные инструменты для JavaScript state-management, а именно: redux и mobx.
Redux
Это легковесная библиотека, которая весит всего 2kB и представляет единый контейнер управляемых состояний для js приложения. Основными плюсами redux являются его малый вес и гибкость. C помощью redux можно разрабатывать приложения любого размера. Мне лично нравится эта библиотека.
Но дьявол, как известно, в деталях.
Все не так просто, как кажется
Когда смотришь пример кода на GitHub возникает чувство, что все довольно просто. Но, когда дело касается применения в реальном проекте и если вы новичок, то у вас может просто-напросто, может вскипеть мозг. Вы не понимаете что, куда и как… Судорожно начинаете искать в интернете статьи и видео-уроки чтобы понять, как собрать все паттерны воедино. Redux-toolkit конечно сглаживает эту проблему, но лишь частично.
Отсутствие асинхронности из коробки.
Вероятно, в 2015, когда создавалась эта библиотека, это не было столь значимо. Сейчас на дворе 2021 и асинхронность повсюду во вселенной JavaScript. Конечно, эта проблема частично решается через middleware, такие как redux-saga и redux-thunk. Но это порождает еще две проблемы: отсутствие единого подхода и увеличение зависимостей проекта.
Отсутствие единого подхода
Лишние зависимости от сторонних библиотек
Вывод
Mobx
Основной лозунг mobx:
“Все, что может быть получено из состояния приложения, должно быть. Автоматически”.
Ни в коем случае не воспринимайте всё вышесказанное как хейт. Это всего лишь моё субъективное мнение, о плюсах и минусах данных инструментов.
Теперь можно поговорить о Biscuit
По задумке, biscuit должен быть максимально функционален, в меру автоматизирован и поощрять единый подход к архитектуре.
Перейдем к практике
Вы наверняка заметили утку на превью к статье и задались вопросом: «Причем тут утка?», речь же о бисквите… Тут нет каких-то безумных аналогий, просто я предпочитаю описывать создание контейнера состояний в biscuit по принципу трех шагов создания утки:
Донесите до утки, что она утка и должна, крякать, летать и плавать;
Научите утку крякать, летать и плавать.
Хватит слов, давайте поиграем в утиного бога
Итак, создадим нашу утку (хранилище состояний).
Если вы ранее использовали redux, то вы привыкли, что у вас есть одно хранилище состояний для всего приложения. Напротив, Biscuit-store поощряет создание нескольких контейнеров для разных абстрактных сегментов вашего приложения.
Мы создали хранилище с минимально необходимыми настройками. То есть у нас теперь есть утка. Но она еще не осознает, что она утка и не умеет быть таковой.
Теперь мы должны донести до нее, что она утка и должна делать вещи, присущие уткам.
В поле actions мы явно указали то, что должна уметь наша стейт-машина, то есть наша утка теперь знает, что ей надо делать некие действия. Теперь нам нужно научить утку делать те самые действия.
Наша утка готова отправится в большой мир.
Давайте проверим, на что она способна.
А так это будет выглядеть в React.
На этом все, спасибо за внимание!
Biscuit-store молод и нуждается в поддержке
Biscuit еще очень молод и находится в стадии бета-тестирования.
Если вам понравилась эта библиотека, помогите ей развиваться звездочкой в GitHub’
Заметки по state management
Apr 25, 2017 · 5 min read
Сейчас я уже чуточку поднабрался опыта и понимания, чего и зачем я хочу. Начнем с того, что именно должен уметь этот state management:
Вот от этих требований никуда деться нельзя, они обязательны. Но есть еще список желаемых вещей:
Самая первая идея, про которую стоит сказать: можно попытаться скопировать механизм change detection от angular2. Т.е. тупо перебираем граф объектов и делаем снепшот на каждом движении мышки и прочих событиях.
Но ангуляр проходит не по всему г рафу объектов. Он чуточку умнее и дергает только объекты достижимые из видимых компонентов. А нам реально придется весь граф проходить. Это не проблема для малых графов, но для больших графов это эпичная жесть. Особенно будет прикольно это обнаружить в тот момент, когда исправлять уже поздно.
Кроме того, у ангуляровских компонентов можно установить ChangeDetection в режиме OnPush, что серьезно снизит нагрузку. А такой же механизм придумать для этих целей немного сложновато.
Также ангуляру вообще даже не приходиться думать о отслеживании дублирующихся ссылок, ибо для него это никакой роли не играет.
К сожалению, по данным caniuse: Proxy поддержка браузерами этой фичи — аж 72%. Это конечно большое число, но на таком строить сейчас сайт просто нельзя.
Но давайте помечтаем. Пускай у нас будет стопроцентная поддержка Proxy. Даже ею нужно уметь воспользоваться. А потом уже подумаем, что делать при нормальном положении вещей.
Когда мы говорим о undo/redo, то есть две стратегии обеспечения этого механизма:
В первой стратегии для обеспечения безопасности диффа мы вынуждены клонировать новые объекты. Иначе программист может случайно испортить историю, что будет очень неотслеживаемым багом.
Во второй стратегии мы тоже вынуждены держать безопасные неизменяемые клоны всех снепшотов. Но под вторую стратегию уже есть целая полупроработанная концепция иммутабельных деревьев и их изменения.
Честно говоря, за снепшоты и имуттабельность я голосую по привычке. Но стратегия инкрементальных диффов (как и любая мутабельная вещь) потенциально может работать быстрее.
Если вы, конечно, сможете её реализовать (это может оказаться весьма нетривиальным).
В частности, если мы возьмем обычный массив, то клонирование массива уже становится дорогой операцией. В этих случаях нужно использовать персистентные структуры данных, но с ними потруднее работать. Да и в целом такие структуры данных слегка медленее (не критично для обычного сайта).
С другой стороны перерисовка снепшота требует прохождения по этому массиву. А это линейная нагрузка: чем больше массив, тем дороже перерисовка. А вот с помощью инкрементальных диффов мы можем сделать перерисовку без прохождения по всему массиву.
Возможно, я когда-то вернусь к рассмотрению этой стратегии.
Отойдем от способа хранения изменений и подумаем, как именно мы будем менять данные.
JavaScript/TypeScript являются императивными языками с малым количеством сахара. Увы, бесполезно надеяться, что мы сможем манипулировать иммутабельными данными так же легко, как и в clojure. Именно по этой причине redux выглядит чужеродно и стремненько.
Имеет смысл спрятать эти манипуляции с иммутабельностями за каким-нибудь мутабельным фасадом. Для этого нам и нужен Proxy. Он просто будет делать всю ерунду, которую в redux программисты делают руками.
Написание такого Proxy — вполне тривиальная задача. Но Change Detection при этом придется оставить ангуляровский без надежды на возможность оптимизации плохих случаев.
Дальше появляется весьма тривиальная идея: а давайте мы будем пересоздавать наши мутабельные прокси в момент изменения соответствующих данных. В таком случае angular будет прокидывать изменения вглубь по дереву компонентов, пока не упрется в компоненты, которые не поменялись.
Использование такого механизма будет выглядеть примерно так:
Это вполне реализуемо на проксях. Почему бы и нет?
Примечание: я, канешно, понимаю, что это тот еще лол, но как еще?
Теперь нужно подумать о вычисляемых свойствах. Есть тривиальный случай: вычисляемое свойство ограничено только пределами текущего объекта и его детей. В этом случае мы не пропустим ни одного изменения.
Главное — следить, чтобы у нас был правильно прибинджен this, но это уже вопрос правильности реализации, а не идеи.
Но на практике возможность сходить в корень состояния очень облегчает жизнь. Особенно с учетом того, что в рамках redux вроде бы пропагандируется нормализация данных. С другой стороны, в рамках того же redux это решается вроде как простыми селекторами и маперрами. Этот вопрос придется отложить и продумывать попозже.
Так, общая концепция у нас есть. А вот Proxy нет. Но так ли нужны нам Proxy?
Если мы говорим про известные нам свойства объекта, то мы можем с легкостью в рантайме генерировать геттеры и сеттеры. А вот с неизвестными свойствами дело обстоит серьезно похуже. Мы вообще не можем с ними ничего сделать.
Тут еще проблем подкидывает Typescript. Для него нет разницы между
А вот у Java и Javascript нет возможности задавать индексатор. Поэтому перехват обновление элемента массива без Proxy невозможно. Словари ведут себя аналогично: нет возможности контроллировать обновление.
В таких условиях реализовать адекватный синтаксис нереально. Но можно вывернуться. С помощью Object.preventExtensions мы можем убедиться, что в объект (или массив) не добавляется ничего нового случайным образом. А с помощью Proxy мы можем проверить, что мы даже не стучимся по отсутствующим свойствам. Мы вполне можем использовать Proxy при разработке, но код в продакшене не должен его содержать.
Работу со словарями и костылями придется костылировать и вводить собственные типы данных, которые позволяют контроллировать обновление. Поэтому для нас весьма критично, чтобы типы корректно сохранялись.
Это общие зарисовки моей новой идеи. Посмотрим, как оно выгорит. Основная надежда у меня возлагается на следующее:
state management
Смотреть что такое «state management» в других словарях:
State management — refers to the management of the state of one or more user interface controls such as text fields, OK buttons, radio buttons, etc in a Graphical User Interface. In this user interface programming technique, the state of one UI control depends on… … Wikipedia
state management — index bureaucracy, government (administration) Burton s Legal Thesaurus. William C. Burton. 2006 … Law dictionary
State Management Scheme — The State Management Scheme (known locally as The Scheme ) saw the UK government take over and run the brewing, distribution and sale of liquor in three regions of the UK from 1916 until 1973. [cite web|url=http://www.bookscumbria.com/cgi… … Wikipedia
ASP.NET state management — Необходимо проверить качество перевода и привести статью в соответствие со стилистическими правилами Википедии. Вы можете помочь улучшить эту статью, исправив в ней ошибки. Оригинал не указан. Пожалуйста … Википедия
State diagram — State diagrams is a diagram used in the field of computer science, representing the behavior of a system, which is composed of a finite number of states. There are many forms of state diagrams, which differ slightly and have different semantics.… … Wikipedia
state-craft — n. Statesmanship, state management, political subtlety … New dictionary of synonyms
State Guard Association of the United States — Abbreviation SGAUS Formation 1985 Legal status 501(c)(6) … Wikipedia
State University of New York College of Environmental Science and Forestry — Established 1911 Type Public President Cornelius B. Murphy, Jr … Wikipedia
State General Administration of Sports — (Chinese: 国家体育总局 Pinyin: guójiā tǐyù zǒngjú) is the government agency responsible for sports in China. It is subordinate to the State Council. It also administers the All China Sports Federation and Chinese Olympic Committee. [1]. The agency is… … Wikipedia
State sector organisations in New Zealand — are as follows: (see also State Sector Act 1988) Parliamentary Offices * Office of the Controller and Auditor General (Tumuaki o te Mana Arotake) ** Audit New Zealand * Office of the Ombudsmen (Nga Kaitiaki Mana Tangata) * Office of the… … Wikipedia
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.