Skip to content

Add multiple redux stores support #310

@MaximKalinin

Description

@MaximKalinin

Is your feature request related to a problem? Please describe.
The electron-redux has really easy-to-use API that helps a lot when working on electron applications. However, it has some limits in advanced usage. Specifically, support of multiple redux stores.

In most cases, this wouldn't be an issue at all, however, my team faced it when trying to apply microfrontend approach to electron app.

In this case we create multiple store instances and, of course, use electron-redux middleware. Since the module sends all the actions through single channel, redux store gets mixed unpredictably. Also, global.getReduxState function doesn't work as expected.

Describe the solution you'd like
So I would like to have an opportunity to work with different instances of the store.

Ideally, it shouldn't break current API since it is an advanced feature. I was thinking about three ways of realisation:

  1. Transform all the functions to higher order functions that would accept name of the channel and use it later, e.g.:
applyMiddleware(forwardToMain('redux-1'));
getInitialStateRenderer('redux-1')();
replayActionRenderer('redux-1')();
  1. Export a only factory instead that would accept channel name and return all the methods:
import {factory} from 'electron-redux';

const {forwardToMain, getInitialStateRenderer, replayActionRenderer} = factory('redux-1');

applyMiddleware(forwardToMain);
getInitialStateRenderer();
replayActionRenderer();
  1. Adopt all the exposed functions based on arguments to handle both standard and advanced usage:
import {forwardToMain, getInitialStateRenderer, replayActionRenderer} from 'electron-redux';

applyMiddleware(forwardToMain); // this would work
applyMiddleware(forwardToMain('redux-1')); // this would also work

Describe alternatives you've considered
I already used myself the first approach in my fork since it's the easiest to implement.

I also understand that for most of the use cases it makes no sense to implement this logic so it's fine for me to keep a fork for this specific case only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions