Hibernating State (Not Necessarily Serialized)

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.

Start by reviewing the proposed View API and the three use cases: list items out of view, detail views, and back/forward navigation. There are no files or tests named in the issue; this work is complete only when a decided public API can preserve and restore component state without requiring serialization.