-
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.)