mobx-state-tree icon indicating copy to clipboard operation
mobx-state-tree copied to clipboard

createActionTrackingMiddleware2 doesn't seem to differentiate between flow types and action type

Open missyjeanbeutler opened this issue 4 years ago • 3 comments

Bug report

  • [x] I've checked documentation and searched for existing issues
  • [x] I've made sure my project is based on the latest MST version
  • [ ] Fork this code sandbox or another minimal reproduction.

Sandbox link or minimal reproduction code https://codesandbox.io/s/mobx-state-tree-middleware-demo-forked-h8tn7?file=/index.js

Describe the expected behavior When using createActionTrackingMiddleware2, I would expect that a flow generator action would have a call type of flow_*.

Describe the observed behavior Instead, the call type is only ever action from what I can tell which makes filtering out call types by synchronous vs asynchronous impossible. Am I missing something? Some help would be much appreciated :)

missyjeanbeutler avatar Apr 07 '21 23:04 missyjeanbeutler

Hi @missyjeanbeutler!

You are right. There is nothing in the call with type action itself that differentiates between synchronous and asynchronous actions. createActionTrackingMiddleware2 only invokes the filter on the initial call with type action, so it might not fit your use case.

Asynchronous actions do however create a call with type flow_spawn with a parentEvent referencing the action that created it, so you might be able to use that instead.

EmilTholin avatar Apr 10 '21 12:04 EmilTholin

Thanks for the response! I'm trying to use a modified version of Atomic to revert actions that result in error. The issue I'm having though is with failed API requests that I was handling in my try/catch are now being reverted as well. I want to filter out flow functions for this reason but I can't with createActionTrackingMiddleware2. If you have any other ideas on how I could approach this, it would be much appreciated.

missyjeanbeutler avatar Apr 13 '21 16:04 missyjeanbeutler

Interesting. Maybe you could exploit the fact that synchronous actions that fail can be caught in a regular try/catch, but asynchronous actions can't?

Example (CodeSandbox)

addMiddleware(myModel, (call, next) => {
  if (call.type !== "action") {
    return next(call);
  }

  try {
    next(call);
  } catch (error) {
    console.log("A synchronous action failed!", call);
  }
});

EmilTholin avatar Apr 14 '21 18:04 EmilTholin

Hey @missyjeanbeutler - just wanted to follow up here to see if @EmilTholin's suggestion helped you with your MobX-State-Tree issue.

I know it's been a while since anyone responded here, so if y'all have since moved on from the issue, no worries. I will mark this to be closed if I don't hear from anyone in the next two weeks or so.

Happy to try and help a lil more if needed!

coolsoftwaretyler avatar Jun 28 '23 03:06 coolsoftwaretyler

No, it unfortunately didn't work for me so I ended up scrapping it. Thanks for reaching out though!

missyjeanbeutler avatar Jun 28 '23 15:06 missyjeanbeutler

Thanks for the response, @missyjeanbeutler! Sorry it didn't work out. I'm going to close this issue for now.

coolsoftwaretyler avatar Jun 28 '23 16:06 coolsoftwaretyler