I worked on a fairly large and high traffic React app. It had some complicated async flows, so the team moved from redux-thunk to sagas.
The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain. I'm sure someone will say "you were doing it wrong" but there were many folks on the team following advice from the maintainers themselves on Discord. General understanding of Sagas by less seasoned developers was also worse than trying to teach them promises.
After the codebase was converted, the team generally concurred that sagas were a waste of time and effort, especially with async/await gaining steam. They also felt that maintainability and debug-ability suffered with sagas. Reasoning about what code runs next is easy, until it's not.
YMMV, but I've tried all the async patterns, and I think sticking with async/await and promises is probably the best bet these days. The code might not "look" as pretty - but aesthetics should hardly be the main goal.
> After the codebase was converted, the team generally concurred that sagas were a waste of time and effort, especially with async/await gaining steam.
To be fair, I'd almost certainly recommend async/await for simpler use cases- in particular, an application in which API calls are the only async behavior. However, in our situation, redux-saga turned out to work pretty well. We needed to coordinate some relatively complex UI flows (the user would draw on a map, then the app would POST the coords to the server). Before introducing redux-saga, we were starting to get lost in a daisy-chain of Redux actions.
> Reasoning about what code runs next is easy, until it's not.
This was the general idea behind "navigationSaga"- to set things up so there's as little as possible happening at a given time.
> The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain.
I dunno. On one hand, I wish there were better tools for testing sagas, but on the other, testing long chains of Promises has caused me all kinds of headaches in the past, as well. I find that it's easier for me to keep responsibilities separate when using sagas than it is using promises or suchlike.
And for what it's worth, I'm not trying to bill sagas as a be-all-end-all solution for all life's problems. :) I was just trying to sorta explicate an approach that worked for us.
Any claims about scalability or testability mean nothing without concrete code examples to back them up. Any tool that makes claims such as these without a sufficiently complex example in the docs, alongside a baseline implementation for comparison, is a huge red flag IMO.
We have been trying elm, and while it has still poor support for "web API", maintaining and growing an elm app has been the most pleasurable and easy thing that happened to us in a long time.
> After the codebase was converted, the team generally concurred that sagas were a waste of time and effort, especially with async/await gaining steam.
Aren't sagas and async/await completely orthogonal issues or am I missing something?
This is an excellent series of posts! Parts 1 and 2 give a ground-up description of the core concepts that redux-saga uses (generators, describing effects, etc), and Part 3 covers some real-world use cases. One of the best tutorials on redux-saga I've seen.
A whole class of problems you wouldn't have in the first place with MobX. So much code in the article for doing so little - where good design could solve the issues much more elegantly using plain function composition and JS concepts.
As I mentioned in other posts, I don't believe redux-saga is the be-all-end-all solution to every problem in client-side Javascript. It's a good solution for codebases which need to coordinate among several different asynchronous processes.
And for what it's worth, I wanted to err on the side of verbosity. I find that a lot of blog posts kinda elide over too much, and so I was actively trying to break down my thought process into very discrete steps. At the end of the day, I think you'll find that the final product involves less than 300 lines of code. If that.
On a different tack, MobX is an excellent library, and we've actually used it to great effect at Formidable! Ken Wheeler has a great post about the topic. The point of this article, though, is simply to share something that worked well for us on a complex project, where replacing Redux with MobX wouldn't have been that helpful.
Along those lines, I ask you in complete honesty: what would you like to see out of a "Javascript Power Tools: MobX" article? I'd love to dig into it a little bit, find out what makes it tick, and share that with folks. :)
Agreed. Just refactored a medium sized redux/redux-saga codebase (20 kloc) to MobX. Shaved off a couple of thousand loc of logic and boilerplate in the process, and everything became so much easier to reason about.
I'm going to use this opportunity to plug my Redux Saga testing library: redux-saga-test-engine[0][1]. It makes saga tests much less verbose. Let me know if you like it (or don't)! :)
Saying "why not simply observables" kinda glosses over a lot of details, but I'll try and answer as best as I can.
I've always found it a bit difficult to use Observables in application-style code, both in a conceptual sense (handling Redux actions as an observable stream) and in a practical sense (actually building and debugging streams and transformations over those streams). I do think they're excellent tools for dealing with cross-cutting concerns like logging, analytics, and debugging. But as I mentioned in the article, "business logic is inherently procedural, and expressing it as such makes our intent clearer." That's the major advantage, I think- being able to use simpler tools (e.g. loops and local variables) in a powerful new way.
And don't get me wrong, I'd love to learn RxJS properly one of these days. :) This article isn't about saying "well this approach is THE BEST APPROACH", it's more about saying "These tools turned out to be super helpful. Here's my thought process, maybe this approach will help you as well."
Because not everyone likes or uses observables? :)
redux-saga was one of the first major side effects middlewares to come out (besides redux-thunk). At this point, I would say that thunks and sagas are the two most popular approaches to side effects in Redux, with observables and various promise-based approaches also used but to a lesser extent.
The main selling points for sagas are things like testability, descriptive declaration of side effects (per Merrick Christen's "effects as data" gist the other day at https://gist.github.com/iammerrick/fc4a677cea11d9c896e8d3a29... ), and the ability to spawn background-thread-like sagas as needed.
[+] [-] eric_b|8 years ago|reply
The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain. I'm sure someone will say "you were doing it wrong" but there were many folks on the team following advice from the maintainers themselves on Discord. General understanding of Sagas by less seasoned developers was also worse than trying to teach them promises.
After the codebase was converted, the team generally concurred that sagas were a waste of time and effort, especially with async/await gaining steam. They also felt that maintainability and debug-ability suffered with sagas. Reasoning about what code runs next is easy, until it's not.
YMMV, but I've tried all the async patterns, and I think sticking with async/await and promises is probably the best bet these days. The code might not "look" as pretty - but aesthetics should hardly be the main goal.
[+] [-] mhink|8 years ago|reply
To be fair, I'd almost certainly recommend async/await for simpler use cases- in particular, an application in which API calls are the only async behavior. However, in our situation, redux-saga turned out to work pretty well. We needed to coordinate some relatively complex UI flows (the user would draw on a map, then the app would POST the coords to the server). Before introducing redux-saga, we were starting to get lost in a daisy-chain of Redux actions.
> Reasoning about what code runs next is easy, until it's not.
This was the general idea behind "navigationSaga"- to set things up so there's as little as possible happening at a given time.
> The claims that testability is improved do not ring true to me. Some of those tests were just awful to write and maintain.
I dunno. On one hand, I wish there were better tools for testing sagas, but on the other, testing long chains of Promises has caused me all kinds of headaches in the past, as well. I find that it's easier for me to keep responsibilities separate when using sagas than it is using promises or suchlike.
And for what it's worth, I'm not trying to bill sagas as a be-all-end-all solution for all life's problems. :) I was just trying to sorta explicate an approach that worked for us.
[+] [-] BigJono|8 years ago|reply
[+] [-] kuon|8 years ago|reply
[+] [-] acemarke|8 years ago|reply
[+] [-] _pmf_|8 years ago|reply
Aren't sagas and async/await completely orthogonal issues or am I missing something?
[+] [-] acemarke|8 years ago|reply
If anyone's interested, I do have links to other tutorials and articles on redux-saga in my React/Redux links list, at https://github.com/markerikson/react-redux-links/blob/master... .
[+] [-] inglor|8 years ago|reply
[+] [-] mhink|8 years ago|reply
As I mentioned in other posts, I don't believe redux-saga is the be-all-end-all solution to every problem in client-side Javascript. It's a good solution for codebases which need to coordinate among several different asynchronous processes.
And for what it's worth, I wanted to err on the side of verbosity. I find that a lot of blog posts kinda elide over too much, and so I was actively trying to break down my thought process into very discrete steps. At the end of the day, I think you'll find that the final product involves less than 300 lines of code. If that.
On a different tack, MobX is an excellent library, and we've actually used it to great effect at Formidable! Ken Wheeler has a great post about the topic. The point of this article, though, is simply to share something that worked well for us on a complex project, where replacing Redux with MobX wouldn't have been that helpful.
Along those lines, I ask you in complete honesty: what would you like to see out of a "Javascript Power Tools: MobX" article? I'd love to dig into it a little bit, find out what makes it tick, and share that with folks. :)
[+] [-] hakanito|8 years ago|reply
[+] [-] timbuckley|8 years ago|reply
[0] https://github.com/DNAinfo/redux-saga-test-engine [1] npmjs.com/package/redux-saga-test-engine
[+] [-] RussianCow|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] k__|8 years ago|reply
Why not simply observables?
[+] [-] mhink|8 years ago|reply
Saying "why not simply observables" kinda glosses over a lot of details, but I'll try and answer as best as I can.
I've always found it a bit difficult to use Observables in application-style code, both in a conceptual sense (handling Redux actions as an observable stream) and in a practical sense (actually building and debugging streams and transformations over those streams). I do think they're excellent tools for dealing with cross-cutting concerns like logging, analytics, and debugging. But as I mentioned in the article, "business logic is inherently procedural, and expressing it as such makes our intent clearer." That's the major advantage, I think- being able to use simpler tools (e.g. loops and local variables) in a powerful new way.
And don't get me wrong, I'd love to learn RxJS properly one of these days. :) This article isn't about saying "well this approach is THE BEST APPROACH", it's more about saying "These tools turned out to be super helpful. Here's my thought process, maybe this approach will help you as well."
[+] [-] acemarke|8 years ago|reply
redux-saga was one of the first major side effects middlewares to come out (besides redux-thunk). At this point, I would say that thunks and sagas are the two most popular approaches to side effects in Redux, with observables and various promise-based approaches also used but to a lesser extent.
The main selling points for sagas are things like testability, descriptive declaration of side effects (per Merrick Christen's "effects as data" gist the other day at https://gist.github.com/iammerrick/fc4a677cea11d9c896e8d3a29... ), and the ability to spawn background-thread-like sagas as needed.
[+] [-] tarr11|8 years ago|reply
Redux saga is very easy to read, works well with the chrome debugger, and plugs into a wide variety of use cases pretty seamlessly.
[+] [-] cnp|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] z3t4|8 years ago|reply
[+] [-] prodtorok|8 years ago|reply
[+] [-] Malice|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]