[Proposal] Use redux-electron-store

[Jhen-Jie Hong]

We can use redux-electron-store, in this way, we can let main process dispatch actions to other BrowserWindow.

1. Main process store reload: samiskin/redux-electron-store#3
2. One issue at samiskin/redux-electron-store#6, otherwise we can split DevTools to another BrowserWindow.

I have such a demand, but this boilerplate will become too complicated? I would like to know everyone views.

[C. T. Lin]

This one is quite interesting. I will give it a try next month.

[Domas]

I also wanted to dispatch some actions from main process, and also to share state between multiple windows.
Achieved this quite easily by instantiating the store on the main process and then remote.requiring it in the renderer:

const remote = require('electron').remote;
const store = remote.require('./app/store');

render(
    <Provider store={store}>
        <CounterPage/>
    </Provider>,
    document.getElementById('root')
);

Works perfectly. Had to hook babel into main proc though.

[Nader Hendawi]

@domasx2 when you hook babel into the main proc, are you then able to successfully run npm run package and run the application? I receive a number of errors related to babel imports.

[Domas]

Yeah, stage-0 preset was somewhy crapping out on main proc.
Probably the right way to solve it was to figure out what's wrong and then refac .babelrc using BABEL_ENV to set up different configs for main proc/ webpack/ tests.
But what I did was:

//.babelrc
{}

//bootstrap.js
require('babel-register')({
    "presets": ["es2015"],
    "plugins": ["transform-object-rest-spread"],
    "ignore": /(browser\/api|common\/api)/
});
require('./main');

//package.json
...
 "main": "bootstrap.js"
...

//webpack.base.js
...
    loaders: [{
      test: /\.jsx?$/,
      loader: 'babel-loader',
      query: {
          "presets": ["es2015", "stage-0", "react"],
          "plugins": ["add-module-exports"]
      },
      exclude: /node_modules/
    }
...

//webpack.development.js
...
config.module.loaders.forEach(function(loader) {
     if (loader.loader === 'babel-loader') {
        loader.query.presets.push("react-hmre");
     }
});
...

[Jhen-Jie Hong]

@naderhen I recommend using babel compile in production mode (npm run package), if you insist on using babel-register in production mode, you must move babel modules to dependencies, it would be big size for package.

Also, in my personal project, I using electron -r babel-core/register . for development mode.

[Nader Hendawi]

@domasx2 running the packaged application works for you with your setup? Things build perfectly in development, but the packaged app still throws the following error:

If you have a fork of this boilerplate I'd love to take a look!

[Domas]

Oh yeah, I did encounter this. The problem is that package.js omits some babel files by accident. Solution was to remove this line: https://github.com/chentsulin/electron-react-boilerplate/blob/master/package.js#L25

Unfortunately my changes for this are in a private repo. I think it would be more worthwhile to "do it properly" and make a PR where package.js babelifies the source rather than include babel in the distro though. Perhaps will get around to doing it eventually...

[Andrea Parodi]

I had the same problem to solve. I didn't was aware of redux-electron-store existence, so I solve it in a slightly different way.

Instead of keep store state in sync between process, I send needed actions around using ipc.

If you like the concept interesting, here are the modules I plan to extract on their own package. I'm using them here and here is how I setup the renderer process, here the main process.

I can easily share actions between BrowserWindow instances, and between BrowserWindow and main process (I use it e.g. to change tray icon when some acions occurs.)

[Burkhard Reffeling]

I didn't like the way redux-electron-store used the remote module to side-load one global store, so inspired by this talk, I implemented it slight differently.

I basically keep the store on the main process, and a proxy store in each renderer process (that gets initialised with the main store's state). Actions fired from the renderer have a meta.scope = 'main' property.
If such property is found, reducer middleware intercepts it, forwards it to the main store, and replays it there. Any actions received by the main store get replayed onto each proxy store, so none gets out of sync.

This approach has the advantage that renderers can also fire locally scoped actions (e.g. to change presentational state) without polluting the global store, but are always kept in the loop about global changes.

Check hardchor/timesheets@9d2c208 for the diff.

[Dave Jeffery]

@hardchor: Awesome, could be a good candidate for an npm module. :)

[Burkhard Reffeling]

@davej Well, would you believe it! It only took me 2 months, but I've finally gotten around to pulling it out of my project and into npm: https://www.npmjs.com/package/electron-redux

Feel free to play around, rip apart, and feedback 😄

@chentsulin My project (https://github.com/hardchor/timesheets) is based on electron-react-boilerplate. Fancy back-porting electron-redux into your boilerplate?

[Alex Morris]

I've looked through your time sheets repo and I have now implemented in a similar way using your npm module and its working great!

I'm just struggling and also unsure if there is any way of having actions dispatched in the main process appear in the dev tools or any log of them whatsoever, they appear to be firing and updating state, but I have no way of tracking what actions have and haven't been sent!
Alex

[Burkhard Reffeling]

@alexemorris Let's continue this discussion in https://github.com/hardchor/electron-redux/issues/new

[Amila Welihinda]

I think we should add a guide on how to add integration with electron-redux. Let's move this discussion to #968