From 78d2f5e6880936063184427fdb235d34d4be8ba1 Mon Sep 17 00:00:00 2001
From: Mark Erikson <mark@isquaredsoftware.com>
Date: Fri, 24 Nov 2023 19:37:40 -0500
Subject: [PATCH] Nuke most "ES2015" references

---
 docs/api/combineReducers.md                   |   2 +-
 docs/faq/Actions.md                           |   2 +-
 docs/faq/General.md                           |   8 +-
 docs/faq/ImmutableData.md                     |   4 +-
 docs/introduction/GettingStarted.md           | 116 +++++++++---------
 docs/style-guide/style-guide.md               |   2 +-
 .../part-6-performance-normalization.md       |   2 +-
 .../part-3-state-actions-reducers.md          |   2 +-
 .../fundamentals/part-8-modern-redux.md       |   2 +-
 .../history-and-design/PriorArt.md            |   2 +-
 docs/usage/ServerRendering.md                 |   2 +-
 docs/usage/side-effects-approaches.mdx        |   2 +-
 .../BasicReducerStructure.md                  |   2 +-
 .../structuring-reducers/InitializingState.md |   8 +-
 .../UsingCombineReducers.md                   |   8 +-
 src/bindActionCreators.ts                     |   2 +-
 src/combineReducers.ts                        |   2 +-
 17 files changed, 88 insertions(+), 80 deletions(-)

diff --git a/docs/api/combineReducers.md b/docs/api/combineReducers.md
index 929193b5f08..c2a432cdc3f 100644
--- a/docs/api/combineReducers.md
+++ b/docs/api/combineReducers.md
@@ -80,7 +80,7 @@ Any reducer passed to `combineReducers` must satisfy these rules:
 
 - It must never return `undefined`. It is too easy to do this by mistake via an early `return` statement, so `combineReducers` throws if you do that instead of letting the error manifest itself somewhere else.
 
-- If the `state` given to it is `undefined`, it must return the initial state for this specific reducer. According to the previous rule, the initial state must not be `undefined` either. It is handy to specify it with ES2015 optional arguments syntax, but you can also explicitly check the first argument for being `undefined`.
+- If the `state` given to it is `undefined`, it must return the initial state for this specific reducer. According to the previous rule, the initial state must not be `undefined` either. It is handy to specify it with optional arguments syntax, but you can also explicitly check the first argument for being `undefined`.
 
 While `combineReducers` attempts to check that your reducers conform to some of these rules, you should remember them, and do your best to follow them. `combineReducers` will check your reducers by passing `undefined` to them; this is done even if you specify initial state to `Redux.createStore(combineReducers(...), initialState)`. Therefore, you **must** ensure your reducers work properly when receiving `undefined` as state, even if you never intend for them to actually receive `undefined` in your own code.
 
diff --git a/docs/faq/Actions.md b/docs/faq/Actions.md
index 7768f70b889..b47691c628e 100644
--- a/docs/faq/Actions.md
+++ b/docs/faq/Actions.md
@@ -114,7 +114,7 @@ There are [many async/side effect middlewares available](https://github.com/mark
 As a general rule of thumb:
 
 - Thunks are best for complex synchronous logic (especially code that needs access to the entire Redux store state), and simple async logic (like basic AJAX calls). With the use of `async/await`, it can be reasonable to use thunks for some more complex promise-based logic as well.
-- Sagas are best for complex async logic and decoupled "background thread"-type behavior, especially if you need to listen to dispatched actions (which is something that can't be done with thunks). They require familiarity with ES2015 generator functions and `redux-saga`'s "effects" operators.
+- Sagas are best for complex async logic and decoupled "background thread"-type behavior, especially if you need to listen to dispatched actions (which is something that can't be done with thunks). They require familiarity with generator functions and `redux-saga`'s "effects" operators.
 - Observables solve the same problems as sagas, but rely on RxJS to implement async behavior. They require familiarity with the RxJS API.
 
 We recommend that most Redux users should start with thunks, and then add an additional side effect library like sagas or observables later if their app really requires handling for more complex async logic.
diff --git a/docs/faq/General.md b/docs/faq/General.md
index 744247b168a..5477008ac04 100644
--- a/docs/faq/General.md
+++ b/docs/faq/General.md
@@ -104,7 +104,13 @@ Redux can be used as a data store for any UI layer. The most common usage is wit
 
 ## Do I need to have a particular build tool to use Redux?
 
-Redux is originally written in ES2015 and transpiled for production into ES5 with Webpack and Babel. You should be able to use it regardless of your JavaScript build process. Redux also offers a UMD build that can be used directly without any build process at all. The [counter-vanilla](https://github.com/reduxjs/redux/tree/master/examples/counter-vanilla) example demonstrates basic ES5 usage with Redux included as a `<script>` tag. As the relevant pull request says:
+Redux is written using modern JS syntax (ES2020), but the code is fairly simple.
+
+If you need to target older browsers, please transpile it yourself.
+
+. You should be able to use it regardless of your JavaScript build process. Redux also offers a UMD build that can be used directly without any build process at all.
+
+The [counter-vanilla](https://github.com/reduxjs/redux/tree/master/examples/counter-vanilla) example demonstrates basic ES5 usage with Redux included as a `<script>` tag. As the relevant pull request says:
 
 > The new Counter Vanilla example is aimed to dispel the myth that Redux requires Webpack, React, hot reloading, sagas, action creators, constants, Babel, npm, CSS modules, decorators, fluent Latin, an Egghead subscription, a PhD, or an Exceeds Expectations O.W.L. level.
 >
diff --git a/docs/faq/ImmutableData.md b/docs/faq/ImmutableData.md
index ff28c4181e0..32595542b47 100644
--- a/docs/faq/ImmutableData.md
+++ b/docs/faq/ImmutableData.md
@@ -452,7 +452,7 @@ JavaScript was never designed to provide guaranteed immutable operations. Accord
 
 With JavaScript, you can accidentally mutate an object (such as the Redux state tree) quite easily without realizing it. For example, updating deeply nested properties, creating a new _reference_ to an object instead of a new object, or performing a shallow copy rather than a deep copy, can all lead to inadvertent object mutations, and can trip up even the most experienced JavaScript coder.
 
-To avoid these issues, ensure you follow the recommended [immutable update patterns for ES2015](../usage/structuring-reducers/ImmutableUpdatePatterns.md).
+To avoid these issues, ensure you follow the recommended [immutable update patterns](../usage/structuring-reducers/ImmutableUpdatePatterns.md).
 
 ### Verbose Code
 
@@ -470,7 +470,7 @@ In contrast, immutable libraries such as Immer can employ structural sharing, wh
 
 **Documentation**
 
-- [Immutable Update Patterns for ES2015](../usage/structuring-reducers/ImmutableUpdatePatterns.md)
+- [Immutable Update Patterns](../usage/structuring-reducers/ImmutableUpdatePatterns.md)
 
 **Articles**
 
diff --git a/docs/introduction/GettingStarted.md b/docs/introduction/GettingStarted.md
index a1dc3dd9dda..189971549e0 100644
--- a/docs/introduction/GettingStarted.md
+++ b/docs/introduction/GettingStarted.md
@@ -13,11 +13,7 @@ It helps you write applications that behave consistently, run in different envir
 
 You can use Redux together with [React](https://reactjs.org), or with any other view library. It is tiny (2kB, including dependencies), but has a large ecosystem of addons available.
 
-## Installation
-
-### Redux Toolkit
-
-[**Redux Toolkit**](https://redux-toolkit.js.org) is our official standard 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.
+[**Redux Toolkit**](https://redux-toolkit.js.org) 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.
 
 RTK includes utilities that help simplify many common use cases, including [store setup](https://redux-toolkit.js.org/api/configureStore),
 [creating reducers and writing immutable update logic](https://redux-toolkit.js.org/api/createreducer),
@@ -27,6 +23,10 @@ Whether you're a brand new Redux user setting up your first project, or an exper
 simplify an existing application, **[Redux Toolkit](https://redux-toolkit.js.org/)** can help you
 make your Redux code better.
 
+## Installation
+
+### Redux Toolkit
+
 Redux Toolkit is available as a package on NPM for use with a module bundler or in a Node application:
 
 ```bash
@@ -79,6 +79,60 @@ The whole global state of your app is stored in an object tree inside a single _
 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.
 
+Redux Toolkit simplifies the process of writing Redux logic and setting up the store. With Redux Toolkit, the basic app logic looks like:
+
+```js
+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
+store.dispatch(incremented())
+// {value: 1}
+store.dispatch(incremented())
+// {value: 2}
+store.dispatch(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 allows us to write shorter logic that's easier to read, while still following the same Redux behavior and data flow.
+
+### Legacy Example
+
+For comparison, the original Redux legacy syntax (with no abstractions) looks like this:
+
 ```js
 import { createStore } from 'redux'
 
@@ -125,58 +179,6 @@ 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:
-
-```js
-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
-store.dispatch(incremented())
-// {value: 1}
-store.dispatch(incremented())
-// {value: 2}
-store.dispatch(decremented())
-// {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.
-
 ## Learn Redux
 
 We have a variety of resources available to help you learn Redux.
diff --git a/docs/style-guide/style-guide.md b/docs/style-guide/style-guide.md
index 848cb9d6512..376b8f3eb5a 100644
--- a/docs/style-guide/style-guide.md
+++ b/docs/style-guide/style-guide.md
@@ -237,7 +237,7 @@ As mentioned in [Reducers Should Own the State Shape](#reducers-should-own-the-s
 The key names in the object passed to `combineReducers` will define the names of the keys in the resulting state object. Be sure to name these keys after the data that is kept inside, and avoid use of the word "reducer" in the key names. Your object should look like `{users: {}, posts: {}}`, rather than `{usersReducer: {}, postsReducer: {}}`.
 
 <DetailedExplanation>
-ES2015 object literal shorthand makes it easy to define a key name and a value in an object at the same time:
+Object literal shorthand makes it easy to define a key name and a value in an object at the same time:
 
 ```js
 const data = 42
diff --git a/docs/tutorials/essentials/part-6-performance-normalization.md b/docs/tutorials/essentials/part-6-performance-normalization.md
index 9c0860d9960..6d521d0327d 100644
--- a/docs/tutorials/essentials/part-6-performance-normalization.md
+++ b/docs/tutorials/essentials/part-6-performance-normalization.md
@@ -822,7 +822,7 @@ When we receive the `fetchPosts.fulfilled` action, we can use the `postsAdapter.
 
 When we receive the `addNewPost.fulfilled` action, we know we need to add that one new post object to our state. We can use the adapter functions as reducers directly, so we'll pass `postsAdapter.addOne` as the reducer function to handle that action.
 
-Finally, we can replace the old hand-written `selectAllPosts` and `selectPostById` selector functions with the ones generated by `postsAdapter.getSelectors`. Since the selectors are called with the root Redux state object, they need to know where to find our posts data in the Redux state, so we pass in a small selector that returns `state.posts`. The generated selector functions are always called `selectAll` and `selectById`, so we can use ES2015 destructuring syntax to rename them as we export them and match the old selector names. We'll also export `selectPostIds` the same way, since we want to read the list of sorted post IDs in our `<PostsList>` component.
+Finally, we can replace the old hand-written `selectAllPosts` and `selectPostById` selector functions with the ones generated by `postsAdapter.getSelectors`. Since the selectors are called with the root Redux state object, they need to know where to find our posts data in the Redux state, so we pass in a small selector that returns `state.posts`. The generated selector functions are always called `selectAll` and `selectById`, so we can use destructuring syntax to rename them as we export them and match the old selector names. We'll also export `selectPostIds` the same way, since we want to read the list of sorted post IDs in our `<PostsList>` component.
 
 ### Optimizing the Posts List
 
diff --git a/docs/tutorials/fundamentals/part-3-state-actions-reducers.md b/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
index 0a09be23213..9059c691f8e 100644
--- a/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
+++ b/docs/tutorials/fundamentals/part-3-state-actions-reducers.md
@@ -272,7 +272,7 @@ export default function appReducer(state = initialState, action) {
 }
 ```
 
-A reducer may be called with `undefined` as the state value when the application is being initialized. If that happens, we need to provide an initial state value so the rest of the reducer code has something to work with. **Reducers normally use ES2015 default argument syntax to provide initial state: `(state = initialState, action)`**.
+A reducer may be called with `undefined` as the state value when the application is being initialized. If that happens, we need to provide an initial state value so the rest of the reducer code has something to work with. **Reducers normally use default argument syntax to provide initial state: `(state = initialState, action)`**.
 
 Next, let's add the logic to handle the `'todos/todoAdded'` action.
 
diff --git a/docs/tutorials/fundamentals/part-8-modern-redux.md b/docs/tutorials/fundamentals/part-8-modern-redux.md
index 32ad8dfc191..2c3be0230b6 100644
--- a/docs/tutorials/fundamentals/part-8-modern-redux.md
+++ b/docs/tutorials/fundamentals/part-8-modern-redux.md
@@ -801,7 +801,7 @@ export const selectFilteredTodoIds = createSelector(
 )
 ```
 
-We call `todosAdapter.getSelectors`, and pass in a `state => state.todos` selector that returns this slice of state. From there, the adapter generates a `selectAll` selector that takes the _entire_ Redux state tree, as usual, and loops over `state.todos.entities` and `state.todos.ids` to give us the complete array of todo objects. Since `selectAll` doesn't tell us _what_ we're selecting, we can use ES2015 destructuring syntax to rename the function to `selectTodos`. Similarly, we can rename `selectById` to `selectTodoById`.
+We call `todosAdapter.getSelectors`, and pass in a `state => state.todos` selector that returns this slice of state. From there, the adapter generates a `selectAll` selector that takes the _entire_ Redux state tree, as usual, and loops over `state.todos.entities` and `state.todos.ids` to give us the complete array of todo objects. Since `selectAll` doesn't tell us _what_ we're selecting, we can use destructuring syntax to rename the function to `selectTodos`. Similarly, we can rename `selectById` to `selectTodoById`.
 
 Notice that our other selectors still use `selectTodos` as an input. That's because it's still returning an array of todo objects this whole time, no matter whether we were keeping the array as the entire `state.todos`, keeping it as a nested array, or storing it as a normalized object and converting to an array. Even as we've made all these changes to how we stored our data, the use of selectors allowed us to keep the rest of our code the same, and the use of memoized selectors has helped the UI perform better by avoiding unnecessary rerenders.
 
diff --git a/docs/understanding/history-and-design/PriorArt.md b/docs/understanding/history-and-design/PriorArt.md
index 7fb68f40d11..8d62baf791c 100644
--- a/docs/understanding/history-and-design/PriorArt.md
+++ b/docs/understanding/history-and-design/PriorArt.md
@@ -113,4 +113,4 @@ Meet some of the outstanding companies that made it possible:
 - [Webflow](https://github.com/webflow)
 - [Ximedes](https://www.ximedes.com/)
 
-[See the full list of Redux patrons](<[PATRONS.md](https://github.com/reduxjs/redux/blob/master/PATRONS.md)>), as well as the always-growing list of [people and companies that use Redux](https://github.com/reduxjs/redux/issues/310).
+[See the full list of original Redux patrons](https://github.com/reduxjs/redux/blob/master/PATRONS.md), as well as the always-growing list of [people and companies that use Redux](https://github.com/reduxjs/redux/issues/310).
diff --git a/docs/usage/ServerRendering.md b/docs/usage/ServerRendering.md
index e4b17e61cf4..d414e04d00a 100644
--- a/docs/usage/ServerRendering.md
+++ b/docs/usage/ServerRendering.md
@@ -39,7 +39,7 @@ npm install express react-redux
 
 The following is the outline for what our server side is going to look like. We are going to set up an [Express middleware](https://expressjs.com/guide/using-middleware.html) using [app.use](http://expressjs.com/api.html#app.use) to handle all requests that come in to our server. If you're unfamiliar with Express or middleware, just know that our handleRender function will be called every time the server receives a request.
 
-Additionally, as we are using ES2015 and JSX syntax, we will need to compile with [Babel](https://babeljs.io/) (see [this example of a Node Server with Babel](https://github.com/babel/example-node-server)) and the [React preset](https://babeljs.io/docs/plugins/preset-react/).
+Additionally, as we are using modern JS and JSX syntax, we will need to compile with [Babel](https://babeljs.io/) (see [this example of a Node Server with Babel](https://github.com/babel/example-node-server)) and the [React preset](https://babeljs.io/docs/plugins/preset-react/).
 
 ##### `server.js`
 
diff --git a/docs/usage/side-effects-approaches.mdx b/docs/usage/side-effects-approaches.mdx
index afa75e30f7e..698290e9ca9 100644
--- a/docs/usage/side-effects-approaches.mdx
+++ b/docs/usage/side-effects-approaches.mdx
@@ -85,7 +85,7 @@ We've intentionally designed the RTK listener middleware to be straightforward t
 
 We specifically recommend _against_ sagas or observables for most reactive logic for multiple reasons:
 
-- Sagas: require understanding ES2015 generator function syntax as well as the saga effects behaviors; add multiple levels of indirection due to needing extra actions dispatched; have poor TypeScript support; and the power and complexity is simply not needed for most Redux use cases.
+- Sagas: require understanding generator function syntax as well as the saga effects behaviors; add multiple levels of indirection due to needing extra actions dispatched; have poor TypeScript support; and the power and complexity is simply not needed for most Redux use cases.
 - Observables: require understanding the RxJS API and mental model; can be difficult to debug; can add significant bundle size
 
 ## Common Side Effects Approaches
diff --git a/docs/usage/structuring-reducers/BasicReducerStructure.md b/docs/usage/structuring-reducers/BasicReducerStructure.md
index 17b81a5fcfd..a174f8f44c7 100644
--- a/docs/usage/structuring-reducers/BasicReducerStructure.md
+++ b/docs/usage/structuring-reducers/BasicReducerStructure.md
@@ -36,7 +36,7 @@ function counter(state, action) {
 
 Notice that this simple function fulfills all the basic requirements. It returns a default value if none exists, initializing the store; it determines what sort of update needs to be done based on the type of the action, and returns new values; and it returns the previous state if no work needs to be done.
 
-There are some simple tweaks that can be made to this reducer. First, repeated `if`/`else` statements quickly grow tiresome, so it's very common to use `switch` statements instead. Second, we can use ES2015's default parameter values to handle the initial "no existing data" case. With those changes, the reducer would look like:
+There are some simple tweaks that can be made to this reducer. First, repeated `if`/`else` statements quickly grow tiresome, so it's very common to use `switch` statements instead. Second, we can use default parameter values to handle the initial "no existing data" case. With those changes, the reducer would look like:
 
 ```js
 function counter(state = 0, action) {
diff --git a/docs/usage/structuring-reducers/InitializingState.md b/docs/usage/structuring-reducers/InitializingState.md
index e161a96801e..00593648cb2 100644
--- a/docs/usage/structuring-reducers/InitializingState.md
+++ b/docs/usage/structuring-reducers/InitializingState.md
@@ -6,13 +6,13 @@ description: 'Structuring Reducers > Initializing State: How Redux state is init
 
 # Initializing State
 
-There are two main ways to initialize state for your application. The `createStore` method can accept an optional `preloadedState` value as its second argument. Reducers can also specify an initial value by looking for an incoming state argument that is `undefined`, and returning the value they'd like to use as a default. This can either be done with an explicit check inside the reducer, or by using the ES2015 default argument value syntax: `function myReducer(state = someDefaultValue, action)`.
+There are two main ways to initialize state for your application. The `createStore` method can accept an optional `preloadedState` value as its second argument. Reducers can also specify an initial value by looking for an incoming state argument that is `undefined`, and returning the value they'd like to use as a default. This can either be done with an explicit check inside the reducer, or by using the default argument value syntax: `function myReducer(state = someDefaultValue, action)`.
 
 It's not always immediately clear how these two approaches interact. Fortunately, the process does follow some predictable rules. Here's how the pieces fit together.
 
 ## Summary
 
-Without `combineReducers()` or similar manual code, `preloadedState` always wins over `state = ...` in the reducer because the `state` passed to the reducer _is_ `preloadedState` and _is not_ `undefined`, so the ES2015 argument syntax doesn't apply.
+Without `combineReducers()` or similar manual code, `preloadedState` always wins over `state = ...` in the reducer because the `state` passed to the reducer _is_ `preloadedState` and _is not_ `undefined`, so the argument syntax doesn't apply.
 
 With `combineReducers()` the behavior is more nuanced. Those reducers whose state is specified in `preloadedState` will receive that state. Other reducers will receive `undefined` _and because of that_ will fall back to the `state = ...` default argument they specify.
 
@@ -59,7 +59,7 @@ const store = createStore(counter, 42)
 console.log(store.getState()) // 42
 ```
 
-Why is it `42`, and not `0`, this time? Because `createStore` was called with `42` as the second argument. This argument becomes the `state` passed to your reducer along with the dummy action. **This time, `state` is not undefined (it's `42`!), so ES2015 default argument syntax has no effect.** The `state` is `42`, and `42` is returned from the reducer.
+Why is it `42`, and not `0`, this time? Because `createStore` was called with `42` as the second argument. This argument becomes the `state` passed to your reducer along with the dummy action. **This time, `state` is not undefined (it's `42`!), so default argument syntax has no effect.** The `state` is `42`, and `42` is returned from the reducer.
 
 ### Combined Reducers
 
@@ -122,4 +122,4 @@ In this case, `state` was specified so it didn't fall back to `{}`. It was an ob
 
 ## Recap
 
-To sum this up, if you stick to Redux conventions and return the initial state from reducers when they're called with `undefined` as the `state` argument (the easiest way to implement this is to specify the `state` ES2015 default argument value), you're going to have a nice useful behavior for combined reducers. **They will prefer the corresponding value in the `preloadedState` object you pass to the `createStore()` function, but if you didn't pass any, or if the corresponding field is not set, the default `state` argument specified by the reducer is chosen instead.** This approach works well because it provides both initialization and hydration of existing data, but lets individual reducers reset their state if their data was not preserved. Of course you can apply this pattern recursively, as you can use `combineReducers()` on many levels, or even compose reducers manually by calling reducers and giving them the relevant part of the state tree.
+To sum this up, if you stick to Redux conventions and return the initial state from reducers when they're called with `undefined` as the `state` argument (the easiest way to implement this is to specify the `state` default argument value), you're going to have a nice useful behavior for combined reducers. **They will prefer the corresponding value in the `preloadedState` object you pass to the `createStore()` function, but if you didn't pass any, or if the corresponding field is not set, the default `state` argument specified by the reducer is chosen instead.** This approach works well because it provides both initialization and hydration of existing data, but lets individual reducers reset their state if their data was not preserved. Of course you can apply this pattern recursively, as you can use `combineReducers()` on many levels, or even compose reducers manually by calling reducers and giving them the relevant part of the state tree.
diff --git a/docs/usage/structuring-reducers/UsingCombineReducers.md b/docs/usage/structuring-reducers/UsingCombineReducers.md
index 2d9cff959b2..14986cf953c 100644
--- a/docs/usage/structuring-reducers/UsingCombineReducers.md
+++ b/docs/usage/structuring-reducers/UsingCombineReducers.md
@@ -26,9 +26,9 @@ There are several important ideas to be aware of when using `combineReducers`:
 
 There are two ways to define the initial shape and contents of your store's state. First, the `createStore` function can take `preloadedState` as its second argument. This is primarily intended for initializing the store with state that was previously persisted elsewhere, such as the browser's localStorage. The other way is for the root reducer to return the initial state value when the state argument is `undefined`. These two approaches are described in more detail in [Initializing State](./InitializingState.md), but there are some additional concerns to be aware of when using `combineReducers`.
 
-`combineReducers` takes an object full of slice reducer functions, and creates a function that outputs a corresponding state object with the same keys. This means that if no preloaded state is provided to `createStore`, the naming of the keys in the input slice reducer object will define the naming of the keys in the output state object. The correlation between these names is not always apparent, especially when using ES2015 features such as default module exports and object literal shorthands.
+`combineReducers` takes an object full of slice reducer functions, and creates a function that outputs a corresponding state object with the same keys. This means that if no preloaded state is provided to `createStore`, the naming of the keys in the input slice reducer object will define the naming of the keys in the output state object. The correlation between these names is not always apparent, especially when using features such as default module exports and object literal shorthands.
 
-Here's an example of how use of ES2015 object literal shorthand with `combineReducers` can define the state shape:
+Here's an example of how use of object literal shorthand with `combineReducers` can define the state shape:
 
 ```js
 // reducers.js
@@ -46,7 +46,7 @@ import theDefaultReducer, {
   secondNamedReducer
 } from './reducers'
 
-// Use ES2015 object literal shorthand syntax to define the object shape
+// Use object literal shorthand syntax to define the object shape
 const rootReducer = combineReducers({
   theDefaultReducer,
   firstNamedReducer,
@@ -58,7 +58,7 @@ console.log(store.getState())
 // {theDefaultReducer : 0, firstNamedReducer : 1, secondNamedReducer : 2}
 ```
 
-Notice that because we used the ES2015 shorthand for defining an object literal, the key names in the resulting state are the same as the variable names from the imports. This may not always be the desired behavior, and is often a cause of confusion for those who aren't as familiar with ES2015 syntax.
+Notice that because we used the shorthand for defining an object literal, the key names in the resulting state are the same as the variable names from the imports. This may not always be the desired behavior, and is often a cause of confusion for those who aren't as familiar with modern JS syntax.
 
 Also, the resulting names are a bit odd. It's generally not a good practice to actually include words like "reducer" in your state key names - the keys should simply reflect the domain or type of data they hold. This means we should either explicitly specify the names of the keys in the slice reducer object to define the keys in the output state object, or carefully rename the variables for the imported slice reducers to set up the keys when using the shorthand object literal syntax.
 
diff --git a/src/bindActionCreators.ts b/src/bindActionCreators.ts
index 24e9c2050d6..b23219c6fdd 100644
--- a/src/bindActionCreators.ts
+++ b/src/bindActionCreators.ts
@@ -21,7 +21,7 @@ function bindActionCreator<A extends Action>(
  * and get a dispatch wrapped function in return.
  *
  * @param actionCreators An object whose values are action
- * creator functions. One handy way to obtain it is to use ES2015 `import * as`
+ * creator functions. One handy way to obtain it is to use `import * as`
  * syntax. You may also pass a single function.
  *
  * @param dispatch The `dispatch` function available on your Redux
diff --git a/src/combineReducers.ts b/src/combineReducers.ts
index 9c37a539c7b..5d99a8b5855 100644
--- a/src/combineReducers.ts
+++ b/src/combineReducers.ts
@@ -103,7 +103,7 @@ function assertReducerShape(reducers: {
  *
  * @param reducers An object whose values correspond to different reducer
  *   functions that need to be combined into one. One handy way to obtain it
- *   is to use ES2015 `import * as reducers` syntax. The reducers may never
+ *   is to use `import * as reducers` syntax. The reducers may never
  *   return undefined for any action. Instead, they should return their
  *   initial state if the state passed to them was undefined, and the current
  *   state for any unrecognized action.