Proposal: add `subscribe` to middlewareAPI

[jonnyreeves]

Expand the existing middlewareAPI to include store.subscribe, ie:

var middlewareAPI = {
  getState: store.getState,
  dispatch: (action) => dispatch(action),
  subscribe: store.subscribe
};

Motivation

Stateful middleware implementations wish to observe the store to know when the store' state has been modified and trigger a side-effect; for example - OAuth middleware will detain CALL_API actions when it detects an expired OAuth Grant until the store has been updated with a new, valid Grant:

export function createMiddleware() {
  var detainedActions = [];

  return store => next => action => {
      if (!action[CALL_API]) {
        return next(action);
      }
      if (store.getState().oauthGrant.expired) {
        detainedActions.push(action);
        await obtainNewOauthGrant(store);
        redispatchDetainedActions(store.dispatch);
      } else {
        // ... sign the request.
    }
  }  

  async function obtainNewOauthGrant(store) {
    const unsubscribe = store.subscribe(() => {
      if (!store.getState().oauthGrant.expired) {
        unsubscribe();
        resolve();
      }
    });
    store.dispatch(obtainNewGrant());
  }

  function redispatchDetainedActions(dispatch) {
    // ... redispatch detained actions.
  }
}

[acdlite]

Not sure about this. My current thinking is that if middleware needs to subscribe, it should be implemented as a store enhancer. This is how Redux DevTools and Redux Router works. We haven't documented this pattern yet, but we likely will in the future.

[acdlite]

Example of a store enhancer:

const storeEnhancer = createStore => (reducer, initialState) => {
  const store = createStore(reducer, initialState);
  // do whatever you want with store object
  return store;
};

[gaearon]

I agree with @acdlite on this. Middleware is meant to be “pass through” thing, anything more complicated should either be a store enhancer or just a function taking the store and calling subscribe on it for its purposes.

[jonnyreeves]

@acdlite, @gaearon, I trust your judgement on this; but I have been struggling with this particular detail for a while; there are already examples of middleware doing more than just "passing through" actions, for example, the API middleware in the real-world example.

From what I can see, Store enhancers do not have access to actions as they pass to reducers, so are therefore not in a position to intercept, sign and / or detain CALL_API actions when required by the app's business logic; likewise a function which wraps the store also has no way to access this flow - middleware appears to be the only way to tap into it.

Exposing the subscribe method in the middlewareAPI does not change the current signature for consumers and does not immediately result in bad-practice and is the only way to allow stateful middleware to work without resorting to importing store instances (which quickly leads to circular dependencies).

[johanneslumpe]

@jonnyreeves The store enhancer has to pass the action to the reducer so yes, it is very much in the position to intercept actions.

You can add enhancers before your middleware and after and even do things like middleware -> enhancer -> middleware -> another enhancer. You are in full control. So if you wanted to prevent the CALL_API actions, you could just create a store enhancer and add it to the chain before your api call middleware.

[jonnyreeves]

@johanneslumpe Thank you for the clarification; apologies for jumping to conclusions without reading the code.

[johanneslumpe]

@jonnyreeves no worries :)

[acdlite]

@jonnyreeves It may help to know that applyMiddleware() itself is a store enhancer :) https://github.com/rackt/redux/blob/master/src/utils/applyMiddleware.js

[jonnyreeves]

Sorry to bring this up again; I believe the real problem I'm facing is that I need to trigger a side effect ( function) after an action has been reduced and the store's state updated.

It would appear that I am in need of a side-effects processor, similar to #569, as a result I knocked up a simple proof of concept side-effect processor which looks for meta.sideEffects on an action as it passes through to the reducer:

export default function sideEffectorExecutor(next) {
  return (reducer, initialState) => {
    const store = next(reducer, initialState);
    let pendingSideEffects;
    let unsubscribe;

    // custom `store.dispatch` implementation which records side-effects on the
    // action object and executes them on the next store update.
    const dispatch = (action) => {
      const { meta: { sideEffects } = {} } = action;

      if (Array.isArray(sideEffects)) {
        pendingSideEffects = sideEffects.concat();

        // one-shot subscription to invoke side-effects after the next store update.
        unsubscribe = store.subscribe(() => {
          unsubscribe();

          // process all side effects.
          pendingSideEffects.forEach(sideEffect => sideEffect());
          pendingSideEffects = null;
        });
      }

      // Pass the action through.
      store.dispatch(action);
    };

    return { ...store, dispatch }
  };
}

One issue I am facing with this approach is that I can't provide a meaningful store.dispatch function through to the side-effect (ie: sideEffect({ dispatch: store.dispatch })) as the supplied dispatch reference will not be decorated by another other store-reducers present on the 'final' store - I'm guessing there may be no solution to this problem as redux itself does not hold a reference to the final composed store instance, only the user's own code does.

[jlongster]

Not sure if this is relevant, but I have thought about this a lot. There are a few times where I really do need to "wait" on an action coming through the system at a later time. And I don't know what started the I/O, so I can't block on the promise (by composing action creators), all I know is that it's already started and I need to wait for it to finish.

I think I found a rather elegant solution to this, and I agree that we shouldn't (edit, I previously wrote "should") expose subscribe which is ripe for abuse. I created a middleware called "wait-service", and I call it a service because it's actually stateful. That's not a problem though because it's not state that I care about saving. You can see it here: https://github.com/jlongster/gecko-dev/blob/debugger-refactor-sources-4/devtools/client/shared/redux/middleware/wait-service.js

Basically, with this you can now dispatch an action that will fire something at a later time based on a predicate:

const { NAME: waitService } = require('wait-service.js');

dispatch({
  type: waitService,
  predicate: action => (action.type === "ADD_ITEM" &&
                        action.status === "done"),
  run: (dispatch, getState, action) => {
    // dispatch and getState are what you expect. `action` is the
    // action that fulfilled the predicate.
  }
});

I have found that I've been to solve some really complex async scenarious with this simple service that has a little state: a list of waiting actions that check each action coming through the system.

(I've been meaning to write a blog post about this)

[jlongster]

I may have mis-read the OP; looks like you just need the dispatch function. You can get this by receiving it in the middleware when its instantiated; check the wait-service.js signature.

[jonnyreeves]

@jlongster, nope - you're spot on. I have middleware that contains state (detained actions) and I want to re-dispatch those actions when a predicate is met on the store.

The later request for dispatch is in response to using a store enhancer to try and achieve the same effect.