Some general thoughts:

• As this is going to be released into v5.0.0, we can take a look at the existing API. Do you think it would be possible for middleware to support both scenarios, over adding a new concept in initialisers?
• Would it make more sense to manage the chaining/composition of the middleware internally, so that consumers don't need to use the create*Decorator functions, perhaps just taking an array of middlewares?
• It would be great if initialisers weren't always treated as async as it means a process with sync commands won't run sync?
• Do you think that the payload is the only thing that an initialiser will ever need? What about generic scenarios that might require the initialiser to mark some state in the store? isLoading as an example.
• It looks like there's some duplication across createInitializerDecorator and createCallbackDecorator which can probably be normalised (Possibly not relevant if we change how the middleware is passed)

@agubler

Some general thoughts:

• As this is going to be released into v5.0.0, we can take a look at the existing API. Do you think it would be possible for middleware to support both scenarios, over adding a new concept in initialisers?

Would something like providing an object for middleware with

{ 'before': {one or more before middlewares}, 'after': {one or more after middlewares} }

Make sense to you? I tried for an API where each middleware was run before and after, by receiving the payload and passing it to a next that returns the result. But it ended up feeling much more complicated to use when mostly you'd want one or the other. It also makes the order that they execute in less obvious.

@agubler

Some general thoughts:

• As this is going to be released into v5.0.0, we can take a look at the existing API. Do you think it would be possible for middleware to support both scenarios, over adding a new concept in initialisers?

Would something like providing an object for middleware with

{ 'before': {one or more before middlewares}, 'after': {one or more after middlewares} }

Make sense to you? I tried for an API where each middleware was run before and after, by receiving the payload and passing it to a next that returns the result. But it ended up feeling much more complicated to use when mostly you'd want one or the other. It also makes the order that they execute in less obvious.

could we have the middleware itself return the before and after? that way users just use middleware and don't need to know where it has to go. It also means middleware can have a before and after without the user having to specify the middleware twice.

@agubler @matt-gadd

I've made updates to address all your feedback.

Middleware now returns an object with optional before and after properties.

after has the same signature as the old middleware and before gets the payload as well as the store.

Instead of exposing the decorator it's just used internally and all the public facing APIs expect ProcessCallbacks directly.

@maier49 apologies for the late review on this. this looks really good to me, I just have one question on the ordering of the after calls. Do we think it should be in reverse order like in the PR and why? In my head I can't quite decide what the correct ordering should be, and which is less surprising to the end user.

@matt-gadd The thought process for the order is borrowed from some request hooks as the last interceptor that modifies the request might need to be the first to handle the response, for example for encrypting/decrypting. However, that doesn't really apply the same way to store processes, so I could be convinced either way on the ordering.

@maier49 I leaning towards the before and after middlewares being executed in the order that they are defined. If I had a process that defined middleware that only executed after the process, i think it would be surprising if they executed in reverse order.

const myProcess = createProcess('example', [ command ], [ afterOne, afterTwo ]);

@agubler That's updated now