I like the elegant simplicity of Redux, but it's so low-level and definitely feels like people are still figuring the "right" way to do a lot of things.<p>I tweeted my feelings on this last week:<p><pre><code> 2015: reflux flummox redux marty alt fluxible…
2016: redux-actions redux-act redux-forms redux-promise redux-ui…
</code></pre>
<a href="https://twitter.com/tlrobinson/status/717258992989306880" rel="nofollow">https://twitter.com/tlrobinson/status/717258992989306880</a>
I don't know much about Redux but these tricks seem like they should be less trick and more re-worked flow.<p>For the first one, if a burger is meant to be consumed differently than fries (serial versus parallel) they why are they using the same mechanism with the burger having a hacked on predicate , service type, dispatch, etc? Why wouldn't the burger just have a workflow that makes sense for how its invoked? For instance if the burger is tied to the UI and a backend request that must happen one at a time then the UI would disallow or provide a way of queueing which I guess this sorta supports but it seems forced and doesn't look like a normal flow.<p>The second part, ignoring async responses. I don't understand this part. Why can't you just replace your state and drop the existing handlers so nothing async from the previous state occurs? Does redux just not support this out of the box or is the author doing something very edge-case-y?<p>When I don't want to handle an async response anymore I remove the handle's association with the event it was going to handle. It works like this in native DOM, jQuery, even my own bias data point: msngr. But I'm curious why wouldn't redux be able to handle the same case?
I just started with redux-saga which uses ES6 generators to handle app control flow.<p>After first impressions, I'd say it's worth a look if you're running into anything near as complicated as talked about here. It's very easy to reason about and test. gaearon - the creator of redux - seems to approve of it as well.<p><a href="https://github.com/yelouafi/redux-saga" rel="nofollow">https://github.com/yelouafi/redux-saga</a>
The isEatingBurger (isLoading) flag seems to be idiomatic in Redux and shows up in tutorials. In addition to preventing overlapping requests, it's useful for spinners, disabling submit buttons, etc. It's cool that you rolled the isLoading pattern into a service.<p>If you really want to pass around the promise, it's doable. To save in your component state, return the promise from your thunk so it gets returned by dispatch (thom_nic just posted this also). To save in your store, dispatch a 'save' action from the thunk with the promise as an argument. But I agree that it's probably a bad design.<p>The request sequence IDs are useful for many situations where you need to order or cancel async requests. If you have multiple in-flight requests for an autocomplete field, you only want to set isLoading=false when the last request completes, and you don't want the result of a later request to overwrite the result of an earlier request if the responses come back out-of-order.
My usual approach is to avoid middlewares for async-requests and to keep this stuff in a separate layer. For example, it can look like an ApiClient object with ES7 async-methods. Such methods would:<p>1. send "Start" action<p>2. await for result of fetch("<a href="http://example.com/api/call");" rel="nofollow">http://example.com/api/call");</a><p>3. send success or error action<p>this way redux is 100% synchronous and I have an obvious place for throttling requests, keeping trace of promises, etc.
In addition to redux-saga (<a href="https://github.com/yelouafi/redux-saga" rel="nofollow">https://github.com/yelouafi/redux-saga</a>) which others have mentioned, redux-loop (<a href="https://github.com/raisemarketplace/redux-loop" rel="nofollow">https://github.com/raisemarketplace/redux-loop</a>) is another interesting "declarative" approach to sequencing operations that uses promises. I'm not using either (yet), but I wrote up my notes on the differences between them and the thunk middleware approach recently (<a href="https://blog.boldlisting.com/connecting-redux-to-your-api-eac51ad9ff89#.79d5lnivt" rel="nofollow">https://blog.boldlisting.com/connecting-redux-to-your-api-ea...</a>). One aspect of these discussions that I find is lost or at least very implicit is the notion of storing metadata about the status of async operations as well as their result is elided together, but there's reason to make mindful choices about whether or not to do that.<p>BTW, the "Ignoring Async Responses" section here is a useful pattern, even if you're not working on browser developer tools ;). I've been working on a web app and have a polling timeout that I cancel on logout. Not quite the same, but logout triggers a reset of all the state obtained while authenticated, but the timeout ids are also in the store and canceled before being cleared.
What stuck out to me is<p>"In an asynchronous world, you have 3 actions indicating asynchronous work: start, done, and error. In our system, they all are of the same type (like ADD_BREAKPOINT) but the status field indicates the event type."<p>This is a great suggestion (I have used a very similar schema before, although in flux), and should be the standard suggestion in redux tutorials.<p>Not enforcing this can lead to a proliferation of inconsistently named constants, especially if a team is learning flux/redux and has not yet settled on a naming schema.
Can you tell me a use case using the "action" that's sent to
"request.run", or is it passed just because it can be.<p><a href="https://github.com/mozilla/gecko-dev/blob/master/devtools/client/shared/redux/middleware/wait-service.js#L51" rel="nofollow">https://github.com/mozilla/gecko-dev/blob/master/devtools/cl...</a>
Good stuff,<p>The EAT_BURGER seems slightly odd, as i've never hit a situation where I would allow a second one to be fired while the first is still pending. I.E. upon EAT_BURGER.start i would disable the UI for the EAT_BURGER action to be fired. I guess that's an idealised world and you've hit something more complicated that requires it though, and the solution is good<p>I particularly like the async call tracking - very simple and neatly solves your issue!<p>Cheers
re: an action caller needing to wait on the async action to complete: I thought that was a non-issue. If you use redux-thunk and your action creator returns a promise, the caller gets it. So while you're no longer triggering off of a redux action/store state change -- which may or may not be seen as a good thing -- you <i>can</i> get the promise and add a `.then()` which will fire after the async action completes.<p>I put together a simple example here: <a href="https://gist.github.com/thom-nic/fbedf27a5222a8490aa9028a40bf053c" rel="nofollow">https://gist.github.com/thom-nic/fbedf27a5222a8490aa9028a40b...</a><p>Basically: component fires a 'delete' action, and then does page navigation when delete is successful. (Not saying this is a good idea to do it that way, just that you <i>can</i> do it.) Or did I miss his point?