Data object and serial preprocessors

[Paul Tiseo]

So, if a preprocessor follows another, and the earlier one (lower priority) adds information to the data object, should the later one (higher priority) be able to see those properties?

For example, I have a preprocessor with priority 1100 that pulls an ID out of a token, and adds it to data.token.id. I can easily access that in actions. But, in a preprocessor with priority 9000, I don't see the same property. Am I supposed to see it or not?

[Evan Tahler]

You certainly should.  

Can you confirm that both of your middleware are either (a) global or (b) invoked by the same action?  For extample, this logs the proper value:

'use strict';

module.exports = {

  loadPriority:  1000,

  initialize: function(api, next){

    api.actions.addMiddleware({

      name: 'A',

      global: true,

      priority: 1000,

      preProcessor: function(data, next){

        data.thing = 'stuff';

        next();

      }

    });

    api.actions.addMiddleware({

      name: 'B',

      global: true,

      priority: 2000,

      preProcessor: function(data, next){

        api.log(data.thing);

        next();

      }

    });

    next();

  }

};

[Paul Tiseo]

The auth preprocessor that pulls the ID is not set to be global, because not all actions should have it by default.

So, I have an action that has a) the non-global auth preprocessor, and b) the global audit preprocessor. With this, the audit preproc won't get a data param that contains the items lifted by the auth one?

[Evan Tahler]

I think we've got an order-of-operations problem here:

1) All global processors happen before any per-action processors 

2) While the priority order is maintained for the global middleware, the actual order you include the names of your local middleware matters within the actions themselves, as non-global middlewares shouldn't have priority.

Is this confusing?  Should we use priority order in all cases?

[Paul Tiseo]

Ah! This should definitely find it's way into the middleware section of the docs. Or, I missed it completely.

I think your current implementation a reasonable design. The only other way would be to somehow compose an "all initializer pipeline" on a per-action basis, which I assume is not only a big refactor, but would be quite a breaking change.

In my case, a simple fix is that I have to move my auditing middleware to being local and make sure everyone includes it in all actions. The burden is on the dev to make sure to include the middleware, which is unfortunate, but better than the alternative.

[Evan Tahler]

Nope, it's not in the docs.  

Wold you mind adding it around here?    http://www.actionherojs.com/docs/#action-middleware

Thanks!