Persistent State Components

[Archmonger]

Current Situation

Currently, component state is lost upon websocket reconnect. This forces a re-render from the base state.

Proposed Changes

Configure some method to save off the current state of the component

Implementation Details

Implement as an opt-in feature. Might be implemented as an alternative to use_state (for example, use_persistent_state) or as a decorator @idom.persistent_component.

Storing the state

• Use dill to pickle whatever is currently within state upon each set_state mutation.
• State can be stored client side within sessionStorage.

Communicating the state back to the server

• Need to develop some method of preventing the first render if the browser currently has a stored state.
• When the pickled data is transported back as json, it will need to somehow be automatically put back into the state

Avoid state spoofing

• If a component state contains something like "is_admin", it would be pretty trivial to spoof this.
• Need to ensure the browser owns the state it says it does (if state is stored client sided)
• Need to ensure the state has been unmodified since last connection (if state is stored client sided)

[Archmonger]

Due to the risks of client-side state spoofing, this implementation may only be reasonable as a server-side database backed feature.

Blindly trusting a client's state could get risky.

[rmorshea]

closed in favor of #33 and #32