In my Electron app the main process owns the data. It holds the SQLite database, runs git and talks to the network. The renderer, the React side, never does any of that and holds only a read-only copy of the state.
The copy works like this. On connect, the renderer asks for a full snapshot. After that, main sends batches of changes, each with a sequence number, and the renderer applies them in order. Main collects changes for a short moment and sends them as one batch to every window.
The rule I'm glad I made: if a sequence number is skipped, the renderer throws its copy away and takes a fresh snapshot. It never tries to patch the gap. A renderer that is sometimes wrong about the data is worse than one that is briefly empty.
The cost is that there are no optimistic updates. A button sends a named command and waits for the change to come back. Every click has a small delay, so main has to answer fast and batches have to stay small.
What I get for it: two windows can't disagree, a command that fails changes nothing on screen, and the renderer has no code that could do something it shouldn't.
It doesn't apply to everything. View state, like which tab is open or a half-typed message, lives in a separate store in the renderer, because nobody else needs to know it and waiting on main for it would be silly.
If you're starting an Electron app, I'd draw the line between "data" and "view" on day one. It's much harder to add later.
Top comments (0)