| > 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. So do I, which is why I dug into it a bit deeper before using it on a project. This article is actually the third in a series (see [1] and [2]), and the first one goes into a little bit of detail about how things work behind the scenes. > The put/call/takeLatest/takeEvery effects, coupled with all the yields made things impossible to grok for the less seasoned folks. I definitely feel you on this, and it's _very_ easy to let things get out of hand. I'm very much _not_ a fan of nesting an anonymous generator function inside takeEvery/takeLatest; it's just too easy to start accessing variables from the enclosing scope and then everything gets totally FUBARed. > 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. This is totally fair, and I definitely agree that apps should start with simple tools and only use power tools when they're called for. As I mentioned in my other comment, we started out with something like Promises, and moved to redux-saga when that approach was starting to get cumbersome. 1: http://formidable.com/blog/2017/javascript-power-tools-redux... 2: http://formidable.com/blog/2017/composition-patterns-in-redu... |