First mutation

[oliviertassinari]

I'm using the latest version of this repository.
The @@router/UPDATE_LOCATION action do not reach the end of my middleware chain during the first mutation of the state.
I'm wondering if this is intentional, or an issue with this project (it's working with redux-router).

Here is my middleware chain in case you ask:

import promiseMiddleware from 'redux-promise';
import thunk from 'redux-thunk';

...

  middleware = applyMiddleware(
    promiseMiddleware,
    thunk,
    reduxRouterMiddleware,
    analyticsMiddleware
  );

The issue for me is that, I want to send every @@router/UPDATE_LOCATION event to google analytics but the first page is missing.

[oliviertassinari]

For now, I'm using this fix at the end of my reducer calls.

  analyticsMiddleware({
    getState: () => state,
  })(() => {})(action);

[jlongster]

The middleware chain you posted does not include the analyticsMiddleware you have above. Can you paste the full code you're working with?

[oliviertassinari]

Sure, here is my analyticsMiddleware.js:

import {UPDATE_LOCATION} from 'redux-simple-router';
import pluginAnalytics from 'plugin/analytics';

function analyticsMiddleware(store) {
  return next => action => {
    const result = next(action);

    if (action && action.type === UPDATE_LOCATION) {
      pluginAnalytics.trackView(store.getState().get('routing').location.pathname);
    }

    return result;
  };
}

export default analyticsMiddleware;

[timdorr]

Ah, it's because the history listener is being set up and is dispatching before the rest of the middleware is applied to the store by applyMiddleware. This may actually be a redux bug....

We could hack around this with setTimeout, but I'm not a huge fan of that approach.

[timdorr]

Opened up reduxjs/redux#1240. We'll see if anything happens there.

[damassi]

This is happening to me as well after upgrading. I have an authorization / restricted routes flow and the way I'm getting around it is by triggering a fake system action on init, which will then process my middleware as it did before.

[timdorr]

Well, I guess we'll have to defer our initial listener with setTimeout. That's the only way around it I can see. I'm open to PRs if someone has a better solution. I'll try to get this tested, fixed, and released soon.

[timdorr]

Thought I had a fix, but didn't work. setTimeout just makes listening async, which works fine in the browser, but busts everything in the server context.

[timdorr]

This should be solved once #259 settles, as it operates on an instantiated store which will have all of its middleware set up.

[gabrielhpugliese]

For those who are using it, the upgrade fixed the problem? My version is 2.0.4 and I see this happening.

[oliviertassinari]

Yes, it does.