-
Notifications
You must be signed in to change notification settings - Fork 67
App state across BrowserWindow instances
I'm going to abbreviate BrowserWindow to "BW".
Right now, we have a set of BWs. Each BW is a React WebApp, with its own Redux app state. This is a sensible model for an App like Slack, which displays each team Slack instance in a pane on the left. It might not be a sensible model for an App like Tofino, which wants to support multiple windows as a first class concept. (This is more clear when we include non-browser-like windows -- authentication logins, preference dialogs -- that are likely to be implemented as BWs.)
Right now, we expect to do a great deal of work in the main process. @rnewman has sketched a plan for a profile service and there are many other things that need to be in the main process -- updates, crash reporting, instrumentation.
Right now, I feel there's an architecture impediment. We have a bunch of Redux loops, each in its own BW sandbox. We call each BW's state "app state", but it's really "window state"; and we don't have a real "app state" that captures the entirety of the browser state.
Let's Redux more of the browser state.
I want to avoid writing a lot of bare message passing, with difficult to interpret life cycles and data flows, between BWs and the main process.
Say the user taps the bookmark star. I want the BW to report the tap action to the main process, and the main process to send the resulting bookmarks state back to the BW. That's Redux: all state changes are actions that are reduced to produce the store; all UI changes are re-renders of the underlying store. I just want to push that model into the main process, and have some of those things cross process boundaries. (Trivial.)
-
Does this buy us anything?
I think so. Trying to follow 'do this, did that, then this' loops in Firefox, across processes, is hard. Redux and React have demonstrated that the action/reduce/update metaphor helps manage complexity. Why in the BW, and not in the main process?
I want to have the same discipline inform the profile service as informs the front end UI.
-
Does this perform?
In an Activity Stream informed world, almost all user actions in a BW should result in a state change, necessarily across process boundaries since the main process will be serializing all actions for later interpretation. Similarly, almost all interpretations will cross the process boundary to ask the main process for results to display. I'd like to have the discipline of actions to the main process and (potential) updates back to the BW process.
Does it scale? Can we isolate the inner Redux loops of each BWs? Can we get performant updates across the process boundary? (I don't have any understanding of these questions.)
[rnewman] I think there are two ways to think of this.
One is that the main process is the top of a React/Redux tree, with reducers running in the main process, and windows are the components underneath, eventually receiving an updated state if one is produced. That is: the only thing that's different is that there's IPC in the action/state flow.
The upside is that this effectively eliminates the multi-window multi-process nonsense.
The downside is that the entire app state is being sent over IPC with some regularity.
An alternative is to think of the main process as the application server, with actions resulting in side-effects sent to the server, and new actions being sent back to each BW as necessary.
For example: a 'bookmark this URL' action results in the 'server' mutating some persistent state, then sending a 'bookmarked URL X' action back to each window.
This alternative seems to fit the "full-stack Redux" model more closely -- it's exactly what a normal R/R web app does when talking to its backend server, and has the potential to be more efficient: allowing the main process to not bother sending messages in some cases, and also making each message smaller.
On the other hand, it requires two BW actions (one "I did this" and one "server state changed in this way") instead of a uniform interface, and is a little more work.
It would be good to get a better understanding of the cost of Electron's IPC layer before moving forward.