I am gung ho about using sagas in my own code, so I was pleased to see this article. I want to mention that I have recently begun splitting up my sagas for testing reasons.
The key element that has made all the difference is the fact that the
call effect can be used for both regular functions and sagas. I try to limit my sagas to doing one flow. If I find myself doing a bunch of if/else or using a loop, I simply package up the guts into a separate saga and then
yield call() it. This allows me to write tests that are only a page long for each saga, which is a decent metric for whether the test is maintainable.
Once it gets longer than a page, I can’t remember how it started, and any error makes debugging a royal pain in the rear.
One other major gotcha: if you use
take instead of
takeEvery or some other equivalent, if there is a burst of actions, your saga will lose one or more of them because
take does not buffer actions. If an action occurs asynchronously while you’re doing something in the saga, it is simply missed entirely. And that’s a very difficult bug to debug. Fortunately, the newer documentation doesn’t even mention
take until several pages in, so most users won’t suffer this fate, but it is an important one to understand.
I think it’s also worth mentioning that if you can safely drop support for Internet Explorer or Android 5 and earlier or iOS 9 and earlier, generators are natively supported in all browsers now, including Edge. If you can’t, you’ll have to load a very large polyfill, which is about 20k as of this comment.