Creating a better state manager.

Image by Valdas Miskinis from Pixabay

I’m a front-end developer and in my work, oftentimes I come across Redux state manager. Probably, anyone who has worked in the web development sphere heard about Redux at least once. And there’s no wonder, it’s a great JavaScript library that helps to manage application state.

But however good the library is, there are always things that can frustrate someone and that can be improved. In the case with Redux, there is a steep learning curve in the sense that it might be difficult for newcomers to get a hold of an idea behind the library and of the way things wired behind curtains. And there is also a lot of complaints from more experienced developers about the amount of work needed for creating a new sub-state. Personally, I find it very frustrating — creating selectors, actions, action types, sagas (another thing you’d need to learn), reducers - just for a single sub-state.

What I also don’t like — the variability of the implementation. By that, I mean that almost every new project, that I’m working on, uses (implements) Redux a bit differently. Sometimes it’s just naming, sometimes project structure, and a state structure. And I can see that this flexibility theoretically might be useful. But in the real world applications — basics are always the same — set statusisLoading (or anything similar) -> get some data -> [optionally: process the data] -> update the state; and notify listeners on every state change.

With all that in mind, I decided to write a simpler, lighter, and arguably faster state management library. With several principles in mind:

1. No nested sub-states, as is, no things like — state.subState_1.nestedSubState_a.nestedNestedSubState_z.
2. The state structure is always the same — a hash table of Objects (subStates) where each such Object has the following fields — data and status.
3. No user-defined statuses, the library provides EnumsStatus object with three possible states — LOADING, LOADED, FAILED.
4. Simple API for creating/reading/updating the state.
5. No sagas/reducers/action types — only actions.

And here is a basic structure:

As there is a lot of material to be covered the whole article is divided into several posts. This first post is an introduction, and more material and actual coding parts are included in the following posts.