alt Hacker News> If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives.
But it's not, is it? The state lives in the server. If I open a page, and let it open for 2 hours, then there's no guarantee it actually represents the current state.
You are conflating all state into a big undifferentiated soup.
I reason about state differently, Here are my axioms:
1. There is no such thing as "state".` There is user/ui state, there is cache state, there is db cursor state, etc. trying to manage all of that as big undifferentiated ball is not proper separation of concerns.
2. what I call User State is the user's exceptions that they will find things "as they left them". If as a user, I do a pager refresh, I expect that my user preferences for colors and fonts will still be there. that the sorting on the table I was looking at will still still be there, that the filters I had applied to the table are still there. That is I was editing a record but had not saved, I will still be editing that record without data loss on screen but still not saved to the db (unless the app is explicitly autosave). In a word: the user state is what the user can see.
3. Ideally my User State has a single source of truth, the user can always confirm it by looking at it, and is therefore IN the front end.
4. Most, if not all, other state is stored on the server. things like the user's auth state is a -backend- concern, and should NOT be stored in the frontend.
5. class-oriented programming is extremely difficult to manage: as I like to say, every class is a petri dish for state corruption. I prefer pure functions on the backend for the reason I outline ion the dataos.software blog articles.
Pure functions are mostly deterministic (especially if you avoid floats). So you can not only count on getting the same results for the same query, you can cache them too. And you can test them trivially. Integration test? What's that?
When you capture the User State from the DOM (using a manifest so that you do not need to capture the whole DOM) and send it to the pure function on the back end, you have a perfect event source pattern. Not only can I tell you exactly who and what triggered a particular piece of html being sent o the screen, I can rewind and reply like a tape recorder.
BTW, I have no hate for React. There are some things I think it does better than any other option. I was a core member of the React Studio team (expired cert on the site but safe to visit for archeological purposes).