Hibernating State (Not Necessarily Serialized)

[sebmarkbage]

Relay and others currently abuses some internals to get some persistent identity of a component. This effectively is used to restore the state of a component after it has been temporarily unmounted. It is also common to abuse Flux stores for this use case. Basically, since this capability doesn't currently exists, you're encouraged to use Flux for everything just in case you need this capability later on.

The purpose of this issue is to discuss a public API for hibernating the state of a component and then restoring it once the component remounts.

The use cases can be broken down into three scenarios:

• List Item Out of View: E.g. Infinite scrolling (such as "table views") where one row eventually needs to be reclaimed to save the memory used by the tree that is out of view.
• Detail View: In a master-detail view, clicking one item in the list switches the state of the detail view. When you click on the original view again.
• Back/Forward Button: You want to save a snapshot of the state when you navigate. The new view can then change the state and when you hit the back button to return to a previous state, you want to restore the original state of the subtree.

We would like to support this at least in a non-serialized form. You could imagine having an API that serializes this to JSON or some other data structure too but that's a potential follow up and not necessarily part of this.

One potential API:

class View {
  state = { stateKeys: [{}, {}, {}] }
  render() {
    return <ChildView key={this.state.stateKeys[this.props.index]} />;
  }
}

Basically, an object is used as a key. Unlike the normal key semantics, the state of the subtree is kept in memory indefinitely. We use a WeakMap to keep the state. If the object ever goes away, the GC will collect the state of that subtree. This solves all three use cases.

[jimfb]

Personally, I'm still a fan of the state-hoisting pattern:
#4595 (comment)

The pattern is almost identical from a usability perspective (the difference is very subtle), but doesn't require any special support from React.

[ccorcos]

I've used the hoisting pattern myself:

https://github.com/ccorcos/meteor-react-instance

It works pretty well but it definitely seems like something that ought to be baked into React somehow. I prefer to use Redux now though.