electron-event-flux

redux-electron-store

This library solves the problem of synchronizing Redux stores in Electron apps. Electron is based on Chromium, and thus all Electron apps have a single main process and (potentially) multiple renderer processes, one for each web page. redux-electron-store allows us to define a store per process, and uses ipc to keep them in sync. It is implemented as a redux store enhancer.

This library only works if the data in your store is immutable, as objects are compared by reference to determine changes. The data being synchronized must also be pure JavaScript objects.

Installation

npm i redux-electron-store --save

Usage

Main Process

import { createStore, applyMiddleware, compose } from 'redux';
import { electronEnhancer } from 'redux-electron-store';
 
let enhancer = compose(
  applyMiddleware(...middleware),
  // Must be placed after any enhancers which dispatch
  // their own actions such as redux-thunk or redux-saga
  electronEnhancer({
    // Necessary for synched actions to pass through all enhancers
    dispatchProxy: a => store.dispatch(a),
  })
);
 
// Note: passing enhancer as the last argument to createStore requires redux@>=3.1.0
let store = createStore(reducer, initialState, enhancer);

Renderer / Webview Process

let enhancer = compose(
  applyMiddleware(...middleware),
  electronEnhancer({
    dispatchProxy: a => store.dispatch(a),
  }),
  DevTools.instrument()
);
 
let store = createStore(reducer, initialState, enhancer);

Filters

In the renderer process, an important parameter that can improve performance is filter. filter is a way of describing exactly what data this renderer process wishes to be notified of. If a filter is provided, all updates which do not change a property which passes the filter will not be forwarded to the current renderer.

A filter can be an object, a function, or true.

If the filter is true, the entire variable will pass through the filter.

If the filter is a function, the function will be called on every dispatch with the variable the filter is acting on as a parameter, and the return value of the function must itself be a filter (either an object or true)

If the filter is an object, its keys must be properties of the variable the filter is acting on, and its values are themselves filters which describe the value(s) of that property that will pass through the filter.

Example Problem:

I am creating a Notifications window for Slack's application. For this to work, I need to know the position to display the notifications, the notifications themselves, and the icons for each team to display as a thumbnail. Any other data in my app has no bearing on this window, therefore it would be a waste for this window to have updates for any other data sent to it.

Solution:

// Note: The Lodash library is being used here as _
let filter = {
  notifications: true,
  settings: {
    notifyPosition: true
  },
  teams: (teams) => {
    return _.mapValues(teams, (team) => {
      return {icons: true};
    });
  }
};

More options are documented in the api docs, and a description of exactly how this library works is on the way.

Hot Reloading Reducers

Hot reloading of reducers needs to be done on both the renderer and the main process. Doing this requires two things:

• The renderer needs to inform the main process when it has reloaded

  // In the renderer process
  if (module.hot) {
    module.hot.accept('../reducers', () => {
      ipc.sendSync('renderer-reload');
      store.replaceReducer(require('../reducers'))
    });
  }

• The main process needs to delete its cached reducers data

  // In the main process
  ipcMain.on('renderer-reload', (event, action) => {
    delete require.cache[require.resolve('../reducers')];
    store.replaceReducer(require('../reducers'));
    event.returnValue = true;
  });

  • Note: Individual reducer files may also need to be deleted from the cache if they have been required elsewhere in the application

How it works

Initialization

1. The main process creates its store
2. When a renderer is created, it copies the current state from the main process for its own initial state
3. The renderer then registers itself with the main process along with its "filter"

Runtime

1. An action occurs in either the renderer or the main process
2. If it was in a renderer, the action is run through the reducer and forwarded to the main process
3. The main process runs the action through the reducer
4. The main process compares its state prior to the reduction with the new state, and with reference checks (hence the need for immutable data), it determines what data in its store changed
5. The main process then iterates through each registered renderer. If the data that changed is described in that renderer's filter, the main process IPC's over an action with data: { updated: {...}, deleted: {...} } properties
6. The renderers that receive that action will then merge in that data, thereby staying in sync with the main process, while not repeating the processing done by the reduction

License

MIT