HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
reduxjs
redux
TypeScript2015–2024
reduxjs / redux

redux

A JS library for predictable global state management

65Distinct people
151Mentions
4Explicit recommenders
61.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A JS library for predictable global state management

GitHub

Where it is used

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

What people are saying

Thanks for doing what you do. I contributed some of the initial documentation [1] for testing middleware back in the day. Wondering if there are any areas in particular you'd…

daveidol used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

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

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 year151 dated mentions

Observed mentions: 2015-06-04 14:48:56 UTC to 2024-12-05 20:12:54 UTC.

01020302015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 34 mentions; 7 submissions, 27 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 24 mentions; 1 submissions, 23 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 27 mentions; 4 submissions, 23 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 20 mentions; 2 submissions, 18 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 23 mentions; 0 submissions, 23 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

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
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC34727
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC16214
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC24123
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC27423
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC20218
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC23023
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

151 sources
Hmm, that is a good point that `useActionState` accepts a reducer-like function (although I think it's async in this case?). And yeah, half of Redux's terminology is simply because the existing Flux Architecture libraries from the prior year all used those terms. There were several debates in the issues about whether to name them "actions", "events", or something else, and the conclusion was "let's just stick with the existing Flux terminology": - https://github.com/reduxjs/redux/issues/891#issuecomment-147... FWIW, as I've revamped the Redux docs over the years, I have specifically made sure we describe the "actions === events" aspect: - https://redux.js.org/style-guide/#model-actions-as-events-no... - https://redux.js.org/tutorials/essentials/part-1-overview-co...
In React 19
I am _thrilled_ to announce that: Redux Toolkit 2.0 is LIVE!!! - https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0 This major version has new features, faster perf, smaller bundle size, and removes deprecated options. It's accompanied by majors for all our Redux family packages ## RTK 2.0: - a new `combineSlices` method for lazy-loading reducers - Updates to `createSlice` to include a `selectors` field and allow defining thunks inside - Immer 10 w/ faster updates - Removal of deprecated options See the migration guide: - https://redux.js.org/usage/migrations/migrating-rtk-2 All of the Redux libraries now have modernized packaging with full ESM/CJS compat. They also ship modern JS (no transpiling for IE11), which means smaller bundle sizes. We've also done byte-shaving work to shrink the bundles (extracting error messages, de-du
Read the rest
ping imports) ## Redux core 5.0: - The TS conversion we did in 2019! - Action types _must_ be strings - `UnknownAction` as the default action type - Better preloaded state types - Internal subscription improvements - Still marks `createStore` as deprecated! - https://github.com/reduxjs/redux/releases/tag/v5.0.0 ## React-Redux 9.0: - *Now requires React 18 and RTK 2.0 / Redux 5.0* - Updates dev-mode checks - Throws better errors in an RSC environment - https://github.com/reduxjs/react-redux/releases/tag/v9.0.0 ## Reselect 5.0: - Switches to a new `weakMapMemoize` memoizer as default - Renames `defaultMemoize` to `lruMemoize` - Allows passing memoizer options direct to `createSelector` - Many TS improvements - https://github.com/reduxjs/reselect/releases/tag/v5.0.1 ## Redux Thunk 3.0: - Drops the default export and switches to named exports ( `{thunk, withExtraArgument}` ) - https://github.com/reduxjs/redux-thunk/releases/tag/v3.1.0 This has been a _huge_ year-long development effort! We're thrilled to get these improvements out. The tooling and bundle improvements will help all users, and we think the features and TS changes will improve the Redux dev experience significantly. Thank you SO MUCH to everyone who has contributed or helped test out the work! Please file bug reports for the inevitable issues that pop up post-release! but now I'm going off on a conf trip and going to take a very well-earned break from Redux work for December :)
In Redux Toolkit 2.0: new features, faster perf, smaller bundle sizes, and more
Oh hey, that's my post! (yes I spend too much time refreshing HN :) ) FWIW I did end up with a packaging combination that seems to work sufficiently. I never did fix the "FalseCJS" issue that `are-the-types-wrong` is detecting. I played with double-emitting TS typedefs, and the `tsup` tool _does_ actually have support for that now (added by Andrew Branch from the TS team). So it might be more feasible now. But ultimately I decided I was tired of messing with packaging setup and that what I've got is good enough. (hopefully) We're actually about to launch Redux Toolkit 2.0 and Redux 5.0 this week, assuming the last couple pieces come together. Here's the latest RCs - you can see the current `package.json` files in there: - https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0... - https://github.com/reduxjs/redux/releases/tag
Read the rest
In Blogged Answers: My Experience Modernizing Packages to ESM
> From what I gather, your ask is to add information about the usage of the toolkit and steer people towards that. Is that correct? If so, I don't mind adding it, but I think the existing information is helpful. Basically, yes. The point is we want people to know that writing object spreads and action constants by hand is _not_ how they're supposed to really write Redux today, and that RTK both exists and is the standard approach for writing Redux logic. Per the "Quick Start/Getting Started" page: the point of that page is not to teach Redux or RTK. It's just the simplest possible example to show what the syntax looks like. _Learning_ this material is why we have the extensive "Essentials" and "Fundamentals" tutorials. Frankly, if having those snippets in the "Getting Started" page is confusing, I'd rather _remove_ those snippets and poi
Read the rest
nt more emphatically over to the tutorials. > you're not really learning Redux, you're learning the abstraction that's built on top of Redux Yes, and that's also the point. RTK _is_ now "Redux". Or rather, it's the form of Redux we want people to learn. Yes, it _is_ a set of abstractions, and some people may find it easier to learn if they understand the underlying principles and techniques first. That's why the "Fundamentals" tutorial exists. But, many other people just want to dive straight into writing working code and see "how to use it". That's why we have the "Essentials" tutorial, and there's been very positive feedback from people who _only_ read the "Essentials" tutorial to start learning Redux. (We've actually considered just replacing the NPM `redux` package with the RTK contents, but concluded that would be too much ecosystem churn: https://github.com/reduxjs/redux/issues/3321 ). It is admittedly hard to split the learning material between our three docs sites: the Redux core docs, the Redux Toolkit docs, and the React-Redux docs. That's why I actually just deleted the tutorials in the RTK site itself recently, and instead now point to the "Essentials" and "Fundamentals" tutorials in the core site instead, so that there's no duplication of tutorial content. (There were several other issues with the RTK tutorials people had complained about anyway - see https://github.com/reduxjs/redux-toolkit/issues/371 ). FWIW, this is a really good discussion and set of feedback, and I appreciate you engaging with me on this :) If you still have concerns about how we're trying to teach Redux and RTK, could you do me a favor and file a new "Discussion" in the Redux core repo, at https://github.com/reduxjs/redux/discussions ? I definitely take concerns over Redux learning flow seriously and am interested in ways we can improve the docs, and this HN thread probably isn't the best place for surfacing the discussion :)
In How to Use Redux to Manage State
That's wrong. Dan created Redux while he was actually unemployed. I'd have to check the exact timeline, but I believe he left Stampsy in late 2014 or early 2015, and was actually getting some funding from an OSS collective-type thing while he developed Redux in preparation for React Europe. Redux was developed in June/July 2015, and demoed at React Europe on July 5, 2015 [0]. Redux 1.0 was released on Aug 14, 2015 [1]. Per the tweet linked from that page [2], Dan didn't join Facebook until November 2015, well after Redux had been released. So, he most definitely was _not_ working at FB when he developed Redux. [0] https://www.youtube.com/watch?v=xsSnOQynTHs [1] https://github.com/reduxjs/redux/releases/tag/v1.0.0 [2] https://twitter.com/dan_abramov/status/671135846830075904
In Comparing Svelte and React
FWIW, I accumulated a bunch of docs writing resources while rewriting the Redux core docs tutorials last year: https://github.com/reduxjs/redux/issues/3609 I specifically recommend Divio's "Documentation System" structure, and the Vue docs "Writing Style Guide" section as being particularly good resources: https://documentation.divio.com/ https://v3.vuejs.org/guide/contributing/writing-guide.html And here's one of the new tutorials I ended up writing, which took inspiration from many different sources: https://redux.js.org/tutorials/essentials/part-1-overview-co...
In 10 Years of Open-Source Visualization: Did I learn anything from D3.js?
I've been working on an ongoing rewrite for the Redux core docs [0], including writing a couple brand new comprehensive tutorials from scratch [1]. In the process, I collected a bunch of notes and resources on useful docs writing advice [2]. My two favorites by far are this Divio docs writing guide, and the Vue docs writing style guide [3]. Excellent resources! [0] https://github.com/reduxjs/redux/issues/3592 [1] https://redux.js.org/tutorials/index [2] https://github.com/reduxjs/redux/issues/3609 [3] https://v3.vuejs.org/guide/contributing/writing-guide.html
In A Framework for Writing Better Documentation
Sorry to hear that :( I get what some of what you're saying here, but I also feel a couple of these complaints are misguided. For one thing, the Redux team has never intentionally tried to make Redux "the main state management tool for React". We've never deliberately sold it that way, and goodness knows the React team has said "React is the only official state management tool for React". Redux got popular because it solved the problems people were dealing with when it came out, better than the existing tools in the ecosystem, at a time when React was taking off. We've done our best to clarify in the docs when it does actually make sense to use Redux. Redux Toolkit is still Redux. You're still writing reducers, creating a store, dispatching actions, and updating the UI based on state. RTK just allows you to do so with less code. So, th
Read the rest
e "Essentials" tutorial starts by introducing those terms, concepts, and data flow, because you need to understand those regardless of how you're writing Redux logic. While Redux _is_ normally used with React, it's also UI-agnostic, hence the separation from React-Redux, and using it with other UI frameworks is a valid use case that we support. We had some long debates about whether to add these additional APIs into the Redux core [0] [1], and concluded that there was too much inertia around the existing Redux ecosystem to build those into the core `redux` package. As it is, even though RTK isn't required, we've had folks say they didn't like some of the opinions we've built into RTK (like using Immer for writing reducers). So, combining all three of those packages into a single super-package is not feasible at this point. I've tossed around the idea of trying to merge the Redux core, React-Redux, and RTK docs into one site, but that would likely require merging all three libs into a monorepo. Not impossible, but not something that's likely to happen any time soon, if only because my own time is very limited and I have a lot of other docs work I need to focus on [2]. Which specific docs page are you referring to? You said "intermediate" and "advanced" - sounds like you're referring to the RTK docs site tutorials [3]? FWIW, I wrote those a year ago, and at the time the main Redux docs were frankly very out of date. I've spent much of this year rewriting the Redux core tutorials, as listed above, and those Redux tutorials are where I would direct anyone who's new to Redux or really wants to know about RTK. We do also have an open issue to discuss what tutorial content should be on the RTK docs site [4], and tbh I'm really not sure _what_ tutorial content should actually be on the RTK site now that the "Essentials" and "Fundamentals" tutorials exist in the core docs. You're right that the actual Redux core itself isn't very complicated, but the biggest issue is trying to teach people to "think in Redux". In fact, it's kind of _because_ the core is so small that there's a lot of documentation needed - so much of this is actually in the patterns around how to use Redux effectively. Anyway, if you can point to some more concrete concerns or have specific suggestions on how we can improve things, I'm very interested - please feel free to comment over in the issues. [0] https://github.com/reduxjs/redux/issues/3321 [1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [2] https://github.com/reduxjs/redux/issues/3592 [3] https://redux-toolkit.js.org/tutorials/intermediate-tutorial [4] https://github.com/reduxjs/redux-toolkit/issues/371
In How I write Elm applications
Thank you, it's really great to hear that feedback! Totally agree that RTK works best if you already know how to write Redux code "by hand", so that you're familiar with the concepts and can see what the abstractions are doing for you. That said, my goal for that "Essentials" tutorial is that folks who have never used Redux before (like, say, someone in the middle of a typical bootcamp) would hopefully be able to start writing real Redux code using RTK and be productive with it, even if they don't understand everything that's going on under the hood. The feedback we've gotten on this new tutorial, as well as on RTK in general, tell me we've mostly managed to hit that goal. FWIW, my next task is to rewrite the existing "Basics/Advanced" tutorial sequence. It will still be a "bottom-up" explanation that teaches the underlying mechanics an
Read the rest
d shows how to do things "by hand", but I want to clean it up considerably to remove outdated references and show simpler patterns. If you're interested, my notes on how I want to redo it are here: https://github.com/reduxjs/redux/issues/3855 If you've got any feedback on the contents of the existing tutorial and what you'd like to see improved, please feel free to leave a comment there.
In React is becoming a black box
Strictly speaking, nothing says a reducer even _has_ to have a switch statement. A reducer can use _any_ conditional logic it wants inside: `if`, `for`, `while`, lookup tables, etc. It's just that the most obvious conditional construct for "checking multiple possible values of a single field" is a `switch` statement [0]. Having said that, we now officially teach our new Redux Toolkit package as the default way to write Redux code [1], and its `createSlice` API [2] does actually use a lookup table approach instead. On a related note: my next task is rewriting that existing Redux "Basics/Advanced" tutorial to modernize it, and I'm currently taking notes on what I do and don't like about it [3]. If you've got any relevant feedback on things you don't like or ways to improve that tutorial sequence, please feel free to comment and let me know
Read the rest
In In Defense of a Switch
I certainly get where you're coming from, and agree that all of the questions you listed are things we didn't express opinions on previously and had to decide for yourself. Still, the bulk of the concerns I've seen over time fall into the categories I've listed - I just really don't remember seeing many comments from folks who were concerned that they "weren't using it effectively" as a particular pain point. Perhaps that was being felt, but expressed in different ways? (I definitely think a lot of people _haven't_ been using it effectively, but didn't necessarily realize it.) In any case, the highly positive response to RTK and the docs work tells me we're headed in the right direction. My next task is to rewrite the existing low-level "Basics/Advanced" tutorial sequence to remove outdated references, show simpler patterns, and improve
Read the rest
explanations. I've got my notes on things I want to change here: https://github.com/reduxjs/redux/issues/3855 If you or anyone else has any particular feedback on things you don't like with that existing tutorial or would like to see covered better, please comment and let me know!
In Why we decided against GraphQL for local state management
Hey, I wrote this! Neat to see that someone else submitted here. I spent a _lot_ of time and effort trying to put this together [0]. The existing tutorial sequence has been read by a lot of people over the years, but it takes a "bottom-up" approach: it teaches how each of the Redux pieces work in isolation, and builds up from there. That tutorial is also one of the oldest parts of our docs, and it was written in a much different era for a different audience: when "Flux" was still a thing, and people were looking at migrating away from Backbone. This new "Redux Essentials" tutorial has several goals: - It takes a "top-down" approach, with a focus on "how to use Redux, the right way", rather than "how it works". - It teaches our latest recommended patterns and practices, like using our official Redux Toolkit package [1] for writing your
Read the rest
Redux logic, and using the React-Redux hooks API [2] instead of the earlier `connect` API. - It shows how to build a somewhat more realistic example app, and explains various Redux concepts and APIs as we add new features. - Improve explanations and make it more clear how Redux integrates into a typical React app, and how data flows through a Redux application. I'm hopeful that this new tutorial will make it easier for people to jump right into learning Redux and building something useful with it, and they can look more into "how does it work inside?" later. The new tutorial is part of my ongoing effort to rewrite most of the Redux docs [3]. I'd previously written the new "Redux Style Guide" docs page [4], which lists our recommended best practices. My next task is to rewrite the existing "Basics/Advanced" tutorial sequence [5]. My plans for that section are: - Drop all outdated references ("Flux", "containers", etc) - Show simpler patterns (inline action types like `{type: "todos/addTodo"}` vs `const ADD_TODO = "ADD_TODO"`, single-file Redux logic) - CodeSandbox examples - Show React-Redux hooks - Improve explanation flow If anyone's got any feedback, suggestions, or questions, let me know! [0] https://github.com/reduxjs/redux/pull/3740#issuecomment-6508... [1] https://redux-toolkit.js.org [2] https://react-redux.js.org/api/hooks [3] https://github.com/reduxjs/redux/issues/3592 [4] https://redux.js.org/style-guide/style-guide [5] https://github.com/reduxjs/redux/issues/3595#issuecomment-55...
In Redux Overview and Concepts – Reimagined Redux Tutorial
> E.g. I couldn’t for the life of me annotate the return value of the pipe function Don't feel bad, no one can do that (yet! I think it should be possible with Variadic Tuple Types, coming in TS 4). There are a couple of attempts[1][2], but they all lack in some way. Redux does it with a boatload of overloads [3]. 1: https://dev.to/ascorbic/creating-a-typed-compose-function-in... 2: https://stackoverflow.com/a/53066700/1586229 3: https://github.com/reduxjs/redux/blob/686d29b5d4e2dcb6709c16...
In Svelte and TypeScript
I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testing library”. The library authors are complicit in this. Rather than showing the pros and cons of both, the trends are being pushed, leading people to falsely believe they must rewrite their whole code base in my experience. The troubling part for me is often those creating these trends may be working on a very different type of app. When you’re writing something complicated, and the ecosystem is dominated by patterns (also prea
Read the rest
ched by Kent) that work best in simpler apps like “only write integration tests” it can be frustrating. If Kent thought enzyme promoted anti patterns he could have technically made a docs PR or just written a thin layer on top of enzyme. Now we have yet another divisive issue. Getting him early access to new react apis and officially recommending RTL in the react docs (while he sells his training videos) make it sit worse with me. It doesn’t feel like the trends are always based on the merits, it feels more like “not invented here” and “nepotism” driving some of these trends for sure.
In Do Not Follow JavaScript Trends

Showing the 15 most recent of 151 sources. Enable JavaScript to search and browse every indexed mention.

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.