State Sharing And You about desktop

[zeke]

I don't have an opinion but I love the breakdown of pros and cons. Looking forward to seeing what others think.

[zcbenz]

Maybe storing global state in localStorage? Which is shared in all renderer processes.

[joshaber]

@zcbenz Good point! I'd be concerned that if N renderers own the state, then it's equivalent to no one owning the state. For example, if we change something and need to broadcast it out to all the renderers, or coordinate some change, we still need something central doing that.

[zeke]

I had some trouble using localStorage because it's not persisted to disk until the app exits cleanly. So if the app crashes or you're working in development and ctrlc out, your state changes are lost.

https://github.com/sindresorhus/electron-config looks interesting. I haven't used it yet.

[kevinsawicki]

So will desktop have multiple windows, like one per repository perhaps?

If that is the case, then is the state we are talking here mostly preferences that apply to all windows, like user preferences and a few global app-wide events (like auto update)?

[joshaber]

So will desktop have multiple windows, like one per repository perhaps?

Right.

If that is the case, then is the state we are talking here mostly preferences that apply to all windows, like user preferences and a few global app-wide events (like auto update)?

Right, or the lists of logged in users, tracked repositories, etc.

[kevinsawicki]

Right, or the lists of logged in users, tracked repositories, etc.

I think the background process (3) approach might work best for this.

One invisible window syncs and dispatches app-wide state changes and can easily be shown when debugging/profiling is needed.

IPC would (I think?) be two-step. Renderer -> main process -> background process.

Yeah, the messages would have go to through the the main process but you could do it all from the background process window.

A window can use the remote module to communicate with other windows "directly", messages still go through the main process but the code is initiated from the background window process making it easier to debug.

backgroundWindow.js

const {getCurrentWindow, BrowserWindow} = require('electron').remote

console.log(`Starting refresh of repositories at ${Date()}`)

refreshRepos().then((repos) => {
  // Assign to global for debugging
  window.latestRepos = repos
  console.log(`Repos refreshed at ${Date()}`)

  // Notify all windows of new repo state
  BrowserWindow.getAllWindows().forEach((window) => {
    // Send IPC event directly to renderer process remotely
    window.webContents.send('repos-refreshed', repos)
  })
}).catch((error) => {
  console.error(`Repos refresh failed at ${Date()}`)
  console.error(error)
  if (process.env.NODE_ENV === 'development') {
    // Show background window on errors when developing
    getCurrentWindow().show()
    getCurrentWindow().openDevTools()
  }
})

window1.js, window2.js, ...

const {ipcRenderer} = require('electron')
ipcRenderer.on('repos-refreshed', (repos) => {
  reposView.setState(repos)
})

[joshaber]

Yeah, the messages would have go to through the the main process but you could do it all from the background process window.

Ah yeah, great call 👍

[joshaber]

Thanks for the input everyone 💖

Gonna continue this discussion around some Real Code in #97.