This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
From what I can tell, the client and server output by the Electric-compiler are tightly coupled, and the server rejects conns from old clients. If a user is filling-out a long form, and a production deployment of the electric app happens in the middle, they lose the state unless we program a way around it. Is this correct, and if so, what would be some reasonable ways of getting around this? Edit: A more succinct version of my question would be "how do I deploy an electric app a few times an hour without annoying users with random refreshes?"
this is correct and you'll need to deal with it in userland for now, in theory "over the air updates" are possible

you can also add ops complexity to keep old server versions running until all clients disconnect
Yeah, that's how I was thinking it could be done. Keeping old server versions running, but letting them know that they're old, which in-turn results in the older clients showing a "newer version available, please refresh" floating modal somewhere.
"user is filling-out a long form" -> for the record, electric makes possible a form architecture where all user interactions are immediately streamed to the server as they type them, where the state can be made durable even before committing to a database
Yeah, long form was not the best example to ask my question.
I have had similar inquiries around this line of questioning. I love how Electric is like well we can just solve that because it’s easy now. So then the question I have. What are some use cases, scenarios where this does fall over. Where you do have to handle persisting an older version of the server application or some other measures. Are these well defined?
"user is filling-out a long form" -> for the record, electric makes possible a form architecture where all user interactions are immediately streamed to the server as they type them, where the state can be made durable even before committing to a database
what would be the usecase for this? why would you stream data to the server, if you do not plan to commit it immediately?
Wouldn’t it be much simple from ops perspective to store the data in browser local storage and stream it to server, when you plan to commit the data to db?sounds use case dependent. Local storage is by definition local, what if you want the user to start a form on their mobile phone and be able to continue on their notebook? What if you're halfway through the form and you want to delegate the rest to one of your team members?
Most people expect a cross device unified experience these days. But there is definitely reasons for local.
ok. cross device experience is a fair point. However, the original question was about how to not loose form state on page refresh, which is triggered by a new electric deployment 😉
Consider for example PKM tools like Notion that can silently lose data if there are connection problems or server problems or the device has low battery and then you lose work. It's my personal opinion that all changes should be "made safe" instantly, and if they are not saved then the input control should be visibly dirty i.e. yellow. The goal being to never lose state ever again. CRUD stuff being an edge case of the more complex Notion use case (which includes datagrids and forms)