opaque handle to replace rootNodeId

[swannodette]

Losing this in 0.13.X broke Om applications like CircleCI that used this to maintain an snapshot of their entire application (https://www.youtube.com/watch?v=5yHFTN-_mOo). This permitted full serialization and deserialization of all React app state including transient component local state between browsers (powerful for testing purposes) without forcing programmers to write non-modular code via world passing.

While it's understandable that people might rely on the specifics of the handle, we just need some opaque identifier. We don't care about the actual representation of the handle.

This may well be out of scope. But it would be nice for this issue to get some consideration and official feedback.

[sophiebits]

See, this is why we break private stuff – to get you all to come and write about the APIs you're missing. :)

@sebmarkbage

[sebmarkbage]

Technically it is still there, just moved a level deeper. Feel free to update the hack. Checkout ReactInstanceHandles. In fact, Relay is even using this hack for this very purpose. It is not perfect though because this ID doesn't contain the full key path. Only the path between rootNodeIDs. We also want to move away from using composite IDs which is expensive. Instead, we'd use a key tree + potentially a counter for event listeners but those are implementation details that we don't want to expose.

However, this use case is definitely in scope. We are thinking of a few public APIs to solve similar things:

1. We want to provide a way to externalize the state tree. We're moving towards this model for the internals. Not sure about the representation. This is probably more long term in terms of public APIs.

2. Short term we want built-in support for "rehydrating" an state tree. This use case is a way to save memory by cleaning up the component tree but keeping its state in memory. E.g. while a view is offscreen, between page transitions (forward and backwards) and master/detail view where you switch between different detail views.

3. Longer term we might add a serializable form of 2.

4. These three options only exposes state, not the component tree. This is because we want the component tree to be transient or non-existent in memory. E.g. a plain stateless render function shouldn't need a backing store. It's just a transformation. However, for things like tooling we want to expose the whole render tree for introspection, as a public API. E.g. for building react-devtools. For that use case we would attach an external tool to a running React instance and maintain an external component tree. This is not for production purposes but would be able to connect to a production instance of React.

That's the plan right now in terms of public APIs. Is that plan satisfactory?

[swannodette]

Sorry for the delayed response. These all sound like movement in the right direction to me!

[sebmarkbage]

Closing this out for a broader discussion in #4595