When would process hook run after reducer?

[KevinAst]

Hi Jeff,

In your process hook docs you state that the process hook typically runs after the state has been updated (unless other logic delay's execution).

I'm not sure I fully understand the caveat of other logic delaying execution. The only thing I could think of was other logic having asynchronous validate/transform hooks, but even that would seem to also delay the reducer execution as well.

I have a couple of logic modules that are relying on the state to be updated, so I want to fully understand the scenario.

Can you enumerate just a bit?

Thanks for your time, and thanks for a great product!

[jeffbski]

@KevinAst Thanks for the question and the kind words.

Yes, in most common use cases the state will be updated before the process hook runs. The original action that triggered the logic to run has passed through any validate/transform hook and it will have been passed onto the next logic (and any other middleware below this).

A few less common scenarios that could delay the state being updated:

1. logic with a validate/transform hook that runs after this logic and which performs an asynchronous task before continuing. If everything is synchronous in the validate/transform then there will be no delay. Or if you configure any logics that might do async work in the validate/transform hooks to run first in the logic stack then that could help.
2. middleware that is configured to run after the logicMiddleware which does async work before continuing. It depends on the middleware as to whether it will just pass through or do other work. If these are configured before logicMiddleware then they won't come into play.
3. If your validate/transform hook changes the action type to a different type, then it will be dispatched to the top of the redux pipeline (so everything has a chance to see it, rather than falling through using next). This by itself wouldn't necessarily delay it, but again steps 1 and 2 apply to that action.

So the main thing is if you are doing async validate/transform code then that could delay an update, but only if those are below your other logic. Most of the time validate/transform logic code is synchronous so it is not an issue.

The middleware async is not normally an issue, but you can configure it to run before redux-logic if you need to.

Hopefully that helps clarify.

[KevinAst]

Thanks @jeffbski for your quick response.

Stated a slightly different way (if I understand what you are saying):

1. State change (i.e. reducer execution) only occurs after ALL validate/transform hooks give the thumbs up (i.e. for ALL logic modules monitoring that action). As a result any one of the logic module validate/transform hooks could delay state change, when async behavior is employed.

2. On the other hand, a process hook is executed solely on the determination of it's own validate/transform. I think you typically invoke the reducer before the process hook, but if the reducer execution is being held up by a downstream asynchronous validate/transform, then the current process hook is invoked before the reducer.

If this is true, I guess it kinda makes sense.

Assuming my summary is correct, would it be advantageous to delay ALL process hooks till after ALL validate/transform hooks had resolved? Regardless of whether the reducer was executed or not, you could have a "stake in the ground" that ALL process hooks would see the end-state result of the dispatched action.

In my mind, this seems more deterministic.

Thoughts?

In regard to other middleware, why would anyone ever want other middleware (with the advent of redux-logic)? I'm kidding (in a way), but seriously: I previously used 3 or 4 middleware services, and after I started using redux-logic all other middleware just naturally disappeared (with very simple straight-forward logic modules).

[jeffbski]

@KevinAst That seems like a great idea and I think it would be relatively easy in the new design I am considering which manages each of those features separately. That does seem like that would be more deterministic.

I would also agree with you regarding not needing any other middleware after adding redux-logic. That's been the case for me too. Of course we do want to make it easy for people to co-exist and to transition to redux-logic over time.

Thanks for the wonderful discussion and ideas. I'll carefully consider this idea but it does seem like the right way to go.