Merge the message optimistically (server optimistic version) in to the stateĬancel the delay if the api call succeeds

Merge the message optimistically (client version) in to the state We had an epic which would handle messaging for example, the user would send a message and the epic would: Often we would find that we were doing too much in an epic. This helps keep the complexity reasonable, and we don't have many epics longer than 20 lines.

The first thing we do when we create a new epic is set up the SRP for what the epic should do, this is in a comment at the top of the file. We love it, but it's easy to write unreadable code. I know that I am late to the party here, but I'd like to share our experiences of redux-observable. For simple requests I'd stick with thunk, then swap them over to a more complicated pattern when I need more powerful functionality. Both observable and saga are HUGELY powerful, but they add a lot more boilerplate on top of the already very boilerplate heavy redux patterns. That's a great way to remain productive, so you're not fighting redux-observable/saga for things that would be trivial with redux-thunk. There's also a lot of merit in using redux-thunk with one of the others (redux-observable/saga) in the same project! redux-thunk for your common simple stuff and then only using redux-observable/saga for complex stuff. To quote the stackoverflow post you linked: my app currently using redux-observable I use it for all my ajax calls, and I regret it. So, TLDR, I think redux-observable is a little harder to learn, but I think it is more worth the time put into learning its concepts. For me redux-observable was a little harder to wrap my head around (I still have to look up the distinction between switchmap/flatmap/mergemap), but I'd rather put the time into learning Rx, as it is a powerful library/concept that crosses langues (RxJS, Rx.NET, etc. I compare that to redux-observable, which is built on top of the super powerful RxJS library. Yes, in saga you will get familiar with generators, but the whole saga concept is something that I think has limited use. The concepts you learn will not be as useful going forward I think they are a bit simpler to start building, and You already linked to some great in-depth comparisons so I'll just share my personal experience/opinion. I also have links to other similar articles in the Redux Side Effects#Side Effect Comparisons section of my React/Redux links list, and I highlighted some of the most popular side effects libraries and their use cases in my ReactBoston talk on the Redux ecosystem. In addition to the posts you linked, I recommend What's the right way to do async operations in Redux?, which compares several different Redux side effects libs. Observables are also great for complex async workflows, and are better if you prefer observables or a pipeline-based sequence of data transformations.

They are usually considered to be easily testable, although some people question whether the testing becomes too coupled to the internal logic. Sagas are great for complex async workflows, and better if you prefer reading imperative / sequential code. Thunks are best for complex synchronous logic and simple async logic (like an AJAX call with no response, or just a simple dispatch on success / failure) My answer is that you should use thunks and your choice of sagas or observables.

Redux observable