Don't have bits of the frontend app state cloned in various places in the main process

[victorporof]

I can see this getting out of hand quickly. Currently, the renderer process sends ipc events to the main process whenever it thinks bits and pieces of the app state are needed there. Things can potentially get messy, especially if different parts of the main process need to access the same app state; the current approach would have us clone this data in every single place, and stress out ipc messaging with redundant events, while having the potential to get everything out of sync.

Should have a standard way of doing all of this. Either clone all or some of the frontend app state in a single place in the main process, or move all of the app state to the main process entirely. The latter approach seems to be even more stressful for the ipc messaging since we have lots of events flowing to the redux store all the time. Selecting data from the app state for use in the frontend might be crippled performace-wise as well if we have only a single app state store in the main process. Therefore, the first option of partially cloned app state in a single place in the main process seems like a better idea to me, opinion weakly held.

[victorporof]

Adding to this, since different frontend browser windows have different app states and live in different processes, this is even more important to fix. The main process code can receive conflicting messages to update certain local state without knowing that said state belongs to different browser windows, unless this nuance is carefully handled.

[victorporof]

I'll take a stab at this. Having a redux store in the main process which can receive actions via ipc seems like a good compromise, resulting in a single place for storing just relevant state.

[victorporof]

Not actively working on this at the moment.