[Fixed #750] Flow actions mutations not syncing to Redux DevTools.

[bourquep]

By only hooking into the onAction notification, the Redux middleware was handling flow (async) actions at their beginning, where the state has not changed yet. So this MR injects another middleware to intercept flow_return action types, which is when the async action is done and the new state is available.

Ideally, we would exclude the regular action type for these, but at the time the middleware is invoked with call.type = "action" there is no way to determine if this is in fact an async action.

So, when an async action is invoked, the Redux DevTools will display:

myAction
myAction [flow_return]

And it's the [flow_return] one that will include the new state.

There weren't any existing tests for the Redux middleware, and I wouldn't really know how to implement them (looks like it would require mocking remotedev).

[xaviergonz]

@bourquep makes me wonder, would it make sense for all the flow types to be shown on the redux dev tools?
the point being, what if a flow_resume of action A changes property (PA), then flow_resume of action B changes property PB, and then flow_return of B changes PB2, would the devtools assume PA, PB and PB2 changed because of action B because the resume ones were not tracked?

[xaviergonz]

also while at it I'd refactor the "onAction" code to be inside the new middleware so there's less duplicated code

[xaviergonz]

I'd probably remove && call.type === "flow_return" and the onAction code

[bourquep]

would it make sense for all the flow types to be shown on the redux dev tools?

This is what I did at first, but the result in devtools was a lot of "noise", at least in my use cases. For example, I have an async action that fetches updates from the backend via 3 different API calls and consolidates the result into a snapshot that is applied to my local MST tree.

In that case, I have 3 yields in my flow, but no state change in between them. The consolidated snapshot is only applied after the last API call.

So I ended up with useless resume actions logged to RDT, with no state delta.

But I agree that there are indeed uses cases where it would make sense to log all the flow types.

Ideally, the programmer should be able to annotate the flow to indicate which steps should be logged or not. But I am not sure how this could be done.

I'll experiment with ways to represent the various flow types in RDT, maybe there's a way to name the actions so the output is clearer (e.g. hierarchical by using whitespace or emojis).

[xaviergonz]

or maybe it could detect if there was no change between the last snapshot and the new one and if that's the case then avoid showing the event (though that might be kind of slow for big states).

Maybe keeping a counter of json patch changes and when an action comes

  if (deltaPatches <= 0) skip logging
  else log and deltaPatches = 0;

?

This approach would also hide the actions at the start of a flow that actually do nothing.

And if this was somehow configurable even better (something like skipIdempotentEvents or whatever)

[bourquep]

I have tried various things, but each attempt results in Chrome running out of memory. Not sure if it's an issue with devtools or with mst-middleware, but I don't have time right now to look into it.

[bourquep]

Closing this PR in favor of #1035