HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
redux-saga
redux-saga
JavaScript2016–2022
redux-saga / redux-saga

redux-saga

An alternative side effect model for Redux apps

12Distinct people
12Mentions
0Explicit recommenders
22.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An alternative side effect model for Redux apps

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2016-01-25 12:49:25 UTC to 2022-11-08 15:20:55 UTC.

0123452016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC514
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101

What Hacker News says

12 sources
If you're curious: https://github.com/redux-saga/redux-saga As I said, I'm on the fence. Redux itself is for programs that get large enough, and interconnected enough, that you want a central place to manage global state. You add in sagas when you want to grow that to include all side effects. It is really cool to use its debugger and look at every message that got passed, and how that changes the global state. But adding in the message passing system is really heavy: you have to connect the component to it, AND create an action for both the request AND the response, AND put the code in a separate "reducer", AND then the whole saga middleware magic, AND several other things. So... keep it in the back of your mind. If nothing else, it's pretty cool to use generators for something.
In Ask HN: Was ES6 a Bust?
>Basically, imagine if a Redux reducer could dispatch further actions. You can achieve the same by using redux-saga[0], then writing a generator function ("saga") that inspects dispatched actions, and potentially triggers a side effect, dispatches another action, waits for another action to get dispatched in a certain time, etc. [0] https://github.com/redux-saga/redux-saga
In The Elm Architecture
Though the article doesn't mention it, the "alternative" is Reactive programming (via RxJS) I think for the typical UI application developer, async / await can provide easier readability and debugging, but at the cost of some expressive power and conciseness. Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks. In the redux world, you can see this by comparing redux-observable [1] (reactive / rxjs) with redux-saga [2] (generators) Rxjs requires a deeper understanding of Reactive programming. Once you understand it, you can write very powerful expressions in a few lines. But debugging is tough and it doesn't translate well for your fellow developers. [1] https://github.com/redux-observable/redux-observable [2] https://github.com/redux-saga/redux-saga
In Async/Await will make code simpler
Man, there's so many tools and styles to learn and evaluate. I'm still relatively new to React and React Native, and have enjoyed writing some apps with Redux. It took me a while to understand the need for redux-thunk, and now I'm about to get started with redux-saga [1]. I'm totally unfamiliar with RxJS, but some of the concepts sound familiar. Do I need to learn and use RxJS if I'm already using redux and redux-saga? I found this SO answer [2], and this post [3], which compares redux-observable and redux-saga. This guide [4] looks pretty good, too. [1] https://github.com/redux-saga/redux-saga [2] http://stackoverflow.com/a/40027778/304706 [3] https://hackmd.io/s/H1xLHUQ8e [4] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 EDIT: OK wow, as soon as you get to the "double click" stream diagram (in link [4]), it all starts to make sens
Read the rest
e. This is pretty amazing. EDIT 2: The example on http://reactivex.io/ is also good. I didn't realize it was available for so many languages: Java, .Net, JS, Swift. This sounds like something I need to learn. EDIT 3: This is the best programming guide I have ever read ([4]). It starts with a real problem, then goes on to show how you would solve it in RxJS in a rudimentary and familiar way. Then it expands on and successively simplifies that solution, to show how you would solve it in the idiomatic way. It's really the perfect way to learn these concepts. > A metastream for responses looks confusing, and doesn't seem to help us at all. We just want a simple stream of responses, where each emitted value is a JSON object, not a 'Promise' of a JSON object. Say hi to Mr. Flatmap: a version of map() that "flattens" a metastream, by emitting on the "trunk" stream everything that will be emitted on "branch" streams. Flatmap is not a "fix" and metastreams are not a bug, these are really the tools for dealing with asynchronous responses in Rx.
In TypeScript at Slack
In addition to redux-saga (https://github.com/yelouafi/redux-saga) which others have mentioned, redux-loop (https://github.com/raisemarketplace/redux-loop) is another interesting "declarative" approach to sequencing operations that uses promises. I'm not using either (yet), but I wrote up my notes on the differences between them and the thunk middleware approach recently (https://blog.boldlisting.com/connecting-redux-to-your-api-ea...). One aspect of these discussions that I find is lost or at least very implicit is the notion of storing metadata about the status of async operations as well as their result is elided together, but there's reason to make mindful choices about whether or not to do that. BTW, the "Ignoring Async Responses" section here is a useful pattern, even if you're not working on browser developer tools ;). I've been wo
Read the rest
rking on a web app and have a polling timeout that I cancel on logout. Not quite the same, but logout triggers a reset of all the state obtained while authenticated, but the timeout ids are also in the store and canceled before being cleared.
In Two Weird Tricks with Redux

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.