Can middleware trigger reducer execution?

[brianegan]

Can middleware trigger reducer execution?

[brianegan]

Hey hey -- the example you've posted will produce an infinite loop (b/c it will always keep dispatching a new action), but I think I get the overall Q.

The next function will forward the action to the next middleware in the chain synchronously. If all of your Middleware synchronously call next, it should reach the reducer first. Do you have any other middleware further down the chain that might be delaying the call to next by wrapping the invocation in an async call of some kind?

This test works, for example. It verifies that the action forwarded by the next function reaches the reducer first.

    test('next actions reach reducer first', () async {
      final List<dynamic> actions = <dynamic>[];
      void middleware(
        Store<String> store,
        dynamic action,
        NextDispatcher next,
      ) {
        next(action);

        if (action == 'I') {
          store.dispatch('F');
        }
      }

      String reducer(String state, dynamic action) {
        actions.add(action);
        return state;
      }

      final store = new Store<String>(
        reducer,
        middleware: [middleware],
      );

      store.dispatch('I');

      expect(actions, ['I', 'F']);
    });

[kentcb]

Thanks Brian. I figured out what confused me yesterday when looking at this. Check this out:

test('next actions reach reducer first', () async {
  final List<dynamic> actions = <dynamic>[];
  void middleware(
      Store<String> store,
      dynamic action,
      NextDispatcher next,
      ) {
    next(action);

    if (action == 'Approve') {
      store.dispatch('Save');
    }
  }

  String reducer(String state, dynamic action) {
    actions.add(action);
    return state;
  }

  final store = new Store<String>(
    reducer,
    middleware: [
      new LoggingMiddleware.printer(),
      middleware],
  );

  store.dispatch('Approve');

  expect(actions, ['Approve', 'Save']);
});

Even though this test passes (proving that reducers are running when expected), the logging middleware (which is all that I was using to analyze the situation yesterday) outputs:

[INFO] LoggingMiddleware: {Action: Save, State: null, ts: 2018-05-04 10:48:06.755677}
[INFO] LoggingMiddleware: {Action: Approve, State: null, ts: 2018-05-04 10:48:06.764199}

This is the opposite of what I would intuitively expect, and I don't quite have my head around why this is. I note that swapping the order of my middleware helps:

    middleware: [
      middleware,
      new LoggingMiddleware.printer(),
    ],

Gives me:

[INFO] LoggingMiddleware: {Action: Approve, State: null, ts: 2018-05-04 10:49:44.685586}
[INFO] LoggingMiddleware: {Action: Save, State: null, ts: 2018-05-04 10:49:44.694610}

Should my logging middleware always be at the end of my middleware pipeline? Conceptually, when I think of dispatching an action, I imagine it traveling through the middleware in the order of definition (so putting the logging middleware first made sense to me, since I figured it would be the first thing to run on each action received). Am I misguided here?

[brianegan]

Heya Kent,

Sorry, traveling the past few days! So, it looks like you found a bug in the Logger implementation :) I'll push up a fix next week when I'm back in action :)

Best,
Brian

[brianegan]

Heya @kentcb -- I tried to fix this bug, but it caused other issues. The only way to get it to work consistently is to put the logger as the last middleware in the chain, which I found is the same restriction as the logging middleware for Redux.js as well.

The problem? The middleware must call next before logging so it has access to the updated State. However, this also triggers the bug you're seeing here. The only fix is to put the loggingMiddleware as the last middleware in the array.

I've updated the documentation to reflect this! Sorry about the confusion.