[yunyu]

Great minds think alike! I had a feeling this was a relatively straightforward insight, and Purview looks like a pretty cool implementation.

To answer your questions:

1. We have a mechanism to serialize the React state tree, as long as it can be copied with the HTML structured clone algorithm (https://github.com/calderajs/caldera-react/blob/master/src/s...) which has always seemed to be the case in practice. Each tree is associated with a unique token which is stored on the client, but the current storage implementation is in-memory only as we haven't addressed the application upgrade issue. Outside of that, there's nothing stopping us from adding basic versioning (along with react-hot-loader-like reconciliation behavior) and moving the state storage to a database that is shared among application servers.

2. This isn't really fleshed out yet, but we'd likely take inspiration from React Native's native module approach where lifecycle events for mounting/unmounting/updating a component are implemented on the client, with bindings being called in the server application code (a React-specific version of your web component implementation). I know we're against high-level RPC, but React props naturally have a data/async callback structure that is amenable to being represented as RPC calls (which works for React Native), which is why we're leaning towards that approach.