Local vs. aliased actions

[percyhanna]

I've been looking to port our Chrome extension to using this module instead of our own home-rolled implementation. One significant blocker is the requirement to separate local state from shared state, which is a separation of local actions vs. background/shared actions.

I'm also looking at electron-redux as an alternative for our Electron build, and it has a concept of separating local actions from alias actions.

A separation of these concerns would also address some of the performance concerns that have been mentioned (#10, #143). Using shared state for storing input state is bad (unless your intentions are to have text inputs update in-sync across all open tabs, but that doesn't seem common).

There is a fundamental difference between app state and UI state. In SPA, the two can live together happily without any issues. But with Chrome extensions + background pages, the two need to be separated. The same issue exists in Electron apps if you're sharing state in the main process across multiple rendering processes, but each rendering process needs its own UI state.

This research has led me to conclude that perhaps a single module could be used for both Chrome and Electron projects, since the concept of a Proxy Store is not unique to Chrome, and the only change would be the middleware for how messages are passed between the main process (background page in Chrome) to the renderers (tabs/popups in Chrome).

I'm not sure if this is more of a question or proposal to make a change, or what. I'm happy to provide some PRs to add local vs. aliased actions, but I wonder if that time could be better spent refactoring electron-redux to support Electron and Chrome (and any other custom proxy "bridge"/middleware).

[percyhanna]

Or maybe I'm completely missing the ability to use local actions somehow, which is possible.

[marcokam]

I think there definitely are use cases for having local actions, and the more general concept of having local unsynced state vs global synced state.

For example, we have a chrome extension that uses this project, where most of the user specific data is retrieved once from the server and stored in the main store in the background. We also inject a frame into each browser tab where we have a content script defined, and that runs a React powered app.

Our app does things like searching for emails, twitter handles, etc and retrieving information about people/companies that our system knows about. The data returned from these searches are specific to the context of the tab and application the user is in, so it is not shared between tabs, but there is a need to access the shared user information as well.

At the moment we accomplish this by having a regular local redux store provided to each react app instance. We also have a proxy store available in the same context, where we subscribe to changes and dispatch a single replace action on the local store. This allows us to connect to one store that has both local and shared state.

Currently we still manually import a reference to the proxy store when we need to dispatch to the global store, but I think that can also be handled by some custom middleware.

I actually wasn't aware of the electron-redux project, and after reading their docs I think their concept of having scoped actions and not necessarily having exactly the same state between stores in different contexts would be really useful.

We don't currently have a need to build an electron app, so our use for a unified project would only be in chrome at the moment. I think some implementation challenges would be to make sure code not required for the platform you are building on isn't automatically included if you import the project.