Reinventing State Management
When my team and I set out to create a new state management framework, meant to reimagine the concept in innovative and useful ways, I was doubtful that any truly innovative system really existed out there for us to discover. I was so enamored by the beauty and structure of frameworks before us, that I couldn’t see the statue in the marble. I went into the team ideation process unsure of the possibility of a good outcome. 72 hours of intense, focused debate later, I emerged with plenty of enthusiasm for the project. When things finally started coming together and I realized that innovation was always possible, Radon was the result.
Radon is a state management framework with the following philosophical precepts:
1: Parts of state should be accessible to whatever needs it, and nothing else.
In Radon, the developer is directly in control of which components are able to modify and access specific parts of the state. Encapsulating the data this way speeds up debugging because state modifications can only originate from a select number of places. When looking for bugs, Radon gives you a map and a compass, so you don’t have to hack through the jungle yourself.
2: State changes should never be mysterious.
State is modified using “modifiers”, which are methods attached to specific variables in the state tree. This method means that Radon never has to guess which parts of state are changing, so components dependent on that data -and only the components dependent on that data- are re-rendered. This speeds up runtime, because nothing is ever re-rendered unnecessarily. Other state management tools don’t accomplish this. For example, in Redux you can only attach reducers to top-level keys in the store, so highly nested state changes will cause all of the components subscribed to the entire subtree to re-render.
These ingredients together make a state management framework ideal for working with large teams on complicated projects with deeply nested state and extensive UI’s. Here’s how it works:
The state exists in a tree called the Silo. The state tree is defined by the developer by creating State Nodes, aligning them in the tree, and filling them with data. The State Nodes act as the permission structure of the tree, safeguarding the data they contain. Components subscribe to State Nodes and have access to
1: The data included in that State Node.
2: The data included in that State Node’s ancestors.
Every piece of state points upward toward its parent. This kind of upward-facing tree allows the developer to delegate exactly which parts of state are available to which parts of the application. If something is placed at the top of the state tree, it will be accessible to every other node. If a variable is placed at one of the leaves, access to it is limited to a single component. This is the foundation of data encapsulation in Radon.
Once the state is initialized, modifiers are created in a similar way. For each variable in state, the developer defines modifier functions that return the updated value. This means that modifiers will be attached to the state they modify, and Radon can always know which parts of the state are changing at any given moment, and never re-render something unnecessarily.
The status quo isn’t always flawed, but it also isn’t always perfect. Even the most elegant and useful systems can be rethought and remade into something better. If that mindset manifested itself in the behaviors of more engineers, then we would all live in a more useful world.
