Implement middleware

[gaearon]

Similar to rpominov/fluce#4

[gaearon]

This is how Redux works now:

----[action]---->  [Redux] ----[state]---->
               (calls stores)

This is how I want it to work:

 ----[action]----> | ? | ----[action]---> [Redux] ----[state]----> | ? | ----[state]---->
                   | ? |                                           | ? |
                   | ? |                                           | ? |
                   | ? |                                           | ? |

Things in the middle are called interceptors. They are async black boxes. They are the extension points of Redux. There may be an interceptor that logs whatever goes through it. There may be an interceptor that transforms the values passing through it, or delays them. An interceptor should be able to fake the data, i.e. fire an arbitrary action at any point of time even if there's nothing being processed at the moment. This will be useful for time travel.

I think I found a nice API for interceptors. I'm going to rewrite Redux dispatcher to use them now. Even observing changes to stores can then be implemented as a (built-in) interceptor.

The interceptor signature is sink => payload => (). See the proof of concept below.

// Utilities
function noop() { }
function compose(...interceptors) {
  return sink => interceptors.reduceRight(
    (acc, next) => next(acc),
    sink
  );
}
function seal(interceptor) {
  return interceptor(noop);
}

// Dispatcher implementation
function getFirstAtom(stores) {
  return new Map([
    for (store of stores)
      [store, undefined]
  ]);
}
function getNextAtom(stores, atom, action) {
  if (!action) {
    return getFirstAtom(stores);
  }
  return new Map([
    for ([store, state] of atom)
      [store, store(state, action)]
  ]);
}
// Dispatcher is an interceptor too
function dispatcher(...stores) {
  stores = new Set(stores);
  let atom = getFirstAtom(stores);

  return sink => action => {
    atom = getNextAtom(stores, atom, action);
    sink(atom);
  };
}

// What can interceptors do?
// These are simple examples, but they show the power of interceptors.
function logger(label) {
  return sink => payload => {
    console.log(label, payload);
    sink(payload);
  };
}
function repeater(times) {
  return sink => payload => {
    for (let i = 0; i < times; i++) {
      sink(payload);
    }
  };
}
function delay(timeout) {
  return sink => payload => {
    setTimeout(() => sink(payload), timeout);
  };
}
function filter(predicate) {
  return sink => payload => {
    if (predicate(payload)) {
      sink(payload);
    }
  };
}
function faker(payload, interval) {
  return sink => {
    setInterval(() => sink(payload), interval);
    return noop;
  };
}

// Let's test this
import { counterStore } from './counter/stores/index';
import { todoStore } from './todo/stores/index';
import { increment } from './counter/actions/CounterActions';
import { addTodo } from './todo/actions/index';

let dispatch = seal(compose(
  // faker(increment(), 1000),
  // filter(action => action.type === 'INCREMENT_COUNTER'),
  // repeater(10),
  logger('dispatching action:'),
  dispatcher(counterStore, todoStore),
  // delay(3000),
  logger('updated state:')
));

dispatch({ type: 'bootstrap' });
dispatch(increment());

setTimeout(() => {
  dispatch(increment());
  dispatch(addTodo());
}, 1000);

[rpominov]

Pretty solid, I like it. My approach looks kind of "dirty" compared to it, but I think it a bit more practical. Two notable differences from what I'm going to do in fluce:

1. You have two points where programmer can insert an interceptor — before and after dispatcher. Maybe there will be difficulty with API, maybe not — don't know )
2. In fluce the reducer function will be available in middleware, and here only dispatcher will have access to such reducer. I used reducer in transactions-middleware, so it seems necessary to have access to it in middleware/interceptor.

[gaearon]

Yeah I'll need to battle test it. Maybe need to make it more practical, maybe not :-)
Transactions are a good testbed indeed.

[gaearon]

You have two points where programmer can insert an interceptor — before and after dispatcher.

I think the interceptors I described here are too low-level. In practice, each interceptor should wrap some other interceptor. This way it's possible for each interceptor to add intercepting functions before and after the nested interceptor.

I used reducer in transactions-middleware, so it seems necessary to have access to it in middleware/interceptor.

Indeed, my proposal needs to be changed to support transactions. It might be that the API is enough, but the dispatcher should accept state, actions as the payload, and output state. Dispatcher should not store the state. This goes well with “storing state is just an optimization, in theory it should be equivalent to reducing all the actions”. The state memoization could then be implemented as the outermost interceptor.

Hopefully this doesn't sound too crazy.. I'll try to get something running tomorrow.

[rpominov]

It might be that the API is enough, but the dispatcher should accept state, actions as the payload, and output state.

(state, actions) -> state looks like the reducer function only accepts multiple actions. Or did you mean that the dispatcher outputs the state by calling a callback rather than simply return it?

Anyway, looks promising. Will be interesting to see more details tomorrow.

[KyleAMathews]

Why not middleware just (conceptually) be another store? Why a new concept for interceptors?

Per the gist discussion, if stores can compose stores then middleware is just an intermediate store?

[rpominov]

It won't be powerful enough as another store. A middleware should be able to fire actions, replace current state etc.

[gaearon]

For extra clarification, the middleware is not meant to be used by the lib users. It is meant for tool builders (e.g. DevTools extensions).