Yet another code organization question

#1

[Please see this gallery for the models I am discussing. I could not upload more than one image: https://imgur.com/a/78nGo]

I’m trying to set up a MVC architecture where the model is in the main process and the BrowserWindow is but a representation of this model. I’ve seen the previous topic (Electron App Database File Structure/Code Structure), and I believe this post is a continuation of that discussion. See this model for what I’m trying to accomplish in the ideal case:

Clearly, this is not directly possible, so I tried a proxy approach using remote (see imgur pic #2)

This works OK, except there is no built-in support for signalling property changes across process boundaries. So I am now considering a final model where I manually signal changes (see imgur pic #3).

This requires me to write a lot of ipc.on(’…’) and debug stuff that I really don’t want to debug. Given this background, is this the best I can do without writing a ton of Electron-specific code?

If not, how could I make things look really close to the ideal setup? What makes it difficult? Is there an alternate approach I am not considering?

If so, what would be the most effective code I could write to make this work in a good way?

I tried the final model, but for an object with 3 properties, I had to write way too much code and I think this is a non-starter. I’m out of ideas :frowning:

Thanks in advance.

#2

Why? What is the benefit of putting the model in the main process despite the numerous downsides? (Including harder to debug, having to marshal information across processes, violating the standard separation of concerns designed into Electron, etc)

#3

The main reason is to share the state and changes to that state betweem multiple windows. Imagine a background sync of some kind that updates a value being displayed in multiple single page BrowserWindows. That’s one use case I’m thinking about. I’m hoping I’m missing something obvious that isn’t just “ship a web server”!

#4

I don’t think you’re missing anything obvious. This isn’t a use case that Electron was really designed for, in my opinion.

#5

I agree that the current architecture does not make it easy, but doesn’t atom do the same thing? Basically, the model is in the main process and the various windows are dumb slaves?

#6

No, as I stated on the previous topic you originally posted to, Atom puts everything in the Renderer process. This includes all of the models and views. The only thing that is in the Main process is the stuff that must deal with the OS APIs directly.

#7

Hm. I see. So one possible design could be to have duplicate models in each render process and perhaps a global ‘lol sync’ message to force a sync. Kind of ugh, but also not the end of the world.

Thanks bud.

#8

Hi cheez,

I have a same experience that I want to share the data among multiple windows. I finally work out by writing a database in main process, and when things changed, it will broadcast ipc message to all windows. I didn’t see any difficulty in doing this, and I believe this is better than duplicate model in multiple renderer process.

#9

jwu, I think you’re suggesting something like this, correct? If so, then the model is implicitly duplicated by virtue of reading the database in multiple processes anyway so we might be saying the same thing.

pattern_electron_duplicate_model.png541x589 24.3 KB

#10

Hi cheez,

A little bit like your picture. Only the different is I didn’t use MV* framework in renderer process, instead only View (such as React or Polymer) in the renderer process. So changes for data will always sending ipc and the renderer process only update the view states.

Plus, in your picture, when BrowserWindow1 change a data, you will change the view and sending the event to main-process and then the main-process transfer it to BrowserWindow2. But in my project, user action will never immediately change the view, instead, the action will send to main-process (for example the writeChange), and after main-process take care of it, it will broadcast the changed event to ALL BrowserWindow. So all the BrowserWindow update the view through *changed ipc message, which will make view state syncing safely.

#11

OK, I understand now. :+1: