react-shared-mutable-state
v0.0.3
Published
Sharing state across multiple React trees using React's state management
Downloads
14
Readme
React Shared Mutable State
This project is built on a few beliefs:
- React's state management is good.
- Single Page Applications (SPAs) are not a silver bullet.
- Multiple React trees are a sufficient (if not ideal!) architecture in many situations.
- React's state management is good.
What does it do?
The ideal of having a single-atom-of-state that is used to render a single React tree is not possible in some architectures. This can be by legacy, or by choice. For these situations, having shared mutable state is necessary, and we want to manage it well.
Usage
Mount a single <Store/>
component.
This component owns the shared mutable state.
It is an uncontrolled component, excepting one prop: defaultState
.
Read shared mutable state anywhere in a React tree using <GetState />
.
Example:
<GetState>
{(sharedMutableState) => (
<pre>
{JSON.stringify(sharedMutableState, null, 2)}
</pre>
)}
</GetState>
Write shared mutable state anywhere in a React tree using <SetState />
<SetState counter={3} />
Other APIs
Keeping things declarative in a React tree was the initial idea.
If this ideal cannot be satisfied, the escape hatches getState()
and setState()
are provided.
getState()
returns the state of the mounted<Store />
component. If the<Store />
isn't mounted, the default React state shape of{}
is returned.setState()
callssetState
on the mounted<Store />
component. If the<Store />
isn't mounted, an error is thrown.
Caveats
Infinite loops?
It's probably easy to create infinite loops by composing <GetState />
and <SetState />
together.
Lodash's isEqual
has been used to prevent the most obvious possibilities, but I wouldn't rule them out completely.
Resetting state?
Re-rendering <Store defaultState={nextState} />
with a new key
will reset it's internal state, same as rendering any component with a new key
within any React tree!
Multiple stores?
YAGNI for now.
I played with the ideas of multiple stores.
The indirection and complexity introduced didn't seem to solve any problems particularly well.
The increase in API surface area wasn't worth the theoretical organization or performance gains.
Team-localized conventions for what is written to <Store />
is my preferred path forward, for now.
It's React state, we can store whatever we want in it!