There has been discussion in various threads around how to handle cases where the user might be in the middle of some work at a URI that uses LiveView when a deployment occurs. This causes the LiveView process to restart and potentially, the user to lose their work.
In my case, I have a fairly complex view that allows the user to ‘select’ various elements with the selections stored in the LV state. On a deployment, this state is lost causing the LV to review to the blank state.
The docs offer some guidance for state recovery that focuses on forms, using the
On the server, the
"validate_wizard_step"event is only concerned with the current client form data, but the server maintains the entire state of the wizard. To recover in this scenario, you can specify a recovery event, such as
"recover_wizard"above, which would wire up to the following server callbacks in your LiveView
I assume this only works for forms. My question is, what about other cases of state? Can I use that binding on non form elements to recover other state? And how is the server expected to “maintain” the state (of the form or anything else)? In some sort of persistent storage it can read from even after a restart?