Predictable state container for JavaScript apps

Related tags

Utility redux

Redux Logo

Redux is a predictable state container for JavaScript apps. (Not to be confused with a WordPress framework – Redux Framework)

It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. On top of that, it provides a great developer experience, such as live code editing combined with a time traveling debugger.

You can use Redux together with React, or with any other view library. It is tiny (2kB, including dependencies), and has a rich ecosystem of addons.

build status npm version npm downloads redux channel on discord Changelog #187


Redux Toolkit is our official recommended approach for writing Redux logic. It wraps around the Redux core, and contains packages and functions that we think are essential for building a Redux app. Redux Toolkit builds in our suggested best practices, simplifies most Redux tasks, prevents common mistakes, and makes it easier to write Redux applications.

npm install @reduxjs/toolkit react-redux

For the Redux core library by itself:

npm install redux

For more details, see the Installation docs page.


The Redux docs are located at

For PDF, ePub, and MOBI exports for offline reading, and instructions on how to create them, please see: paulkogel/redux-offline-docs.

For Offline docs, please see: devdocs

Learn Redux

Redux Essentials Tutorial

The Redux Essentials tutorial is a "top-down" tutorial that teaches "how to use Redux the right way", using our latest recommended APIs and best practices. We recommend starting there.

Redux Fundamentals Tutorial

The Redux Fundamentals tutorial is a "bottom-up" tutorial that teaches "how Redux works" from first principles and without any abstractions, and why standard Redux usage patterns exist.

Additional Tutorials

Other Resources

Help and Discussion

The #redux channel of the Reactiflux Discord community is our official resource for all questions related to learning and using Redux. Reactiflux is a great place to hang out, ask questions, and learn - please come and join us there!

Before Proceeding Further

Redux is a valuable tool for organizing your state, but you should also consider whether it's appropriate for your situation. Please don't use Redux just because someone said you should - instead, please take some time to understand the potential benefits and tradeoffs of using it.

Here are some suggestions on when it makes sense to use Redux:

  • You have reasonable amounts of data changing over time
  • You need a single source of truth for your state
  • You find that keeping all your state in a top-level component is no longer sufficient

Yes, these guidelines are subjective and vague, but this is for a good reason. The point at which you should integrate Redux into your application is different for every user and different for every application.

For more thoughts on how Redux is meant to be used, please see:

Developer Experience

Dan Abramov (author of Redux) wrote Redux while working on his React Europe talk called “Hot Reloading with Time Travel”. His goal was to create a state management library with a minimal API but completely predictable behavior. Redux makes it possible to implement logging, hot reloading, time travel, universal apps, record and replay, without any buy-in from the developer.


Redux evolves the ideas of Flux, but avoids its complexity by taking cues from Elm. Even if you haven't used Flux or Elm, Redux only takes a few minutes to get started with.

Basic Example

The whole global state of your app is stored in an object tree inside a single store. The only way to change the state tree is to create an action, an object describing what happened, and dispatch it to the store. To specify how state gets updated in response to an action, you write pure reducer functions that calculate a new state based on the old state and the action.

import { createStore } from 'redux'

 * This is a reducer - a function that takes a current state value and an
 * action object describing "what happened", and returns a new state value.
 * A reducer's function signature is: (state, action) => newState
 * The Redux state should contain only plain JS objects, arrays, and primitives.
 * The root state value is usually an object.  It's important that you should
 * not mutate the state object, but return a new object if the state changes.
 * You can use any conditional logic you want in a reducer. In this example,
 * we use a switch statement, but it's not required.
function counterReducer(state = { value: 0 }, action) {
  switch (action.type) {
    case 'counter/incremented':
      return { value: state.value + 1 }
    case 'counter/decremented':
      return { value: state.value - 1 }
      return state

// Create a Redux store holding the state of your app.
// Its API is { subscribe, dispatch, getState }.
let store = createStore(counterReducer)

// You can use subscribe() to update the UI in response to state changes.
// Normally you'd use a view binding library (e.g. React Redux) rather than subscribe() directly.
// There may be additional use cases where it's helpful to subscribe as well.

store.subscribe(() => console.log(store.getState()))

// The only way to mutate the internal state is to dispatch an action.
// The actions can be serialized, logged or stored and later replayed.
store.dispatch({ type: 'counter/incremented' })
// {value: 1}
store.dispatch({ type: 'counter/incremented' })
// {value: 2}
store.dispatch({ type: 'counter/decremented' })
// {value: 1}

Instead of mutating the state directly, you specify the mutations you want to happen with plain objects called actions. Then you write a special function called a reducer to decide how every action transforms the entire application's state.

In a typical Redux app, there is just a single store with a single root reducing function. As your app grows, you split the root reducer into smaller reducers independently operating on the different parts of the state tree. This is exactly like how there is just one root component in a React app, but it is composed out of many small components.

This architecture might seem like a lot for a counter app, but the beauty of this pattern is how well it scales to large and complex apps. It also enables very powerful developer tools, because it is possible to trace every mutation to the action that caused it. You can record user sessions and reproduce them just by replaying every action.

Redux Toolkit Example

Redux Toolkit simplifies the process of writing Redux logic and setting up the store. With Redux Toolkit, that same logic looks like:

import { createSlice, configureStore } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    value: 0
  reducers: {
    incremented: state => {
      // Redux Toolkit allows us to write "mutating" logic in reducers. It
      // doesn't actually mutate the state because it uses the Immer library,
      // which detects changes to a "draft state" and produces a brand new
      // immutable state based off those changes
      state.value += 1
    decremented: state => {
      state.value -= 1

export const { incremented, decremented } = counterSlice.actions

const store = configureStore({
  reducer: counterSlice.reducer

// Can still subscribe to the store
store.subscribe(() => console.log(store.getState()))

// Still pass action objects to `dispatch`, but they're created for us
// {value: 1}
// {value: 2}
// {value: 1}

Redux Toolkit allows us to write shorter logic that's easier to read, while still following the same Redux behavior and data flow.


Almost all examples have a corresponding CodeSandbox sandbox. This is an interactive version of the code that you can play with online.


“Love what you're doing with Redux” Jing Chen, creator of Flux

“I asked for comments on Redux in FB's internal JS discussion group, and it was universally praised. Really awesome work.” Bill Fisher, author of Flux documentation

“It's cool that you are inventing a better Flux by not doing Flux at all.” André Staltz, creator of Cycle


Special thanks to Jamie Paton for handing over the redux NPM package name.


You can find the official logo on GitHub.

Change Log

This project adheres to Semantic Versioning. Every release, along with the migration instructions, is documented on the GitHub Releases page.


The work on Redux was funded by the community. Meet some of the outstanding companies that made it possible:

See the full list of Redux patrons, as well as the always-growing list of people and companies that use Redux.



  • Reducer Composition with Effects in JavaScript

    Reducer Composition with Effects in JavaScript

    Inspired by this little tweetstorm.

    Problem: Side Effects and Composition

    We discussed effects in Redux for ages here but this is the first time I think I see a sensible solution. Alas, it depends on a language feature that I personally won’t even hope to see in ES. But would that be a treat.

    Here’s the deal. Redux Thunk and Redux Saga are relatively easy to use and have different pros and cons but neither of them composes well. What I mean by that is they both need to be “at the top” in order to work.

    This is the big problem with middleware. When you compose independent apps into a single app, neither of them is “at the top”. This is where the today’s Redux paradigm breaks down—we don’t have a good way of composing side effects of independent “subapplications”.

    However, this problem has been solved before! If we had a fractal solution like Elm Architecture for side effects, this would not be an issue. Redux Loop implements Elm Architecture and composes well but my opinion its API is a bit too awkward to do in JavaScript to become first-class in Redux. Mostly because it forces you to jump through the hoops to compose reducers instead of just calling functions. If a solution doesn’t work with vanilla combineReducers(), it won’t get into Redux core.

    Solution: Algebraic Effects in JavaScript

    I think that what @sebmarkbage suggested in this Algebraic Effects proposal is exactly what would solve this problem for us.

    If reducers could “throw” effects to the handlers up the stack (in this case, Redux store) and then continue from they left off, we would be able to implement Elm Architecture a la Redux Loop without the awkwardness.

    We’d be able to use vanilla combineReducers(), or really, any kind of today’s reducer composition, without worrying about “losing” effects in the middle because a parent didn’t explicitly pass them up. We also would not need to turn every reducer into a generator or something like that. We can keep the simplicity of just calling functions but get the benefits of declaratively yielding the effects for the store (or other reducers! i.e. batch()) to interpret.

    I don’t see any solution that is as elegant and simple as this.

    It’s 2am where I live so I’m not going to put up any code samples today but you can read through the proposal, combine it with Redux Loop, and get something that I think is truly great.

    Of course I don’t hold my breath for that proposal to actually get into ES but.. let’s say we could really use this feature and Redux is one of the most popular JavaScript libraries this year so maybe it’s not such a crazy feature as one might think at first :smile: .

    cc people who contributed to relevant past discussions: @lukewestby @acdlite @yelouafi @threepointone @slorber @ccorcos

    opened by gaearon 209
  • Redux's brand id

    Redux's brand id

    Hi all,

    As some of you know we've been following, and lately using, Redux more extensively at UXtemple.

    We wanted to contribute with a nice touch and @tomatuxtemple, my friend and business partner, started designing a brand identity for Redux. Here's his first iteration at it:


    I hope you like it and would love to hear your thoughts about it :) Best, Darío

    opened by dariocravero 176
  • Trying to put API calls in the correct place

    Trying to put API calls in the correct place

    I'm trying to make a login success/error flow but my main concern is where I can put this logic.

    Currently I'm using actions -> reducer (switch case with action calling API) -> success/error on response triggering another action.

    The problem with this approach is that the reducer is not working when I call the action from the API call.

    am I missing something?


    import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';
    import Immutable from 'immutable';
    import LoginApiCall from '../utils/login-request';
    const initialState = new Immutable.Map({
      email: '',
      password: '',
    export default function user(state = initialState, action) {
      switch (action.type) {
        case LOGIN_ATTEMPT:
          return state;
        case LOGGED_FAILED:
          console.log('failed from reducer');
          return state;
          console.log('success', action);
          console.log('success from reducer');
          return state;


    import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';
    export function loginError(error) {
      return dispatch => {
        dispatch({ error, type: LOGGED_FAILED });
     * Should add the route like parameter in this method
    export function loginSuccess(response) {
      return dispatch => {
        dispatch({ response, type: LOGGED_SUCCESSFULLY });
        // router.transitionTo('/dashboard'); // will fire CHANGE_ROUTE in its change handler
    export function loginRequest(email, password) {
      const user = {email: email, password: password};
      return dispatch => {
        dispatch({ user, type: LOGIN_ATTEMPT });

    API calls

     // Use there fetch polyfill
     // The main idea is create a helper in order to handle success/error status
    import * as LoginActions from '../actions/LoginActions';
    const LoginApiCall = {
      login(userData) {
        fetch('http://localhost/login', {
          method: 'post',
          headers: {
            'Accept': 'application/json',
            'Content-Type': 'application/json',
          body: JSON.stringify({
            password: userData.password,
        .then(response => {
          if (response.status >= 200 && response.status < 300) {
          } else {
            const error = new Error(response.statusText);
            error.response = response;
            throw error;
        .catch(error => { console.log('request failed', error); });
    export default LoginApiCall;
    question docs 
    opened by 5h1rU 115
  • Request for Discussion: Redux

    Request for Discussion: Redux "boilerplate", learning curve, abstraction, and opinionatedness

    Resolution: use Redux Toolkit

    The ideas in this thread eventually turned into our official Redux Toolkit package. It includes utilities to simplify many common Redux use cases, including store setup, reducer definition, immutable update logic, creating entire "slices" of state automatically without writing any action creators or action types by hand, and even automatic data fetching and caching with the "RTK Query" API.

    For more details on what problems Redux Toolkit is meant to solve, see the "Vision for Redux Toolkit" manifesto I wrote .

    The number one complaint I see about Redux is that there's "too much boilerplate". I also frequently see complaints that there's too much to learn, too many other addons that are needed to do anything useful, and too many aspects where Redux doesn't have any opinion and therefore doesn't offer any kind of built-in guidance.

    I just had a discussion with @tannerlinsley regarding several of these aspects. We discussed the Jumpstate library, which is an abstraction layer around Redux, and how it was intended to ease the learning curve, as well as various philosophical opinions about what constitutes "good" Redux usage.

    Out of that, we came up with several questions that I would like to bring up for wider discussion:

    Key points

    Boilerplate / Verbosity

    • Redux is not intended to be the "most concise way of doing things", but rather to make data flow obvious and readable
    • Docs are written in a deliberately verbose style for clarity and learning, and not specifically intended as "the one true way to write Redux code", but that style has been somewhat blindly adopted (or, sometimes, resulted in rejecting Redux)
    • Frequent complaints about "boilerplate", such as "too many files", "use of action creators", etc

    Abstractions and Learning

    • The core Redux library itself is effectively feature-complete, but there's lots of interesting addons and tools being built by the community
    • Various abstraction libs have been built to "ease learning curve" or "make things more OOP", but most of these are not really "idiomatic" Redux usage
    • Redux learning curve can be steep, but once you grasp concepts, the need for abstraction layers often goes away


    • What are the "boilerplate" complaints mostly about?
    • What are the hardest aspects of Redux for new learners?
    • What are the "no opinions" areas that cause problems for people?

    Potential Solutions

    • What would idiomatic Redux usage with "less boilerplate" look like? How can we provide solutions to those complaints?
    • What possible abstractions could be created that simplify the process of learning and usage, but without actually hiding Redux (and would hopefully provide a migration/learning path to "base" Redux)?
    • How much of this could be solved with improved docs in some way?

    I would like to invite the community to offer up complaints, pain points, and concerns about using Redux, and hopefully also provide suggestions and ideas for solving those problems as well.

    opened by markerikson 109
  • Recommendations for best practices regarding action-creators, reducers, and selectors

    Recommendations for best practices regarding action-creators, reducers, and selectors

    My team has been using Redux for a couple of months now. Along the way I've occasionally found myself thinking about a feature and wondering "does this belong in an action-creator or a reducer?". The documentation seems a bit vague on this fact. (Or perhaps I've just missed where it's covered, in which case I apologize.) But as I've written more code and more tests I've come to have stronger opinions about where things should be and I thought it would be worth sharing and discussing with others.

    So here are my thoughts.

    Use selectors everywhere

    This first one is not strictly related to Redux but I'll share it anyway since it's indirectly mentioned below. My team uses rackt/reselect. We typically define a file that exports selectors for a given node of our state tree (eg. MyPageSelectors). Our "smart" containers then use those selectors to parameterize our "dumb" components.

    Over time we've realized that there is added benefit to using these same selectors in other places (not just in the context of reselect). For example, we use them in automated tests. We also use them in thunks returned by action-creators (more below).

    So my first recommendation is- use shared selectors everywhere- even when synchronously accessing data (eg. prefer myValueSelector(state) over state.myValue). This reduces the likelihood of mistyped variables that lead to subtle undefined values, it simplifies changes to the structure of your store, etc.

    Do more in action-creators and less in reducers

    I think this one is very important although it may not be immediately obvious. Business logic belongs in action-creators. Reducers should be stupid and simple. In many individual cases it does not matter- but consistency is good and so it's best to consistently do this. There are a couple of reasons why:

    1. Action-creators can be asynchronous through the use of middleware like redux-thunk. Since your application will often require asynchronous updates to your store- some "business logic" will end up in your actions.
    2. Action-creators (more accurately the thunks they return) can use shared selectors because they have access to the complete state. Reducers cannot because they only have access to their node.
    3. Using redux-thunk, a single action-creator can dispatch multiple actions- which makes complicated state updates simpler and encourages better code reuse.

    Imagine your state has metadata related to a list of items. Each time an item is modified, added to, or removed from the list- the metadata needs to be updated. The "business logic" for keeping the list and its metadata in sync could live in a few places:

    1. In the reducers. Each reducer (add, edit, remove) is responsible for updating the list as well as the metadata.
    2. In the views (container/component). Each view that invokes an action (add, edit, remove) it is also responsible for invoking an updateMetadata action. This approach is terrible for (hopefully) obvious reasons.
    3. In the action-creators. Each action-creator (add, edit, remove) returns a thunk that dispatches an action to update the list and then another action to updates the metadata.

    Given the above choices, option 3 is solidly better. Both options 1 and 3 support clean code sharing but only option 3 supports the case where list and/or metadata updates might be asynchronous. (For example maybe it relies on a web worker.)

    Write "ducks" tests that focus on Actions and Selectors

    The most efficient way to tests actions, reducers, and selectors is to follow the "ducks" approach when writing tests. This means you should write one set of tests that cover a given set of actions, reducers, and selectors rather than 3 sets of tests that focus on each individually. This more accurately simulates what happens in your real application and it provides the most bang for the buck.

    Breaking it down further I've found that it's useful to write tests that focus on action-creators and then verify the outcome using selectors. (Don't directly test reducers.) What matters is that a given action results in the state you expect. Verifying this outcome using your (shared) selectors is a way of covering all three in a single pass.

    opened by bvaughn 106
  • What are the disadvantages of storing all your state in a single immutable atom?

    What are the disadvantages of storing all your state in a single immutable atom?

    I understand that this is the principle underlying all of redux, and that it comes with all these awesome benefits that are pretty well known by now.

    However, I feel that one place that redux is lacking in, is that it doesn't openly describe the conceptual disadvantages of using this architecture. Perhaps this is a good choice since you want people to not shy away due to the negatives.

    I'm just curious because it applies not just to redux, but in some capacity to other things like Om, datomic and that talk about turning the database inside out. I like redux, I like Om, I'm interested in datomic, and I really liked that talk.

    But for all the searching I've done, it's hard to find people critical of the single immutable store. This is an example, but it just seems to have a problem more with the verbosity of redux than with the actual architecture.

    The only things I can think of is that perhaps it takes more memory to keep storing copies of your state, or that it's a little harder to rapidly protoype with redux.

    Because you guys have probably put a lot more thought into this than I have, could you help elucidate this for me?

    question discussion docs 
    opened by AriaFallah 91
  • Port to TypeScript

    Port to TypeScript

    Do you want to request a feature or report a bug?


    What is the current behavior?

    Redux publishes a manually created index.d.ts file. This also affects reselect, redux-devtools, and redux-thunk.

    If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar.

    Explanation of why this isn't recommended:

    To summarize, type declarations should either be generated from TypeScript source code or shared in DefinitelyTyped, which allows contributors to edit the types without having to edit the original package. This can also help alleviate maintenance and versioning issues regarding Redux users that write their code in TypeScript. Many issues about TypeScript compatibility could be moved to the dedicated DefinitelyTyped community if the types were separated, and the types could have breaking changes released without interfering with non-TypeScript users.

    What is the expected behavior?

    Redux either removes its type declaration (should be a breaking change) and moves them to DefinitelyTyped (recommended) or is ported to TypeScript (could be difficult and requires additional maintenance, but makes the types more accurate).

    Which versions of Redux, and which browser and OS are affected by this issue? Did this work in previous versions of Redux?

    3.4.0+ (all versions that publish index.d.ts)

    discussion feedback wanted typescript 
    opened by nickmccurdy 86
  • Add first-class support for store enhancers to createStore() API

    Add first-class support for store enhancers to createStore() API

    (Updated to @timdorr’s suggestion in


    - const createStoreWithMiddleware = applyMiddleware(thunk, logger)(createStore)
    - const store = createStoreWithMiddleware(rootReducer, initialState)
    + const store = createStore(
    +   rootReducer,
    +   initialState,
    +   applyMiddleware(thunk, logger)
    + )

    Fixing the Store Enhancer API

    It’s often said that creating a store with enhancers like applyMiddleware() or DevTools.instrument() is weird because it just looks outlandish in JavaScript to compose functions in such a savage way:

    // bad
    const createStoreWithMiddleware = applyMiddleware(thunk, logger)(createStore)
    const store = createStoreWithMiddleware(reducer, initialState)
    // and even worse
    const finalCreateStore = compose(
      applyMiddleware(thunk, logger),
    const store = finalCreateStore(reducer, initialState)

    Here, we propose to integrate the idea of store enhancers into the createStore() API itself. This would keep the concept of enhancers and their API exactly the same but will simplify applying them in real projects. This is also not a breaking change because we didn’t support any additional arguments to createStore() previously.

    // not bad
    const store = createStore(
      applyMiddleware(thunk, logger)
    // not too bad either
    const store = createStore(
        applyMiddleware(thunk, logger),

    It has often been suggested that we do something about this uneasiness but unfortunately I don’t think there was ever any specific proposal that dealt with store enhancers correctly. Most proposals I saw were focused on the middleware which is just one kind of a store enhancer. I think that this proposal should satisfy the needs of the community in terms of a simple API without compromising on the power of store enhancers.

    What do you think?

    enhancement help wanted 
    opened by gaearon 84
  • Support for typed actions (Typescript)

    Support for typed actions (Typescript)

    Related to these two issues:


    Hi Dan,

    The company I am with is using Redux as well as Typescript, and we would like to add some additional compile-time guarantees to our actions. Currently this isn't possible because of the restriction that actions must be plain objects. You said that this is because 'record/replay and associated features won't work with an action class' and I get that those are valuable features and don't want to lose them. But I had code using Typescript classes that (when the redux devtools were enabled) could still record, cancel and replay actions just fine (using the code I posted in issue 355).

    When I remove the devtools I just get errors from that check that actions are plain objects and execution stop there. To me it seems like it is too strict, checking more than is really required. I would much rather have a check that requires that the actions are serializable. I know performance is a concern - IMO it shouldn't have to guarantee/prove they are serializable, just check that the action objects themselves say that they are, and then trust them. (Not sure why the check doesn't also fail when devtools are enabled - maybe you can shed light on that).

    I would really like to be able to leverage the advantages of both Typescript and Redux. Hope you can help me (and others using both of these tools) arrive at a solution.

    I also want to reiterate that (as much as I wish it were otherwise!) Typescript does not have discriminated unions, so solutions based on that approach will not work.

    Thank you!

    opened by nickknw 71
  • Redux screencast series on Egghead

    Redux screencast series on Egghead

    If you're following Redux repo but haven't dived into it yet, or are confused about some of its fundamental aspects, you'll be happy to learn that Egghead has just published my Getting Started with Redux series.

    It covers the same topics as the “Basics” part of the docs, but hopefully dives a little bit deeper and ensures you really understand the Redux fundamentals.

    I plan to create more content about Redux on Egghead—this time, for subscribers only. It will feature more advanced topics. If you have particular suggestions, please let me know in this thread!

    feedback wanted 
    opened by gaearon 69
  • Relay and Redux

    Relay and Redux

    So now that Relay and GraphQL are out in the open, we should start a conversation about how this relates to Redux. Anyone have thoughts on Relay will effect both the core Redux library, and what ecosystem tools will need to be built out to accommodate it?

    discussion ecosystem 
    opened by nhagen 69
  • Redux FAQ: Organizing State Outdated

    Redux FAQ: Organizing State Outdated

    What docs page needs to be fixed?

    • Faq:
    • Redux FAQ: Organizing State:

    What is the problem?

    I was looking at this today and this FAQ seems outdated.

    In particular, it links to two community packages that have been out of date since 2015:

    redux-component, redux-react-local

    It also makes mention of this.setState().

    There is no mention of RTK, useSelector, or react hooks.

    As a beginner, this is a very confusing page to come across via Google.

    What should be changed to fix the problem?

    Ideally - it should be updated. If not - it should be marked as depreciated or removed.

    opened by wadsworj 1
  • Add a new

    Add a new "TS Usage" page to the Redux Essentials tutorial

    The "Essentials" tutorial currently uses only plain JS for all of the examples and content.

    If you want to learn how to use Redux with TS, we have two separate pages:

    • "TS Quick Start", which just gives quick examples of inferring types from the store, defining typed hooks, declaring slice state and action types, and using the hooks
    • The longer "TS Usage" guide page, which is a laundry list of various use cases

    Unfortunately neither of those have any larger context for how TS gets used in practice.

    I want the "Essentials" tutorial to cover TS usage. However, some of the suggested approaches are impractical:

    • If we rewrite the entire tutorial to be TS-first/only, then it adds an extra barrier to learning for anyone who doesn't know TS yet. Since we do have a lot of folks still being pushed into Redux fairly early on, this is likely to be a significant number of people who would now have to decipher TS on top of Redux basics
    • The next obvious approach is "use a TS/JS language toggle". We already do this in the RTK docs for the examples, and we did just add that same capability to the Redux core docs. However... the tutorial is way more than just some example snippet blocks. It's an entire app repo with a commit history. In addition, there's a ton of explanations of "here's what this code is doing", and the point of this is to explain how to use TS for as much of the actual app code as possible. If we were to make all the code toggleable, then we'd somehow have to start toggling large chunks of explanation, too. Technically feasible, but this would be extremely hard to write coherently.

    I think the best approach is to add a "Redux Essentials, Part 9: Redux and TypeScript" page that would cover the TS material as a capstone to the tutorial sequence. I'm picturing a page that would run through some of the key code sections and API examples from the earlier pages in the tutorial, and explain how you'd write that same code from scratch with TS.

    There was also a great suggestion on Twitter here at :

    I can see prefacing the JS docs with a "We'll cover the TS-specific stuff at the end" note. Then, where it's important in the JS docs for TS folks to know about, say, inference adapters, add a "TS" badge that references the relevant section at the end.

    I think that strikes a good balance between showing meaningful examples of TS usage, and not having to maintain multiple copies or weird back-and-forths in the main tutorial sequence.

    opened by markerikson 2
  • [Docs] Add admonitions warning about tutorials teaching

    [Docs] Add admonitions warning about tutorials teaching "redux" vs "redux toolkit"

    What docs page needs to be fixed?

    • Home Page
    • Tutorial Pages

    What is the problem?

    As both a new developer (1-2 years experience) and new to the redux ecosystem, I'll be the first to admit that I'm guilty of the comment made by @markerikson in his Twitter post. Essentially when I, as I'm sure many (if not most) new devs, want to learn about a way to have a global state or share state across react components, the most vocal solution is always redux, leading us to follow these next steps:

    1. Google "redux tutorial" or "redux"
    2. (sometimes) See the official redux page and click it, then go to the docs site (either the home page or the "Redux Fundamentals" page depending on what the first result is)
    3. Get "scared" at how much information there is on the docs site
    4. Click the next-closest blog or video tutorial because they look less intimidating
    5. Learn from there...

    The obvious (in hindsight) flaw in this plan is that the next-closest tutorials normally use pre-toolkit redux. The only reason I noticed redux toolkit exists is that people kept complaining about the "boilerplate" and "complexity" that redux has and I had started looking for alternatives (zustand, recoil, jotai, etc).

    There's definitely a larger fundamental issue with the documentation community in steps 2 and 3, where beginner devs would historically look at the docs of some library or framework only to realize that the docs don't have enough focus on the practical side of the tool versus a blog or video teaching how to make an example application with the tool. This problem might be a bit too out of scope for this little issue ticket.

    Instead I want to focus on the "pre-toolkit redux tutorials" issue, hopefully getting people to come to the 2 conclusions stated in the official documentation:

    We specifically recommend that our users should use Redux Toolkit (the @reduxjs/toolkit package), and should not use the legacy redux core package for any new Redux code today!

    The redux core package still works, but today we consider it to be obsolete.

    What should be changed to fix the problem?

    Place a red "warning" admonition on the home page and at the top of tutorial pages saying something along the lines of:

    The redux core package still works, but today we consider it to be obsolete. We specifically recommend that our users should use Redux Toolkit (the @reduxjs/toolkit package), and should not use the legacy redux core package for any new Redux code today! Even for existing applications, we recommend at least switching out createStore for configureStore as the dev-mode middleware will also help you catch accidental mutation and serializability errors in existing code bases. If you still want to learn outside the official docs, then unless specifically needed, please prioritize tutorials teaching Redux Toolkit as they are more likely to teach the simpler way of using redux.

    (Note that I directly copied and pasted most of these sentences from the official docs)

    This can hopefully catch a large handful of developers at step 2, at least sending them in a better direction when working on one of two scenarios:

    • A developer working on a brand new project who wants to implement a global state or shared state across React components
    • A developer working on an established project that is currently using the older way of redux, unaware of the existence of redux toolkit (and so won't consider that an easier way exists!)
    opened by mickremedi 0
  • Enable prefer type-only imports

    Enable prefer type-only imports

    This PR really doesn't fit under any of the categories available. Sorry if this kind of PR is not accepted, I will close if it's not.

    This PR enables prefer type-only imports eslint rule. I noticed that redux-toolkit has this rule enabled so I thought it'd be good to port it over redux as well.

    Related to issue:

    opened by raulsanchez1024 2
  • Enable type-only imports

    Enable type-only imports

    Enables @typescript-eslint/consistent-type-imports eslint rule. I noticed redux-toolkit has this rule enabled so I thought it'd be a good idea to port this over to redux too.

    opened by raulsanchez1024 0
  • [tutorial] Reactions update is broken in <SinglePostPage />

    [tutorial] Reactions update is broken in

    Steps To Reproduce

    1. Click "View Post" for any post
    2. Click the reactions

    Link to code example: The codesandbox here

    The current behavior

    Reactions work for the post list page, not for the single post page.

    The expected behavior

    1. Reactions work for single post page
    2. Reactions sync in both list list page and single post page.
    opened by dpyzo0o 6
  • v4.2.0(Apr 18, 2022)

    This release marks the original createStore API as @deprecated to encourage users to migrate to Redux Toolkit, and adds a new legacy_createStore API as an alias without the deprecation warning.


    Redux Toolkit (the @reduxjs/toolkit package) is the right way for Redux users to write Redux code today:

    Unfortunately, many tutorials are still showing legacy "hand-written" Redux patterns, which result in a much worse experience for users. New learners going through a bootcamp or an outdated Udemy course just follow the examples they're being shown, don't know that RTK is the better and recommended approach, and don't even think to look at our docs.

    Given that, the goal is to provide them with a visual indicator in their editor, like ~~createStore~~ . When users hover over the createStore import or function call, the doc tooltip recommends using configureStore from RTK instead, and points them to that docs page. We hope that new learners will see the strikethrough, read the tooltip, read the docs page, learn about RTK, and begin using it.

    To be extremely clear:


    We are just marking createStore as "deprecated":

    "the discouragement of use of some feature or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use"

    For additional details, see the extensive discussion in .


    • RTK provides a vastly improved Redux usage experience, with APIs that simplify standard usage patterns and eliminate common bugs like accidental mutations
    • We've had suggestions to merge all of RTK into the redux core package, or fully deprecate the entire redux package and rename it to @reduxjs/core. Unfortunately, those bring up too many complexities:
      • We already had a package rename from redux-starter-kit to @reduxjs/toolkit, and all of our docs and tutorials have pointed to it for the last three years. I don't want to put users through another whiplash package transition for no real benefit
      • Merging or rearranging our packages would effectively require merging all of the Redux repos into a single monorepo. That would require hundreds of hours of effort from us maintainers, including needing to somehow merge all of our docs sites together. We don't have the time to do that.
    • I don't want to add runtime warnings that would be really annoying

    So, this is the minimum possible approach we can take to reach out to users who otherwise would never know that they are following outdated patterns, while avoiding breaking running user code or having to completely rewrite our package and repo structure.


    When a user imports createStore in their editor, they will see a visual strikethrough. Hovering over it will show a doc tooltip that encourages them to use configureStore from RTK, and points to an explanatory docs page:


    Again, no broken code, and no runtime warnings.

    If users do not want to see that strikethrough, they have three options:

    • Follow our suggestion to switch over to Redux Toolkit and configureStore
    • Do nothing. It's just a visual strikethrough, and it doesn't affect how your code behaves. Ignore it.
    • Switch to using the legacy_createStore API that is now exported, which is the exact same function but with no @deprecation tag. The simplest option is to do an aliased import rename:


    What's Changed

    • Mark createStore as deprecated, and add legacy_createStore alias by @markerikson in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip)
  • v5.0.0-alpha.0(Oct 30, 2021)

    ⚠️ This is an experimental alpha release. Things may break. If they do, let us know! ⚠️

    This release contains the TypeScript codebase conversion work we did in 2019, to let users check compatibility and see if this is suitable for publishing.


    TypeScript Conversion

    In 2019, we began a community-powered conversion of the Redux codebase to TypeScript. The original effort was discussed in #3500: Port to TypeScript, and the work was integrated in PR #3536: Convert to TypeScript.

    However, the TS-converted code in master has sat around since then, unused and unpublished, due to concerns about possible compatibility issues with the existing ecosystem (as well as general inertia on our part).

    Given the recent updates to Reselect and Redux Thunk, where we successfully published new minor builds that contained conversions to TS and significant rewrites/improvements to the TS types, it's worth publishing the current conversion as an alpha to give the community a chance to report any compatibility issues.

    In theory, this should be almost identical in both runtime behavior and types to the recently released 4.1.2 build, but it's very likely that some of the changes may cause types issues.

    Please try this out and let us know how it works! We're especially interested in any TS types compatibility issues you might see.

    You can provide feedback in #4129: Evaluate current Redux TS port status to determine remaining work for a 5.0 release


    Source code(tar.gz)
    Source code(zip)
  • v4.1.2(Oct 28, 2021)

    This release fixes a small specific TS types issue where state types that had a nested unknown field inside would cause compilation failures when used as the preloadedState argument.

    What's Changed

    • Fix preloaded state type by @phryneas in

    Full Changelog:

    Source code(tar.gz)
    Source code(zip)
  • v4.1.1(Aug 3, 2021)

  • v4.1.0(Apr 24, 2021)

    This release shrinks our bundle size via error message extraction, updates several error messages for clarity, and optimizes our list of runtime dependencies.

    Overall, version 4.1 shrinks from 2.6K min+gz to 1.6K min+gz thanks to these changes.

    Be sure to check out the Redux Toolkit 1.6 alpha containing our new "RTK Query" data fetching APIs! It also includes Redux 4.1 as a dependency.


    Error Message Extraction and Improvements

    We now extract all of our error messages from production builds in order to save on bundle size, using a technique inspired from React's error code extraction. The error messages will still show as normal in development, but in production they will reference a specific numeric error code and provide a link to a Redux docs page that has the full error message.

    An example of this is: , which shows the "can't subscribe while reducers are executing" error.

    The error code extraction saves about 800 bytes out of a production build.

    Thanks to @andrewmcgivery for doing all the hard work on implementing the error extraction!

    We've also updated many of our error messages to provide additional details at runtime about what happened, especially runtime type checks such as "actions must be plain objects". They now provide a more specific type for the unexpected value, such as indicating promise or function:

        expect(() => store.dispatch(() => {})).toThrow(
          /the actual type was: 'function'/
        expect(() => store.dispatch(new Date())).toThrow(
          /the actual type was: 'date'/

    Dependency Updates

    We've updated the list of runtime dependencies for Redux:

    • We inlined the symbol-observable polyfill. This shrinks bundle size by a few bytes,
    • We've removed the legacy loose-envify dependency, which was only ever needed by Browserify users. If you still happen to be using Browserify, please review your build settings and see if you need to make any updates.
    • We now explicitly depend on @babel/runtime to extract some additional helpers out of our bundle. It's likely that your app already is pulling in those helpers anyway, so that removes some potential duplication.

    Typing Tweaks

    We've merged fixes for a couple edge cases in the 4.x TS typings related to state types.


    • Remove symbol-observable and loose-envify deps (#4058 - @markerikson)
    • Port error extraction setup from master (#4057 - @markerikson)
    • Port build dependencies from master into 4.x (#4056 - @markerikson)
    • Rewrite Redux core error messages (#4055 - @markerikson)
    • feat: mangle error codes to error indexes (#3920 - @andrewmcgivery)
    • fix: Declare "EmptyObject" interface to wrap $CombinedState (#4031 - @JacobLey)
    • Only apply mapped types to un-branded types (#3805 - @invliD)
    Source code(tar.gz)
    Source code(zip)
  • v4.1.0-alpha.0(Apr 4, 2021)

    This pre-release for 4.1.0 shrinks our bundle size via tooling updates, and updates several error messages for clarity. This is all the changes we plan to have for 4.1, so if feedback looks good, we'll release 4.1.0 shortly.

    Changelog Summary

    The 4.1.0 release will have a more complete changelog, but summarizing:

    • Shrinks our bundle sizes by extracting error messages from production builds and replacing them with error codes (similar to React). Thanks to @andrewmcgivery for implementing this!
    • Inlines the symbol-observable polyfill
    • Drops the legacy loose-envify dependency
    • Externalizes the @babel/runtime helpers
    • Fixed a TS typedef to work better with TS 4.3

    We've also updated the error messages to clarify what's happening, provide more details when runtime type checks fail, and link to relevant documentation.


    • Merge pull request #4058 from reduxjs/feature/4x-remove-legacy-deps 9a1d065e
    • Inline the symbol-observable polyfill 0d7d94d8
    • Remove symbol-observable and loose-envify deps b882d9af
    • Merge pull request #4057 from reduxjs/feature/4x-error-messages f3680b5b
    • Port error message updates from master 46f5c94d
    • Port error extraction setup from master 05d55057
    • Merge pull request #4056 from reduxjs/feature/4x-update-build-tooling 82ad6363
    • fix: Declare "EmptyObject" interface to wrap $CombinedState (#4031) c3cbe2e0
    • Only apply mapped types to un-branded types (#3805) e23aa592

    Source code(tar.gz)
    Source code(zip)
  • v4.0.5(Dec 24, 2019)

    This release includes a memory leak fix, and a fix for removing reducers with replaceReducer and combineReducers.

    There are also some TypeScript changes, which require version 3.5 or higher. This also removes our DeepPartial type, which wasn't intended to be a public API. If you need this type, you can find an equivalent of likely higher quality in the utility-types package.

    Speaking of TypeScript, we are done with converting the code to TypeScript on master and are looking to get some TS improvements in before launching 5.0. If you're interested in helping, feel free to submit a PR with anything you'd like to contribute.


    • Clear current listeners on store unsubscribe (#3475 by @dmitrysteblyuk)
    • Fix for combineReducers when replaceReducers removes a reducer (#3490 by @anubhavgupta)
    • TypeScript: Add strict type inference overload for combineReducers (#3484 by @ChrisAckerman)
    • TypeScript: Preloaded state is now selectively partial (instead of deeply partial) (#3485 by @ChrisAckerman)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.4(Jul 10, 2019)

  • v4.0.3(Jul 9, 2019)

    This is a quick revert of a change to our typings that broke compatibility. Apologies for the problems.

    Also, if you are experiencing type errors related to [Symbol.observable], please ensure you have the same version of redux installed for all your dependencies with npm ls redux.


    • Reverts the change to combineReducers' type parameters (#3467 by @timdorr)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.2(Jul 9, 2019)

    This is a very minor release with some nice improvements to our TypeScript type definitions. Enjoy!


    • Iterate in combineReducers using for in (#3371 by @pvorona)
    • Fix DeepPartial type (#3369 by @OliverJAsh)
    • Add types for Observable interface (#3067 by @pinyin)
    • Make reducer optional in JSDocs (#3408 by @pingfengafei)
    • Infer action types from combineReducers (#3411 by @appden)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.1(Oct 13, 2018)

    A very minor release. We've upgraded to Babel 7 internally and now provide a .mjs file which you can import cleanly into browsers that support ES modules natively. Enjoy!


    • Update mixed NODE_ENV message for Webpack 4 (4a215fb by @timdorr)
    • Add unpkg field to package.json (#3003 by @andrewbridge)
    • Use same return type for both StoreCreator signatures (#2985 by @reklawnos)
    • Mark StoreCreator's preloadedState argument as optional (#3080 by @srittau)
    • Add ES browser build (#3143 by @TimvdLippe)
    • Throw an error if createStore is passed several enhancers (#3151 by @selbekk)
    • Upgrade to Babel 7 (b9ee1cf by @timdorr)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Apr 17, 2018)

    Redux 4 is here! 🎉

    If you're a React user, this is going to be a lot like going from 15 to 16. Not a lot of user-facing changes, but some interesting improvements under the hood.

    The major changes (#1342) are around our TypeScript definitions, bundled CommonJS and ES builds, throwing if you subscribe or getState from a reducer, and a bunch of other smaller things. The full changes are listed below.



    • Tons of docs updates. Thanks @markerikson and the Redux community for all your PRs!
    • Make middleware API dispatch pass through all call arguments (#2560 by @Asvarox)
    • Refactor applyMiddleware to reduce confusion around createStore args (#2201 by @jimbolla)
    • Make bindActionCreators transparently pass this (#2641 by @Parakleta)
    • Remove @private flag on AnyAction type definition (#2510 by @alexmngn)
    • Fixed quote types inconsistency in a warning message (#2297 by @Andarist)
    • Move ActionTypes to a private export (b62248b by @timdorr)
    • Throw if getState, subscribe, or unsubscribe called while dispatching (including inside a reducer) (#1569 by @mjw56)
    • Warn when dispatching during Middleware setup (#1485 by @timdorr)
    • Mapped type for combineReducers in index.d.ts (#2182 by @mkusher)
    • Remove legacy jsnext entry (#2284 by @TrySound)
    • Revamp TypeScript typing with more type safety (#2563 by @pelotom)
    • Fix TS definitions test for new Dispatch typing (#2674 by @pelotom)
    • Add DeepPartial type for preloaded state (#2679 by @aikoven)
    • Bundle cjs and es formats (#2358 by @TrySound)
    • REPLACE action for replaceReducers (#2673 by @timdorr)
    • Update build to use babel-preset-env (#2696 by @hmillison)
    • Optimize dispatch plain object check (#2599 by @timdorr)
    • Update TypeScript typings (#2773 by @aikoven)
    • Added prettier formatting (#2676 by @adityavohra7)
    • Add a sideEffects: false flag for Webpack 4 (#2865 by @timdorr)
    • Fix missed case in "observe" type check (#2919 by @zerobias)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0-rc.1(Apr 10, 2018)

    npm install [email protected]

    There haven't been any big complaints with the previous beta, so it's time to graduate to a release candidate. Please give this a try in your applications and let us know if you see any issues. If we're all clear, I'll get 4.0 released in the next week!


    • Add a sideEffects: false flag for Webpack 4 (#2865 by @timdorr)
    • Fix missed case in "observe" type check (#2919 by @zerobias)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0-beta.2(Feb 15, 2018)

  • v4.0.0-beta.1(Nov 16, 2017)

    It's time to bump the major version on Redux! 🎉

    This is the first beta release of 4.0.0. Despite the version bump, the changes are relatively minor. Most of it was covered in the 4.0 tracking issue: #1342.

    The largest amount of work was done with our Typescript definitions. They have been completely overhauled, so they should work better and take advantage of all the new stuff in TS 2.x.

    The other big change is we are now bundling our CommonJS and ES builds like React has done recently. This means direct, private imports (import createStore from 'redux/lib/createStore') will no longer work. This ensures our modules are maintaining a consistent contract with your apps and that any reorganization we choose to do internally has no effect on your usage of Redux.

    We've also tightened up some behavior quirks and dropped support for IE < 11. The vast majority of apps should require no changes. But we will run through a standard RC process to gradually release this out to the world and ensure no big headaches for everyone during the holiday season.



    • Tons of docs updates. Thanks @markerikson and the Redux community for all your PRs!
    • Make middleware API dispatch pass through all call arguments (#2560 by @Asvarox)
    • Refactor applyMiddleware to reduce confusion around createStore args (#2201 by @jimbolla)
    • Make bindActionCreators transparently pass this (#2641 by @Parakleta)
    • Remove @private flag on AnyAction type definition (#2510 by @alexmngn)
    • Fixed quote types inconsistency in a warning message (#2297 by @Andarist)
    • Move ActionTypes to a private export (b62248b by @timdorr)
    • Throw if getState, subscribe, or unsubscribe called while dispatching (#1569 by @mjw56)
    • Warn when dispatching during Middleware setup (#1485 by @timdorr)
    • Mapped type for combineReducers in index.d.ts (#2182 by @mkusher)
    • Remove legacy jsnext entry (#2284 by @TrySound)
    • Revamp TypeScript typing with more type safety (#2563 by @pelotom)
    • Fix TS definitions test for new Dispatch typing (#2674 by @pelotom)
    • Add DeepPartial type for preloaded state (#2679 by @aikoven)
    • Bundle cjs and es formats (#2358 by @TrySound)
    • REPLACE action for replaceReducers (#2673 by @timdorr)
    • Update build to use babel-preset-env (#2696 by @hmillison)
    • Optimize dispatch plain object check (#2599 by @timdorr)
    Source code(tar.gz)
    Source code(zip)
  • v3.7.2(Jul 13, 2017)

  • v3.7.1(Jun 26, 2017)

    This reverts the console.error on bindActionCreators() coming from #2279.

    While well-intentioned, when star importing all exports from a module (import * as actions from './actions'), transpilation by Babel defaults to adding a default and __esModule property to the import, which are not functions. While it can be disabled, this isn't common to do and leads to a lot of confusion. So, we're reverting the change.

    Thanks for the feedback from everyone and the civility and healthy discourse on the issue!

    Source code(tar.gz)
    Source code(zip)
  • v3.7.0(Jun 17, 2017)

    Another long break!

    Oh, hey! I didn't see you sitting there. You look bored. How about a Redux release to spice things up?

    Not a huge set of changes to report here. The biggest change, and the reason for the minor bump, is the UMD build is now done via Rollup. One big advantage is more readable code in the bundle. Rollup does "scope hoisting", which is a fancy term for putting every module at the top level of the file. Other than a surrounding IIFE, all of the code in Redux all lives together. You can compare the two here:

    Rollup UMD build
    Webpack UMD build

    There is also a cost savings of 30,811 vs 26,880 bytes, and 6,999 vs 5,995 bytes minified. Redux is already a small library, and this helps shave some extra bytes for our UMD users.

    One thing to note is that Webpack has introduced it's own scope hoisting feature in 3.0 beta. So, this isn't intended as an indictment of Webpack. You should continue to use it in your own apps. The adage of "Webpack is for apps, Rollup is for libraries" definitely holds true. It still has a superior developer experience with hot module reloading and webpack-dev-server. But use whatever makes sense for your project, not just whatever we use. 😄

    We're also looking at applying this to the NPM bundle. The main motivation is again more readable code in your bundles. Instead of transpilation oddities from Babel, you will end up with a single clean file, which should be easier to read through and debug. It's currently scheduled for the big, mythical 4.0 release and you can follow along in #2358


    • Build UMD with rollup (#2283 by @TrySound)
    • Warn when bindActionCreators encounters non-function property (#2279 by @artgillespie)
    • Update variables to ES6 (#2169 by @dfrownfelter)
    • Remove filtering inside compose (#2167 by @istarkov)
    • Simplify compose (#2147 by @JoeCortopassi)
    Source code(tar.gz)
    Source code(zip)
  • v3.6.0(Sep 4, 2016)

    Hey, it's been a while!

    How's everyone doing? Enjoying your summer (or winter for the Southern Hemisphere folks)?

    This is a bugfix release for Redux. We're working towards a 4.0 with more substantial changes. Please see #1342 to pitch in!

    Dan also ported all the examples (except the universal one) in #1883 to use the excellent Create React App. This means the changes in #1800 have been lost. If you'd like to help out, we would love PRs on the examples to modernize and clean them up.


    • Updated symbol-observable to 1.0.2 (#1663 and #1877)
    • Added a Redux logo (#1671)
    • Replace es3ify with Babel ES3 transforms (#1688)
    • Run tests on Node 6 (#1673)
    • Optimize one function case in compose (#1701)
    • Check ES3 syntax compatibility (#1720)
    • TypeScript: preloadedState is optional (#1806)
    • Add a warning for undefined properties passed to combineReducers (#1789)
    • Add module entry point for webpack 2 (#1871)
    • TypeScript: Improve typings for compose function (#1868)
    Source code(tar.gz)
    Source code(zip)
  • v3.5.2(Apr 24, 2016)

  • v3.5.1(Apr 20, 2016)

  • v3.5.0(Apr 20, 2016)

  • v3.4.0(Apr 8, 2016)

  • v3.3.1(Feb 6, 2016)

    • ES Modules build now uses the ES Modules build of Lodash. This makes vanilla Redux code include zero CommonJS interop for Rollup users. (#1372)
    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Feb 5, 2016)

    • Fixes jsnext:main to point to a Rollup-friendly ES Modules build in redux/es. It still depends on Lodash so you can’t use without rollup-plugin-commonjs, but importing individual functions like import { createStore } from 'redux' should now work, and you shouldn’t be getting an error when you use npm({ jsnext: true }) anymore due to a broken jsnext:main. (,,
    Source code(tar.gz)
    Source code(zip)
  • v3.2.1(Feb 2, 2016)

  • v3.2.0(Feb 1, 2016)

    • isPlainObject that we use internally is now outsourced to Lodash 4.1 (#1339). Note that this does not mean we depend on Lodash itself. We only use a tiny module from it. We will be able to reuse the same module in React Redux.
    Source code(tar.gz)
    Source code(zip)
  • v3.1.7(Jan 31, 2016)

    • Fix an issue with setInterval unavailable in certain environments (#1335)
    • Performance and memory usage optimizations (5b586080b43ca233f78d56cbadf706c933fefd19, c031c0a8d900e0e95a4915ecc0f96c6fe2d6e92b)
    • Slightly more aggressive minification (6e8d9d430cb2602e3ee1203d4507d671f4e5b259)
    Source code(tar.gz)
    Source code(zip)
  • v3.1.6(Jan 31, 2016)

    • subscribe() now throws a descriptive error when the listener argument is not a function (#1325)
    • bindActionCreators() now ignores anything but functions on the input object (#1329)
    Source code(tar.gz)
    Source code(zip)
  • v3.1.5(Jan 30, 2016)

Redux is a predictable state container for JavaScript apps.
Various useful utilities for Android apps development

Android Commons Various useful utilities for Android apps development. API documentation provided as Javadoc. Usage Add dependency to your build.gradl

Alex Vasilkov 113 May 8, 2021
TSBattery a new way to save your battery avoid cancer apps hacker it.

TSBattery TSBattery a new way to save your battery avoid cancer apps hacker it. TSBattery 是一个旨在使 QQ、TIM 变得更省电的开源 Xposed 模块 Get startted 此模块支持原生 Xposed

Fankesyooni 294 Oct 1, 2022
An Android App which is capable of accessing system apps

Android_Project_Kotlin In this Project I am building an Android App which is capable of accessing system apps. This project is written in Kotlin and I

null 0 Dec 13, 2021
Mi-FreeForm - An APP that is activated through Shizuku/Sui and can display most apps in the form of freeform

Mi-FreeForm 简体中文 Mi-FreeForm is an APP that is activated through Shizuku/Sui and

KindBrive 139 Sep 21, 2022
Web Container: A simple web container library for Android to help fellow developer to open WebView easily

WebContainer Description Web Container is a simple web container library for And

Achmad Ichsan Thaib 7 Mar 8, 2022
Simple Design for Kotlin bridge with Javascript. Also can get javascript console.log.

SDBridgeJava is here. If your h5 partner confused about how to deal with iOS and Android. This Demo maybe help. bilibili video introduction is here. Y

null 10 Sep 25, 2022
Barista makes developing UI test faster, easier and more predictable. Built on top of Espresso

Barista makes developing UI test faster, easier and more predictable. Built on top of Espresso, it provides a simple and discoverable API, removing most of the boilerplate and verbosity of common Espresso tasks. You and your Android team will write tests with no effort.

Adevinta Spain 1.6k Oct 1, 2022
A powerful cross-platform UI toolkit for building native-quality iOS, Android, and Progressive Web Apps with HTML, CSS, and JavaScript.

Ionic Ionic is an open source app development toolkit for building modern, fast, top-quality cross-platform native and Progressive Web Apps from a sin

Ionic 48k Sep 30, 2022
🚀 Native iOS- and Android- Apps with JavaScript

Titanium Welcome to the Titanium open source project. Titanium provides a mature platform for developers to build completely native cross-platform mob

Team Appcelerator 2.6k Oct 1, 2022
Lollipop's Recents container

MaterialRecents Easy to use adapter container. For details check the sample code. Uses CardView, works on all Android versions back to Froyo. I was as

null 495 Feb 15, 2022
Arc Layout is a view group with which you can add a arc-shaped container in your layout.

ArcLayout Arc Layout is a view group with which you can add a arc-shaped container in your layout. Two main variables are the direction and the curvat

Ali Rezaiyan 32 Aug 17, 2022
A small android library for tagging views inside a ScrollView as "sticky" making them stick to the top of the scroll container until a new sticky view comes and takes it's place

StickyScrollViewItems StickyScrollViewItems is a ScrollView subclass that allowed you to mark items inside the ScrollView as sticky. The items marked

Emil Sjölander 1k Sep 23, 2022
ExpandableSelector is an Android library created to show a list of Button/ImageButton widgets inside a animated container which can be collapsed or expanded.

ExpandableSelector ExpandableSelector is an Android library created to show a list of Button/ImageButton widgets inside a animated container which can

Karumi 701 Jul 15, 2022
Loading layout is a container view that manages easy switching between loading, completed and other states of your screen with a single line.

Loading layout is a container view that manages easy switching between loading, completed and other states of your screen with a single line.

ValarTech 16 Jul 5, 2022
Android Emulator Container Scripts

This is a set of minimal scripts to run the emulator in a container for various systems such as Docker, for external consumption. The scripts are compatible with both Python version 2 and 3.

Google 1.4k Oct 2, 2022
Lightweight service for creating standalone mock, written in pure Kotlin with Netty container.

MockService The lightweight service for creating a standalone mock, written in pure Kotlin with Netty container. The service allows getting config fil

null 2 Oct 28, 2021
Aagent-new-service-parent - A Springboot Rest Webservice Project that can be deployed to a Docker container

Webservice in a Docker Container A Springboot Rest Webservice Project that can b

ReeceRiley-aa 0 Jan 4, 2022
A high-performance Android system parasitic container.

Mizuki A high-performance Android system parasitic container. This is a project idea that will be realized in a few years time. License GPL-3.0 Copyri

Fankesyooni 1 Jan 10, 2022
ArchGuard is a architecture governance tool which can analysis architecture in container, component, code level, create architecure fitness functions, and anaysis system dependencies..

ArchGuard backend ArchGuard is a architecture governance tool which can analysis architecture in container, component, code level, database, create ar

ArchGuard 433 Sep 22, 2022
JavaScript evaluation from kotlin common code for android & iOS

Mobile Kotlin javascript This is a Kotlin MultiPlatform library that allows you to run JavaScript code from common Kotlin code Table of Contents Featu

IceRock Development 14 Aug 29, 2022