6 ms·

JavaScript Power Tools: Real-World Redux-Saga Patterns

138 points by thekenwheeler 9y ago

acemarke 9y ago
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. 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/redux-side-effects.md#sagas https://github.com/markerikson/react-redux-links/blob/master... .
timbuckley 9y ago
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)! :) [0] https://github.com/DNAinfo/redux-saga-test-engine https://github.com/DNAinfo/redux-saga-test-engine [1] npmjs.com/package/redux-saga-test-engine
- RussianCow 9y ago
  This is awesome! I'm definitely going to give it a try on my next side project. :) Thanks for sharing!
- deleted 9y ago
  [deleted]
cnp 9y ago
The codebase for redux-saga is a dream to read through: https://github.com/redux-saga/redux-saga https://github.com/redux-saga/redux-saga
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- z3t4 9y ago
  could you actually get anything done in js before es6 !?
  - rounce 9y ago
    Quite happily, ES6 is 90% sugar.
    - elyobo 9y ago
      Was that a yes or a no? :D
      - deleted 9y ago
        [deleted]
- deleted 9y ago
  [deleted]
- prodtorok 9y ago
  Any advice on how to compare this with RxJS?
  - acemarke 9y ago
    It's largely a question of whether you prefer to write your code in imperative-looking form via generator functions, or pipeline/declarative form via observables. There's a couple particularly good comparisons of Redux side effects approaches at https://decembersoft.com/posts/what-is-the-right-way-to-do-asynchronous-operations-in-redux/ https://decembersoft.com/posts/what-is-the-right-way-to-do-a... and https://medium.com/react-native-training/redux-4-ways-95a130da0cdc https://medium.com/react-native-training/redux-4-ways-95a130... , and more comparisons in my links list at https://github.com/markerikson/react-redux-links/blob/master/redux-side-effects.md https://github.com/markerikson/react-redux-links/blob/master... .
    - prodtorok 9y ago
      awesome, thanks
- Malice 9y ago
  What do you like about it?
k__ 9y ago
I don't understand. Why not simply observables?
- acemarke 9y ago
  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/fc4a677cea11d9c896e8d3a29a184f91 https://gist.github.com/iammerrick/fc4a677cea11d9c896e8d3a29... ), and the ability to spawn background-thread-like sagas as needed.
  - k__ 9y ago
    Yes, I know. I just found it strange that people try to bend Redux til it does their bidding and not simply use something that works out of the box.
    - acemarke 9y ago
      Well, one of the primary design goals behind Redux was to make async behavior a pluggable approach (as detailed in my blog post "The Tao of Redux, Part 1 - Implementation and Intent" [0]). So, I don't see how use of redux-saga, or redux-thunk, or any other async middleware, qualifies as "bending Redux until it does their bidding", given that it was explicitly intended to allow that. On the other hand, there definitely _are_ lots of ways that people "bend Redux", especially things like trying to slap OOP layers on top of an FP-oriented library. Those are technically valid because the Redux core is very unopinionated, but they're definitely not idiomatic Redux usage. (I also discussed those in "The Tao of Redux, Part 2 - Practice and Philosophy" [1]). [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
eric_b 9y ago
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.
- acemarke 9y ago
  Interesting. What specific concerns or pain points did you experience? Any examples of "reasoning about what code runs next is easy, until it's not" ?
  - eric_b 9y ago
    The put/call/takeLatest/takeEvery effects, coupled with all the yields made things impossible to grok for the less seasoned folks. Even for me, having seen some similar things before with other libraries in other languages, it's just not a pattern that my brain wraps itself easily around. There is so much indirection between the sagas and reducers and the effects. Like, I just want to see the code that actually does all the work. I understand the sagas "look" easy, but that's just because all the good stuff is hidden away. I like to see easily where the rubber meets the road, so to speak. The main selling point was "look how easy this code is to read, it's async but you can read it procedurally". This is mostly true for simple sagas, but the advanced flows were challenging to read, especially trying to remember what each effect did, and what "real" code it called under the covers. Thinking back on that code, had async/await been used - it would have been simpler to work on and understand, and you wouldn't have carried the weight of a third party library with somewhat esoteric ergonomics. Edit: It's been several months since I worked on that code, and it's all Angular 2,4,a billion all the time now, so I apologize for limited specifics. In general I appreciate that people are trying new async things (CSP, sagas, observables etc) but they all just feel like a fad to me. Obviously use the right tool for the job, but most of the time I think promises should be the way to go unless there's a super compelling reason not to.
inglor 9y ago
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.
- mhink 9y ago
  Author here. 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 9y ago
    I think it would be great for the community to see a writeup on how complex async flows can be handled with MobX reactions and data atoms, two pretty powerful concepts IMO
- hakanito 9y ago
  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.

138 points by thekenwheeler 9y ago

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. 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/redux-side-effects.md#sagas https://github.com/markerikson/react-redux-links/blob/master... .

timbuckley 9y ago

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)! :) [0] https://github.com/DNAinfo/redux-saga-test-engine https://github.com/DNAinfo/redux-saga-test-engine [1] npmjs.com/package/redux-saga-test-engine

RussianCow 9y ago
This is awesome! I'm definitely going to give it a try on my next side project. :) Thanks for sharing!
deleted 9y ago
[deleted]

cnp 9y ago

The codebase for redux-saga is a dream to read through: https://github.com/redux-saga/redux-saga https://github.com/redux-saga/redux-saga

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
z3t4 9y ago
could you actually get anything done in js before es6 !?
- rounce 9y ago
  Quite happily, ES6 is 90% sugar.
  - elyobo 9y ago
    Was that a yes or a no? :D
    - deleted 9y ago
      [deleted]
deleted 9y ago
[deleted]
prodtorok 9y ago
Any advice on how to compare this with RxJS?
- acemarke 9y ago
  It's largely a question of whether you prefer to write your code in imperative-looking form via generator functions, or pipeline/declarative form via observables. There's a couple particularly good comparisons of Redux side effects approaches at https://decembersoft.com/posts/what-is-the-right-way-to-do-asynchronous-operations-in-redux/ https://decembersoft.com/posts/what-is-the-right-way-to-do-a... and https://medium.com/react-native-training/redux-4-ways-95a130da0cdc https://medium.com/react-native-training/redux-4-ways-95a130... , and more comparisons in my links list at https://github.com/markerikson/react-redux-links/blob/master/redux-side-effects.md https://github.com/markerikson/react-redux-links/blob/master... .
  - prodtorok 9y ago
    awesome, thanks
Malice 9y ago
What do you like about it?

k__ 9y ago

I don't understand. Why not simply observables?

acemarke 9y ago
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/fc4a677cea11d9c896e8d3a29a184f91 https://gist.github.com/iammerrick/fc4a677cea11d9c896e8d3a29... ), and the ability to spawn background-thread-like sagas as needed.
- k__ 9y ago
  Yes, I know. I just found it strange that people try to bend Redux til it does their bidding and not simply use something that works out of the box.
  - acemarke 9y ago
    Well, one of the primary design goals behind Redux was to make async behavior a pluggable approach (as detailed in my blog post "The Tao of Redux, Part 1 - Implementation and Intent" [0]). So, I don't see how use of redux-saga, or redux-thunk, or any other async middleware, qualifies as "bending Redux until it does their bidding", given that it was explicitly intended to allow that. On the other hand, there definitely _are_ lots of ways that people "bend Redux", especially things like trying to slap OOP layers on top of an FP-oriented library. Those are technically valid because the Redux core is very unopinionated, but they're definitely not idiomatic Redux usage. (I also discussed those in "The Tao of Redux, Part 2 - Practice and Philosophy" [1]). [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

eric_b 9y ago

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.

acemarke 9y ago
Interesting. What specific concerns or pain points did you experience? Any examples of "reasoning about what code runs next is easy, until it's not" ?
- eric_b 9y ago
  The put/call/takeLatest/takeEvery effects, coupled with all the yields made things impossible to grok for the less seasoned folks. Even for me, having seen some similar things before with other libraries in other languages, it's just not a pattern that my brain wraps itself easily around. There is so much indirection between the sagas and reducers and the effects. Like, I just want to see the code that actually does all the work. I understand the sagas "look" easy, but that's just because all the good stuff is hidden away. I like to see easily where the rubber meets the road, so to speak. The main selling point was "look how easy this code is to read, it's async but you can read it procedurally". This is mostly true for simple sagas, but the advanced flows were challenging to read, especially trying to remember what each effect did, and what "real" code it called under the covers. Thinking back on that code, had async/await been used - it would have been simpler to work on and understand, and you wouldn't have carried the weight of a third party library with somewhat esoteric ergonomics. Edit: It's been several months since I worked on that code, and it's all Angular 2,4,a billion all the time now, so I apologize for limited specifics. In general I appreciate that people are trying new async things (CSP, sagas, observables etc) but they all just feel like a fad to me. Obviously use the right tool for the job, but most of the time I think promises should be the way to go unless there's a super compelling reason not to.

inglor 9y ago

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.

mhink 9y ago
Author here. 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 9y ago
  I think it would be great for the community to see a writeup on how complex async flows can be handled with MobX reactions and data atoms, two pretty powerful concepts IMO
hakanito 9y ago
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.