State Frustrations in Desktop Apps
I made an electron app recently that had me question where to handle state. I built a global store using pinia(vue) and it all worked perfectly.
Until someone asked me to pin reactive data on the mac tray.
The data is stored “too far forward” as sending updates to the tray requires calling back to electrons main process, then redirecting data to tray.
Not difficult, but suboptimal spaghetti. This had me realize that it makes more sense to store reactive state in the main process, so data only has to move "forward".
This has three issues tho…
1) how do you patch ui updates now? (qwik? nah nvm)
2) user interaction is now farther from state making some event handling a tad more tedious
3) we usually choose electron for code sharing with websites… this destroys that (unless you mimic context isolation/bridge with an iframe maybe?)
Has anyone tried managing state this way before?
or is there a better paradigm to pass frontend data to native elements that i missed?
1 Reply
I feel im introducing into the isomorphic / 2 app issue to client code 😆