redux

This patch release adjusts the isPlainObject util to allow objects created via Object.create(null), and fixes a type issue which accidentally made the store state type non-nullable.

What's Changed

• isPlainObject: Support check Object.create(null)

• types/store: Unexpectedly narrowed return type of function Store['getState']

This major release:

• Converts the codebase to TypeScript

• Updates the packaging for better ESM/CJS compatibility and modernizes the build output

• Requires that action.type must be a string

• deprecated

  Continues to mark createStore as deprecated

• deprecated

  Deprecates the AnyAction type in favor of an UnknownAction type that is used everywhere

• removed

  Removes the PreloadedState type in favor of a new generic argument for the Reducer type.

This release has breaking changes.

This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.

For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.

# RTK
npm install @reduxjs/toolkit
yarn add @reduxjs/toolkit

# Standalone
npm install redux
yarn add redux

Changelog

ESM/CJS Package Compatibility

The biggest theme of the Redux v5 and RTK 2.0 releases is trying to get "true" ESM package publishing compatibility in place, while still supporting CJS in the published package.

The primary build artifact is now an ESM file, dist/redux.mjs. Most build tools should pick this up. There's also a CJS artifact, and a second copy of the ESM file named redux.legacy-esm.js to support Webpack 4 (which does not recognize the exports field in package.json). Additionally, all of the build artifacts now live under ./dist/ in the published package.

Modernized Build Output

We now publish modern JS syntax targeting ES2020, including optional chaining, object spread, and other modern syntax. If you need to

Build Tooling

We're now building the package using github.com/egoist/tsup. We also now include sourcemaps for the ESM and CJS artifacts.

Dropping UMD Builds

Redux has always shipped with UMD build artifacts. These are primarily meant for direct import as script tags, such as in a CodePen or a no-bundler build environment.

We've dropped those build artifacts from the published package, on the grounds that the use cases seem pretty rare today.

There's now a redux.browser.mjs file in the package that can be loaded from a CDN like Unpkg.

If you have strong use cases for us continuing to include UMD build artifacts, please let us know!

createStore Marked Deprecated

In Redux 4.2.0, we marked the original createStore method as @deprecated. Strictly speaking, this is not a breaking change, nor is it new in 5.0, but we're documenting it here for completeness.

This deprecation is solely a visual indicator that is meant to encourage users to migrate their apps from legacy Redux patterns to use the modern Redux Toolkit APIs.

The deprecation results in a visual strikethrough when imported and used, like createStore, but with no runtime errors or warnings.

createStore will continue to work indefinitely, and will not ever be removed. But, today we want all Redux users to be using Redux Toolkit for all of their Redux logic.

To fix this, there are three options:

• deprecated

  Follow our strong suggestion to switch over to Redux Toolkit and configureStore

• deprecated

  Do nothing. It's just a visual strikethrough, and it doesn't affect how your code behaves. Ignore it.

• deprecated

  Switch to using the legacy_createStore API that is now exported, which is the exact same function but with no @deprecated tag. The simplest option is to do an aliased import rename, like import { legacy_createStore as createStore } from 'redux'

Action types must be strings

We've always specifically told our users that actions and state must be serializable, and that action.type should be a string. This is both to ensure that actions are serializable, and to help provide a readable action history in the Redux DevTools.

store.dispatch(action) now specifically enforces that action.type must be a string and will throw an error if not, in the same way it throws an error if the action is not a plain object.

In practice, this was already true 99.99% of the time and shouldn't have any effect on users (especially those using Redux Toolkit and createSlice), but there may be some legacy Redux codebases that opted to use Symbols as action types.

TypeScript Changes

We've dropped support for TS 4.6 and earlier, and our support matrix is now TS 4.7+.

Typescript rewrite

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 sat around in the repo for several years, unused and unpublished, due to concerns about possible compatibility issues with the existing ecosystem (as well as general inertia on our part).

Redux core v5 is now built from that TS-converted source code. In theory, this should be almost identical in both runtime behavior and types to the 4.x build, but it's very likely that some of the changes may cause types issues.

Please report any unexpected compatibility issues!!

AnyAction deprecated in favour of UnknownAction

The Redux TS types have always exported an AnyAction type, which is defined to have {type: string} and treat any other field as any. This makes it easy to write uses like console.log(action.whatever), but unfortunately does not provide any meaningful type safety.

We now export an UnknownAction type, which treats all fields other than action.type as unknown. This encourages users to write type guards that check the action object and assert its specific TS type. Inside of those checks, you can access a field with better type safety.

UnknownAction is now the default any place in the Redux source that expects an action object.

AnyAction still exists for compatibility, but has been marked as deprecated.

Note that Redux Toolkit's action creators have a .match() method that acts as a useful type guard:

if (todoAdded.match(someUnknownAction)) {
  // action is now typed as a PayloadAction<Todo>
}

You can also use the new isAction util to check if an unknown value is some kind of action object.

Middleware type changed - Middleware action and next are typed as unknown

Previously, the next parameter is typed as the D type parameter passed, and action is typed as the Action extracted from the dispatch type. Neither of these are a safe assumption:

• next would be typed to have all of the dispatch extensions, including the ones earlier in the chain that would no longer apply.

  • Technically it would be mostly safe to type next as the default Dispatch implemented by the base redux store, however this would cause next(action) to error (as we cannot promise action is actually an Action) - and it wouldn't account for any following middlewares that return anything other than the action they're given when they see a specific action.

• action is not necessarily a known action, it can be literally anything - for example a thunk would be a function with no .type property (so AnyAction would be inaccurate)

We've changed next to be (action: unknown) => unknown (which is accurate, we have no idea what next expects or will return), and changed the action parameter to be unknown (which as above, is accurate).

In order to safely interact with values or access fields inside of the action argument, you must first do a type guard check to narrow the type, such as isAction(action) or someActionCreator.match(action).

This new type is incompatible with the v4 Middleware type, so if a package's middleware is saying it's incompatible, check which version of Redux it's getting its types from!

PreloadedState type removed in favour of Reducer generic

We've made tweaks to the TS types to improve type safety and behavior.

First, the Reducer type now has a PreloadedState possible generic:

type Reducer<S, A extends Action, PreloadedState = S> = (
  state: S | PreloadedState | undefined,
  action: A
) => S

Per the explanation in #4491:

Why the need for this change? When the store is first created by createStore/configureStore, the initial state is set to whatever is passed as the preloadedState argument (or undefined if nothing is passed). That means that the first time that the reducer is called, it is called with the preloadedState. After the first call, the reducer is always passed the current state (which is S).

For most normal reducers, S | undefined accurately describes what can be passed in for the preloadedState. However the combineReducers function allows for a preloaded state of Partial<S> | undefined.

The solution is to have a separate generic that represents what the reducer accepts for its preloaded state. That way createStore can then use that generic for its preloadedState argument.

Previously, this was handled by a $CombinedState type, but that complicated things and led to some user-reported issues. This removes the need for $CombinedState altogether.

This change does include some breaking changes, but overall should not have a huge impact on users upgrading in user-land:

• The Reducer, ReducersMapObject, and createStore/configureStore types/function take an additional PreloadedState generic which defaults to S.

• The overloads for combineReducers are removed in favor of a single function definition that takes the ReducersMapObject as its generic parameter. Removing the overloads was necessary with these changes, since sometimes it was choosing the wrong overload.

• Enhancers that explicitly list the generics for the reducer will need to add the third generic.

Other Changes

Internal Listener Implementation

The Redux store has always used an array to track listener callbacks, and used listeners.findIndex to remove listeners on unsubscribe. As we found in React-Redux, that can have perf issues when many listeners are unsubscribing at once.

In React-Redux, we fixed that with a more sophisticated linked list approach. Here, we've updated the listeners to be stored in a Map instead, which has better delete performance than an array.

In practice this shouldn't have any real effect, because React-Redux sets up a subscription in <Provider>, and all nested components subscribe to that. But, nice to fix it here as well.

isAction Predicate

We recently added an isAction predicate to RTK, then realized it's better suited for the Redux core. This can be used anywhere you have a value that could be a Redux action object, and you need to check if it is actually an action. This is specifically useful for use with the updated Redux middleware TS types, where the default value is now unknown and you need to use a type guard to tell TS that the current value is actually an action:

We've also exported the isPlainObject util that's been in the Redux codebase for years as well.

What's Changed

Entirely too many PRs to list here, as it's been a few years since 4.2 was released :) See the diff below.

This bugfix release removes the isMinified internal check to fix a compat issue with Expo. That check has added in early 2016, soon after Redux 3.0 was released, at a time when it was still less common to use bundlers with proper production build settings. Today that check is irrelevant, so we've removed it.

What's Changed

• Remove minified check

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.

Goal

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

redux.js.org/introduction/why-rtk-is-redux-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 NOT GOING TO ACTUALLY REMOVE THE createStore API, AND ALL YOUR EXISTING CODE WILL STILL CONTINUE TO WORK AS-IS!

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 #4325 .

Rationale

• 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.

Results

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:

image

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:

image

What's Changed

• deprecated

  Mark createStore as deprecated, and add legacy_createStore alias

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

Just a small fix for Safari users in development mode.

Changes

• Move miniKindOf out of if scope to fix ES5 compatibility issue

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.

Changelog

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: redux.js.org/errors , which shows the "can't subscribe while reducers are executing" error.

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

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:

Typing Tweaks

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

Changes

• 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)

• Mangle error codes to error indexes (#3920 - @andrewmcgivery)

• Declare "EmptyObject" interface to wrap $CombinedState (#4031 - @JacobLey)

• Only apply mapped types to un-branded types (#3805 - @invliD)

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.

Changes

• Clear current listeners on store unsubscribe

• Fix for combineReducers when replaceReducers removes a reducer

• TypeScript: Add strict type inference overload for combineReducers

• TypeScript: Preloaded state is now selectively partial (instead of deeply partial)

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.

Changes

• Reverts the change to combineReducers' type parameters

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

Changes

• Iterate in combineReducers using for in

• Fix DeepPartial type

• Add types for Observable interface

• Make reducer optional in JSDocs

• Infer action types from combineReducers

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!

Changes

• Update mixed NODE_ENV message for Webpack 4 (4a215fb

• Add unpkg field to package.json

• Use same return type for both StoreCreator signatures

• Mark StoreCreator's preloadedState argument as optional

• Add ES browser build

• Throw an error if createStore is passed several enhancers

• Upgrade to Babel 7 (b9ee1cf

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.

Enjoy!

Changes

• Tons of docs updates. Thanks @markerikson and the Redux community for all your PRs!

• Make middleware API dispatch pass through all call arguments

• Refactor applyMiddleware to reduce confusion around createStore args

• Make bindActionCreators transparently pass this

• removed

  Remove @private flag on AnyAction type definition

• Fixed quote types inconsistency in a warning message

• Move ActionTypes to a private export (b62248b

• Throw if getState, subscribe, or unsubscribe called while dispatching (including inside a reducer)

• Warn when dispatching during Middleware setup

• Mapped type for combineReducers in index.d.ts

• Remove legacy jsnext entry

• Revamp TypeScript typing with more type safety

• Fix TS definitions test for new Dispatch typing

• Add DeepPartial type for preloaded state

• Bundle cjs and es formats

• REPLACE action for replaceReducers

• Update build to use babel-preset-env

• Optimize dispatch plain object check

• Update TypeScript typings

• Added prettier formatting

• Add a sideEffects: false flag for Webpack 4

• Fix missed case in "observe" type check

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!

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
vs
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

Changes

• Build UMD with rollup

• Warn when bindActionCreators encounters non-function property

• Remove filtering inside compose

• Simplify compose

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.

Changes

• Updated symbol-observable to 1.0.2 (#1663 and #1877)

• Added a Redux logo

• Replace es3ify with Babel ES3 transforms

• Run tests on Node 6

• Optimize one function case in compose

• Check ES3 syntax compatibility

• TypeScript: preloadedState is optional

• Add a warning for undefined properties passed to combineReducers

• Add module entry point for webpack 2

• TypeScript: Improve typings for compose function

• For Browserify users, Redux should now be properly envified without extra configuration

• createStore() now receives an enhancer such as applyMiddleware() as the last optional argument

Wait, what?

You don’t have to change anything. However if you use store enhancers such as applyMiddleware() or Redux DevTools you might like that you can now express the same code in a more JavaScript-friendly way:

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

For multiple store enhancers you can still use compose() but in a similar more straightforward fashion:

- const finalCreateStore = compose(
-   applyMiddleware(thunk, logger),
-   DevTools.instrument()
- )(createStore)
- const store = finalCreateStore(reducer, initialState)
+ const store = createStore(
+   reducer,
+   initialState,
+   compose(
+     applyMiddleware(thunk, logger),
+     DevTools.instrument()
+   )
+ )

The second initialState argument stays optional so you can skip it when specifying the enhancer.

The old way of doing things still works, too.
We’re just adding a nicer way to apply enhancers, that’s all.

Happy reducing!

• compose() now aligns more closely with Underscore/Lodash behavior by allowing multiple arguments to be passed to the last function. This is not changing the existing behavior for the single argument call which has been the only possible use case before. (#632, #1050)

• The dev-only state shape sanity check warning in combineReducers() now runs faster. (#1118)

• breaking

  Now we warn if you’re running an unenvified build of Redux in production as it is slower. We determine this by checking whether you have uglified Redux code, and if you did, we check that process.env.NODE_ENV polyfill (which we require anyway) is set to 'production'. This does not affect the UMD builds. This is also a warning and not a hard error so it isn't a breaking change. (#1029, #1075)

• We now officially support importing individual modules from redux/lib/*.js. This is only true for top-level directory—we do not supporting reaching into redux/lib/utils, for example. To support this, we moved all top-level exports to be in redux/lib, for example, redux/lib/applyMiddleware.js. (#1223, #1224)

One of the problems v3.0.1 was intended to solve was not completely fixed in 3.0.1.
This release amends that.

• An error thrown inside reducer during the combineReducer() sanity check will be delayed until the first dispatch. This lets Redux DevTools correctly handle it and recover from the error. (#717, #761, #807, gaearon/redux-devtools#106, gaearon/redux-devtools#120)

To enjoy this, you’ll need at least redux-devtools@2.1.4.

!(i.imgur.com/skmH0uC.gif)

This release brings a few changes that, while aimed at making the developer experience better, should have no noticeable impact on your apps.

• In development, combineReducers() now checks the state shape on every invocation instead of just once. This makes it easy to discover issues like #715 where you post-process the state from combineReducers() and then wonder why something you added to it has disappeared after the next action. This change has no effect in production, and you’re unlikely to hit it in development either, as post-processing state from combineReducers() isn't a very common pattern. (#715, #720)

• The reducer probing performed by combineReducers() as a sanity check has been moved from the combineReducers() call to the first reducer invocation. Technically the check is still performed during the combineReducers() call, but the error is only thrown after during the initial dispatch. (Usually that would correspond to the createStore()call.) This reason for this is that otherwise an error thrown inside a reducer used to blow up combineReducers() and thus the whole module definition, and hot reloading used to fail in this case instead of showing the error in Redux DevTools. With this change and a corresponding fix in Redux DevTools, an error thrown inside a reducer that was later wrapped in combineReducers() will be displayed correctly, and once you fix the error, it will hot reload. (#717, #761, #106, #120)

• The reducer probing performed by combineReducers() as a sanity check now uses @@redux/PROBE_UNKNOWN_ACTION_ prefix in the action type. Previously, action type was a random string. The reason for this change is to make it easier for type-checking libraries like redux-tcomb ignore such actions. This change does not affect application developers: just like before, you should never attempt to handle @@redux/* actions directly in your code. (#792, #796)

Happy reducing!

Breaking Changes

getReducer() is removed from Store public API (#668)

It was only needed because React Redux used it to magically allow reducer hot reloading. This magic used to cause problems (#301, #340), so we made the usage of replaceReducer() for hot reloading explicit (#667).

It is likely that you never used getReducer(). However, if you used hot reloading of reducers, you'll need to add module.hot API calls to the place where you create the store. (Of course, assuming that you use Webpack.)

Before

import { createStore } from 'redux';
import rootReducer from '../reducers/index';

export default function configureStore(initialState) {
  return createStore(rootReducer, initialState);
}

After

import { createStore } from 'redux';
import rootReducer from '../reducers/index';

export default function configureStore(initialState) {
  const store = createStore(rootReducer, initialState);

  if (module.hot) {
    // Enable Webpack hot module replacement for reducers
    module.hot.accept('../reducers', () => {
      const nextRootReducer = require('../reducers/index');
      store.replaceReducer(nextRootReducer);
    });
  }

  return store;
}

This is more code, but what's happening is now explicit, and this also lets you do this right in index.js instead of creating a separate <Root> component. See #667 for a migration example.

compose() now acts like a proper compose() (#669)

This fixes the embarrassing mishap that compose() API was.
As suggested by @jlongster, now it is a proper compose() you'd find in Lodash or Underscore:

it('composes from right to left', () => {
  const double = x => x * 2;
  const square = x => x * x;
  expect(compose(square)(5)).toBe(25);
  expect(compose(square, double)(5)).toBe(100);
  expect(compose(double, square, double)(5)).toBe(200);
});

In terms of usage, you just need to remove createStore from the chain, and add it as a function application instead.

Before

const finalCreateStore = compose(
  applyMiddleware(stuff),
  devTools(),
  somethingElse(),
  createStore
);

After

const finalCreateStore = compose(
  applyMiddleware(stuff),
  devTools(),
  somethingElse()
)(createStore);

process.env.NODE_ENV is required for CommonJS build (#671)

In 1.0.1, we temporarily removed the dependency on it to support React Native, but now that RN 0.10 is out with process.env.NODE_ENV polyfill, we again demand it to be defined. If you're not ready to use RN 0.10, or are in a different environment, either use a browser build, or shim it yourself.

!(i.imgur.com/73u79JT.gif)

Breaking Changes

If you're migrating from 0.12, apply 0.12 -> 1.0.0-alpha migration first, and then 1.0.0-alpha -> 1.0.0-rc. 1.0 only has a single breaking change since 1.0.0-rc:

• breaking

  If dispatch is attempted while reducer is executing, an error is thrown. Note that you can dispatch from lifecycle hooks just fine. It's only reducers that are not allowed to dispatch. (#368)

New Home

We moved under rackt Github org. This won't affect you, but the new official URL is github.com/rackt/redux. We did this because we share values, and we want to collaborate on creating better tools, libraries, documentation, and examples. Redux stays independent of React, but we will work closely with React Router community to figure out a better integration.

Docs!

We have real docs now. There are a few missing pieces, but it's a terrific effort, so thanks to everybody who contributed in the past month to get this shipped. Thanks to Gitbook for providing great tooling, too.

Examples!

There's been no shortage of great examples in Awesome Redux, but we're shipping two new built-in examples in 1.0. One of them is a very simple async application. Creating it is covered in async tutorial. Another example we ship is a “real-world” example. It's a port of somewhat well-known flux-react-router-example to Redux, and shows advanced techniques such as caching, data normalization, custom API middleware, and pagination. Hopefully this example will help answer some commonly asked questions.

Other Improvements

• Unsubscribing during a dispatch is now fixed: #462

• bindActionCreators now can also accept a function as the first argument: #352

• Dispatching from iframe now works: #304

• Symbols can be used as action types: #295 (Note: we don't recommend you to do this, because they're not serializable, so you can't record/replay user sessions.)

Patrons

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

• Webflow

• Chess iX

• Herman J. Radtke III

• Ken Wheeler

• Chung Yen Li

• Sunil Pai

• Charlie Cheever

• Eugene G

• Matt Apperson

• Jed Watson

• Sasha Aickin

No breaking changes this time.

• Classes returned by decorators now expose a static DecoratedComponent property for easier testing

• Dependencies on lodash and babel-runtime are dropped

• Now compatible with Babel loose mode

• composeStore now ignores non-function values (useful in Babel loose mode)

• A UMD build is added

• The initial action dispatched to the stores now has a built-in @@INIT type (might be useful to devtools)

Missing from the 0.10 release notes: React Native is now supported!
(And that's actually a breaking change.)

Now, to import React-specific parts (containers or decorators), you need to either import from redux/react or redux/react-native:

// Import utilities and functions from redux
import { createRedux, bindActionCreators } from 'redux';

// Import components and decorators from redux/react
import { provide, Connector } from 'redux/react';

// React Native: Import components and decorators from redux/react-native
import { provide, Connector } from 'redux/react-native';

0.10 release also had a problem with ES6 code inside redux/react and redux/react-native entry points, which is now fixed. Please upgrade if you had problems with 0.10.

Changes introduced in 0.10.1:

• Connector now throws if select returns something other than a plain object (#85)

• The custom dispatcher API is tweaked so setState now returns the state that was actually set. This makes custom dispatchers more composable. (#77)

Happy reducing!

Middleware

Redux 1.0 is within striking distance! Can you believe how quickly Redux has matured? @gaearon made the first commit only 14 days ago.

The 0.10 release is a follow-up to 0.9, with a focus on what we're calling (at least for now) middleware.

You can read all about middleware here. We plan to release some official middleware soon, but of course we'd also love to see middleware created by the community.

Breaking changes

Just a small one: Redux includes a feature that enables you to return a function from an action creator to perform asynchronous dispatches. The function receives a callback and getState() as parameters. This has behavior has been re-implemented as middleware and moved into a separate module called thunkMiddleware(). It is included automatically when using the createRedux(stores) shortcut, but not when using createDispatcher().

Tests

We have tests! Still need to improve coverage in a few areas, but we're currently at ~93%. Not bad! Big thanks to @emmenko for setting these up.

Internal Refactoring & Custom Dispatchers

This release brings breaking changes necessary to start experimenting with middleware and extensibility (#6, #55). It does not bring any support for middleware per se, but it untangles “Dispatcher” (a function that tells how actions turn into state updates) from “Redux” (an instance holding the current state and managing subscriptions). It is now possible to specify your own Dispatcher if you want to experiment with ideas like middleware, time travel, action creators returning Promises or Observables, etc.

• createDispatcher now returns a function you need to give to createRedux

• createRedux is the primary API you'll use for initialization

• Instead of dispatcher prop, a dispatch function prop is injected by the <Connector> and @connect

• Instead of dispatcher prop, <Provider> and @provide accept a redux prop

• Instead of dispatcher.getAtom(), use redux.getState()

• Instead of dispatcher.setAtom(), you may pass a second initialState argument to createRedux

• Instead of dispatcher.perfrorm() or dispatcher.dispatch(), use redux.dispatch()

• bindActions is renamed to bindActionCreators and accepts dispatch as the second parameter

• You may skip composeStores and createDispatcher completely and just use createRedux(stores) as a shortcut

How It Looks Like Now

Initialization

Short Way

This is a shortcut for the most common use case.

import { createRedux, Provider } from 'redux';
import * as stores from '../stores/index';

const redux = createRedux(stores);

export default class App {
  render() {
    return (
      <Provider redux={redux}>
        {() =>
          <CounterApp />
        }
      </Provider>
    );
  }
}

Long Way

This way of writing lets you use compose Stores differently, or even pass a custom Dispatcher function. Its signature is (initialState, setState) => (action) => ().

import { createRedux, createDispatcher, composeStores } from 'redux';
import * as stores from '../stores/index';

// Compose all your Stores into a single Store function with `composeStores`:
const store = composeStores(stores);

// Create a default Dispatcher function for your composite Store:
const dispatcher = createDispatcher(store); // You may use your custom function here

// Create a Redux instance using the dispatcher function:
const redux = createRedux(dispatcher);

export default class App {
  render() {
    return (
      <Provider redux={redux}>
        {() =>
          <CounterApp />
        }
      </Provider>
    );
  }
}

Hydration and dehydration

// server
const redux = createRedux(stores);
redux.dispatch(MyActionCreators.doSomething()); // fire action creators to fill the state
const state = redux.getState(); // somehow pass this state to the client

// client
const initialState = window.STATE_FROM_SERVER;
const redux = createRedux(stores, initialState);

Binding actions

import React from 'react';
import { connect, bindActionCreators } from 'redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/CounterActions';

@connect(state => ({
  counter: state.counter
}))
export default class CounterApp {
  render() {
    const { counter, dispatch } = this.props;
    return (
      <Counter counter={counter}
               {...bindActionCreators(CounterActions, dispatch)} />
    );
  }
}

• hydrate() and dehydrate() are gone, welcome getAtom() and setAtom() instead

• initialize() and dispose() are added for advanced use cases

• Changing select function now updates the Connector state

• The bug with action creators accepting dispatch instead of perform is fixed