Redux electron store

[wolovim]

What does it do?

• Introduces a client-side Redux store
• Synchronizes state across main and client-side stores
• Takes a pass at refactoring i18n through a Redux workflow

Any helpful background information?

This comes after lots of research and experimentation. It doesn't feel perfect by any means, but the Redux+Electron workflow is starting to make a great deal more sense. I captured some thoughts/lessons along the way:

• It appears to be very common to see Redux in the client side, used identically to web apps. Less so in the main process, as its completely separated from a view library.
• There are two packages that can be used to sync Redux stores across main and client-side (or multiple client-side)
  • https://github.com/samiskin/redux-electron-store. I've chosen this one, as it was developed and used at Slack, and the API is much simpler.
  • https://github.com/hardchor/electron-redux - requires using aliased actions (ugly)
• Redux actions can be used to replace manual IPC calls (though they occur under the hood to synchronize stores)
  • however, this strategy appears to force you to use Redux in ways it was not intended to be used (reacting to new changes by dispatching more actions or handling a lot of logic in a subscribe callback. Example usage: Is it possible to get action and state in store.subscribe? reduxjs/redux#580 (comment))
  • instead of the above, it feels very reasonable to continue to use manual IPC calls, but use them to trigger new actions on the client side. (Example found in this i18n PR.)
• Eventually, the Redux store can probably replace things like the Settings class instance that gets instantiated several times throughout the app.
• When a new store is created, you can optionally pass it an initial state. For example, after the local db contents are fetched, the store may be created with those settings as its initial state. (Another implementation option is just to have the results of the db fetch update the store later.)
• I'm experimenting with a different action type naming pattern to differentiate between actions dispatched by client and main stores, e.g. [CLIENT]:GET_LANGUAGE:SUCCESS. I don't mind changing that if stronger preferences exist.
• Unit tests have been added and can be ran in watch mode with yarn test:unit (or ran once with yarn test:unit:once).

Which code should the reviewer start with?

There's a lot going on. For starters, the main store is created in modules/core/store.js and the slimmed down client-side store gets instantiated in modules/preloader/mistUI.js.

New dependencies? What are they used for?

redux-electron-store: for keeping stores in unique processes in sync.

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.