3 ms·

I don't know much about Redux but these tricks seem like they should be less trick and more re-worked flow. For the first one, if a burger is meant to be consu

I don't know much about Redux but these tricks seem like they should be less trick and more re-worked flow. 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. 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? 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?

jlongster 11y ago
There are many reasons why the UI should not care about how the server requests are ordered. > 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? In our case we use the same connection but it switches "contexts" and we want to ignore everything from a previous context. In simpler situations you could make sure the your connection is destroyed before the UI is destroyed, yes.
- BinaryIdiot 11y ago
  > There are many reasons why the UI should not care about how the server requests are ordered. Sure. It was just an example. My main point was the change here felt like a hack and they forced a mechanism that should be processed serially into one that is meant to handle parallel. > In our case we use the same connection but it switches "contexts" and we want to ignore everything from a previous context. In simpler situations you could make sure the your connection is destroyed before the UI is destroyed, yes. So wouldn't it be best to sever ties that will cause issues and reconnect them versus anything else? That's typically the pattern you use when you want to replace event handlers. The way in the article just wastes a lot of CPU cycles to support an awkward pattern I've never seen someone use before. Just my 2 cents. But like I said I've never used Redux so maybe these patterns are normal here.

jlongster 11y ago

There are many reasons why the UI should not care about how the server requests are ordered. > 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? In our case we use the same connection but it switches "contexts" and we want to ignore everything from a previous context. In simpler situations you could make sure the your connection is destroyed before the UI is destroyed, yes.

BinaryIdiot 11y ago
> There are many reasons why the UI should not care about how the server requests are ordered. Sure. It was just an example. My main point was the change here felt like a hack and they forced a mechanism that should be processed serially into one that is meant to handle parallel. > In our case we use the same connection but it switches "contexts" and we want to ignore everything from a previous context. In simpler situations you could make sure the your connection is destroyed before the UI is destroyed, yes. So wouldn't it be best to sever ties that will cause issues and reconnect them versus anything else? That's typically the pattern you use when you want to replace event handlers. The way in the article just wastes a lot of CPU cycles to support an awkward pattern I've never seen someone use before. Just my 2 cents. But like I said I've never used Redux so maybe these patterns are normal here.