Shortcomings of the current applyMiddleware and composing createStore.

[joonhocho]

export default function applyMiddleware(...middlewares) {
  return (next) => (reducer, initialState) => {
    var store = next(reducer, initialState)
    var dispatch = store.dispatch
    var chain = []

    var middlewareAPI = {
      getState: store.getState,
      dispatch: (action) => dispatch(action)
    }
    chain = middlewares.map(middleware => middleware(middlewareAPI))
    dispatch = compose(...chain)(store.dispatch)

    return {
      ...store,
      dispatch
    }
  }
}

Looking at the source code above, applyMiddleware creates a new store object and overrides dispatch with newly composed dispatch, and returns the new store.

There are shortcomings of this approach that I have experienced.
Take a look at the following scenario:

compose(
  applyMiddleware(A),
  reduxRouter(...),
  applyMiddleware(B)
)(createStore)

Because of the current implementation of applyMiddleware and compose to enhance createStore,
middleware A and middleware B will not share the same dispatch.
That means dispatch(action) in A and dispatch(action) in B will go through different code paths and may yield completely different outcomes, and it's confusing and difficult to debug.
Also, there is no way for middleware A to dispatch any reduxRouter actions such as pushState, replaceState, etc as those actions will never go through reduxRouter middleware.

My proposed solution would be:

1. Create only one store instance, and do not replace it by composeing createStore.
2. Enhance it by composing and replacing dispatch function on the only store instance.
3. Share the store, not dispatch across all middlewares.

This way, there is only one universal store instance, and store.dispatch will always go through the same code path and yield the same outcome regardless of which middleware.

[gaearon]

I think we need to discourage "too powerful" store enhancers that introduce such problems. It's not nice that people start having two middleware chains before and after the Redux Router. This really complicates Redux and isn't quite how I imagined it would be used. Rather than allowing this use case, I would like to better understand why you need two different middleware chains. Is this a workaround for some deeper issue?

1. Create only one store instance

AFAIK this doesn't work with the DevTools. They want there to be two stores: the "real" store with DevTools state and the "facade" store that your app sees and interacts with. This was the design constraint of the store enhancers as they are now.

[joonhocho]

I was trying to create an auth middleware that redirects user to login page by firing replaceState action when current action.requireAuth is true and state.auth.user is not set.
This does not work because auth middleware's dispatch does not work properly with any of redux-router`s action creators due to the stated reasons from the previous comment.

[gaearon]

Why not put middleware before Redux Router?

[mikebarnhardt]

@gaearon When you put a middleware before Redux Router you can't see Redux Router's dispatches.

I ran into a similar issue when trying to add an analytics middleware so that when the routerDidChangefired I could call ga.push() or whatever. The only way to get it working was to add another middleware after reduxRouter, but you need things like thunk to be first in the middleware chain so that async dispatches can still use pushState.

I agree about creating "too powerful" store enhancers. Do you think the redux-router middleware is too powerful? Should it be included in applyMiddleware() instead?

[joonhocho]

As @mikebarnhardt said, when you have a middleware chain A -> B -> C, B can listen to actions that A passes on, but cannot send any actions to A. Whenever B sends any action it will always start from C.

At first without looking at the source code, I expected it to work like the following:

Root dispatch -> A -> B -> C -> Final dispatch.
And any actions created at any point by any middleware always go through the same path, root -> A -> B -> C -> final.
I think it's similar to how the 'flux' works as well in principle. All events going through same action -> dispatch -> store -> view path.

[joonhocho]

It was my mistake to accidentally close the issue. I hate the button placement for close issue.

[gaearon]

I'm currently busy so I'll try my best to get back to this when I'm more available.
Sorry!

[mikebarnhardt]

Because I felt the reduxRouter(...) middleware was too independent, I went back to using basic react-router and hooking into history.listen(...) for my purposes. I know that it removes the router state from the Redux store, but I haven't run into any issues using history.pushState(...) in my action creators. I know this probably won't work for everyone, though.

[acnovais]

Ran into this issue today.
While developing a middleware, one has the impression that by calling store.dispatch the action would go through all the middlewares from the beginning.
This was a bit frustrating to find.

[gaearon]

It does go through all the middlewares inside a single applyMiddleware call. I don't see an easy way to make it jump to the first middleware chain when there any many such chains. In any case we don't suggest to make too powerful middleware. It's meant for simple transformations and not complex logic.

[acnovais]

Yes, that was my current solution.
Aggregate my middlewares in a single applyMiddleware chain.

I'm using middlewares for transformations, API calls, routing and flow control. I don't think I'm having very complex logic. Maybe the flow control is the most complex: the idea is to allow an action to reach the store based on the current state. Do you think this makes sense?