Я фронтенд-разработчик и в своей работе часто сталкиваюсь с менеджером состояний Redux. Наверное, каждый, кто работал в сфере веб-разработки, хоть раз слышал о Redux. И неудивительно, что это отличная библиотека JavaScript, которая помогает управлять состоянием приложения.

Но какой бы хорошей ни была библиотека, всегда есть вещи, которые могут кого-то расстроить и которые можно улучшить. В случае с Redux кривая обучения должна быть крутой, в том смысле, что новичкам может быть сложно понять, что стоит за библиотекой и как все устроено за занавесками. Более того, более опытные разработчики жалуются на объем работы, необходимый для создания нового подсостояния. Лично меня это очень расстраивает - создание селекторов, действий, типов действий, саг (еще одна вещь, которую вам нужно изучить), редукторов - только для одного подсостояния.

Что еще не нравится - вариативность реализации. Под этим я подразумеваю, что почти каждый новый проект, над которым я работаю, использует (реализует) Redux немного иначе. Иногда это просто наименование, иногда структура проекта и государственная структура. И я вижу, что такая гибкость теоретически может быть полезной. Но в реальных приложениях - основы всегда одни и те же - установите statusisLoading (или что-нибудь подобное) - ›получите некоторые данные -› [необязательно: обработайте данные] - ›обновите состояние; и уведомлять слушателей о каждом изменении состояния.

Помня об этом, я решил написать более простую, легкую и, возможно, более быструю библиотеку управления состоянием. Помня о нескольких принципах:

  1. Никаких вложенных подсостояний, как есть, никаких вещей вроде - state.subState_1.nestedSubState_a.nestedNestedSubState_z.
  2. Структура состояний всегда одна и та же - хеш-таблица объектов (subStates), где каждый такой объект имеет следующие поля - data и status.
  3. Нет пользовательских статусов, библиотека предоставляет объект EnumsStatus с тремя возможными состояниями - LOADING, LOADED, FAILED.
  4. Простой API для создания / чтения / обновления состояния.
  5. Никаких саг / редюсеров / типов действий - только действия.

А вот базовая структура:

Так как материала предстоит осветить, вся статья разбита на несколько постов. Этот первый пост является введением, и в следующие посты включены дополнительные материалы и фактические части кодирования.