Externalize the State Tree (or alternatives)

React provides the notion of implicitly allowing a child component to store state (using the setState functionality). However, it is not just used for business logic state. It is also used to remember DOM state, or tiny ephemeral state such as scroll position, text selection etc. It is also used for temporary state such as memoization.

This is kind of a magic black box in React and the implementation details are largely hidden. People tend to reinvent the wheel because of it, and invent their own state management systems. E.g. using Flux.

There is still plenty of use cases for Flux, but not all state belongs in Flux stores.

Manually managing the adding/removing of state nodes for all of this becomes a huge burden. So, regardless you’re not going to keep doing this manually, you’ll end up with your own system that does something similar. We need a convenient and standard way to handle this across components. This is not something that should be 100% in user space because then components won’t be able to integrate well with each other. Even if you think you’re not using it, because you’re not calling setState, you still are relying on the capability being there.

It undermines the ecosystem and eventually everyone will reconverge on a single external state library anyway. We should just make sure that gets baked into React.

We designed the state tree so that the state tree data structure would be opaque so that we can optimize the internals in clever ways. It blocks many anti-patterns where external users breaks through the encapsulation boundaries to touch someone else’s state. That’s exactly the problem React’s programming model tries to address.

However, unfortunately this state tree is opaque to end users. This means that there are a bunch of legitimate use cases are not available to external libraries. E.g. undo/redo, reclaiming memory, restoring state between sessions, debugging tools, hot reloading, moving state from server to the client and more.

We could provide a standard externalized state-tree. E.g. using an immutable-js data structure. However, that might make clever optimizations and future features more difficult to adopt. It also isn’t capable of fully encapsulating the true state of the tree which may include DOM state, it may be ok to treat this state differently as a heuristic but the API need to account for it. It also doesn’t allow us to enforce a certain level of encapsulation between components.

Another approach is to try to add support for more use cases to React, one-by-one until the external state tree doesn’t become useful anymore. I’ve created separate issues for the ones we we’re already planning on supporting: #4593 Debugger Hooks as Public API #4594 Hibernating State (not the serialized form)

What else do we need?

Pinging some stake holders:

@leebyron @swannodette @gaearon @yungsters @ryanflorence

[ryanflorence]

I get excited about redux because of time-travel debugging and eventually creating test cases out of dispatched actions … but I really like how components encapsulate state.

Trying to create a place in redux state for each component instance is cumbersome and pretty ridiculous when the component already has a place for its own state.

Also, it turns out that component state is the state that the time-travel debugging is most useful! So the state I keep in redux is boring, the state I don’t put in redux doesn’t get time-travel. Feels weird.

What I love about redux is the middleware to create tools around the app’s state. I’m sure this API has 8 trillion holes in it, but just to prime the conversation what if we had stuff like:

React.render(<App/>, el);

let tree = React.getStateTreeAtNode(el);

React.onStateTreeChangeAtNode(el, fn);

React.renderWithStateTree(<App/>, tree, el);

That would be enough to build some time-travel debugging tools, yeah?

[bgergen]

Have there been any further thoughts regarding this over the past year and a half?