11–20 of 47 posts
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 [1] npmjs.com/package/redux-saga-test-engine
The codebase for redux-saga is a dream to read through: https://github.com/redux-saga/redux-saga
The codebase for redux-saga is a dream to read through: https://github.com/redux-saga/redux-saga
The codebase for redux-saga is a dream to read through: https://github.com/redux-saga/redux-saga
Any advice on how to compare this with RxJS?
There's a couple particularly good comparisons of Redux side effects approaches at https://decembersoft.com/posts/what-is-the-right-way-to-do-a... and 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... .
Earlier quoted context omitted.
Any advice on how to compare this with RxJS?
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-a... and https://medium.com/react-native-training/redux-4-ways-95a130... , and more comparisons in my links list at…
Why not simply observables?
I don't understand. Why not simply 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.
I don't understand. Why not simply observables?
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, descripti…
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.
I don't understand. Why not simply observables?
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."
Earlier quoted context omitted.
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, descripti…
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.
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...
[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...