3 ms·

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 t

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.