Motivation

Introduction

Ever since the advent of single-page applications, we've been handling more and more data on the Frontend, to the point where technologies like GraphQL® are putting Frontend in the driving seat and be done with it. This is all great until you realize that now you have to fetch, transform, manipulate, and manage all this data in an efficient way on Frontend.

Problem

Angular, React, Vue, and other similar technologies have made Frontend development so much more versatile and efficient. But at the same time, state-management doesn't seem to be getting any easier.

For efficient state-management, we need a few things

• data structures that are type-safe

• data structures that can emit events on mutation

• data structures that can guarantee immutability

• data structures that can be persisted through sessions

JavaScript has none of it, but that's just one part of the problem.

A component built with the Model-View-Controller pattern works great until you have to share the Model with other components. That's where the state managers come into the picture. All the shared data now goes through the state-manager, every component gets the data from the state-manager and updates it into the state-manager. But since most mainstream state managers seem to be too verbose, the more you have to use the state-manager the more bloated your codebase becomes, instead of MVC now it becomes Store-Feature-Reducer-Middleware-Selector-Dispatcher-Effect-View-Controller. It increases the number of moving parts and bloats up the logic involved in a feature.

The verbosity and obscurity inherent with most mainstream state management solutions can be intimidating to new developers, and even puzzle and overwhelm the experienced ones. It can become the most complicated part of your app logic very quickly. Then we have to use even more abstract concepts and tools to make sense of this complex structure. It's not uncommon that developers start questioning the need for all this extra complexity and even deem it counter-productive.

Apart from the verbosity and obscurity, another problem is the human brain's limited working memory; and having so many abstract concepts distributed in so many files all over the place hinders a developer's performance. Separation of concerns is supposed to make our lives easier not harder.

Solution

We believe instead of having a single store and so many abstract utility concepts to make the store work, having independent reactive storage Units, that closely resemble JavaScript's native data structures with all the features required for modern state-management built-in, are the answer. Together with a few utilities these Units can achieve everything that is required from a state-manager and do it very efficiently with less code and less confusion.