fix (docs): dictionary.txt: 'redux' -> 'Redux'

dictionary.txt

@@ -363,7 +363,7 @@ README
 reCAPTCHA
 reconciler
 Reddit
-redux
+*redux
 Redux
 rehydrate
 reimplement

docs/docs/creating-and-modifying-pages.md

@@ -178,7 +178,7 @@ It does come with the advantage of querying your data from one place after decla
 
 However, it doesn’t give you the opportunity to know what exactly you are querying for in the template and if any changes occur in the component query structure in `gatsby-node.js`. [Hot reload](/docs/glossary#hot-module-replacement) is taken off the table and the site needs to be rebuilt for changes to reflect.
 
-Gatsby stores page metadata (including context) in a redux store (which also means that it stores the memory of the page). For larger sites (either number of pages and/or amount of data that is being passed via page context) this will cause problems. There might be "out of memory" crashes if it's too much data or degraded performance.
+Gatsby stores page metadata (including context) in a Redux store (which also means that it stores the memory of the page). For larger sites (either number of pages and/or amount of data that is being passed via page context) this will cause problems. There might be "out of memory" crashes if it's too much data or degraded performance.
 
 > If there is memory pressure, Node.js will try to garbage collect more often, which is a known performance issue.
 

docs/docs/data-storage-redux.md

@@ -16,7 +16,7 @@ The namespaces in Gatsby's Redux store are a great overview of the Gatsby intern
 - **Jobs** - Long-running and CPU-intensive processes, generally started as a side-effect to a GraphQL query. Gatsby doesn’t finish its process until all jobs are ended.
 - **webpack** - Config for the [webpack](/docs/webpack-and-ssr/) bundler which handles code optimization and splitting of delivered JavaScript bundles.
 
-The Gatsby [redux index file](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/redux/index.ts) has two key exports, `store` and `emitter`. Throughout the bootstrap and build phases, `store` is used to get the current state and dispatch actions, while `emitter` is used to register listeners for particular actions. The store is also made available to Gatsby users through the [Node APIs](/docs/node-apis/).
+The Gatsby [Redux index file](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/redux/index.ts) has two key exports, `store` and `emitter`. Throughout the bootstrap and build phases, `store` is used to get the current state and dispatch actions, while `emitter` is used to register listeners for particular actions. The store is also made available to Gatsby users through the [Node APIs](/docs/node-apis/).
 
 ## Actions
 

docs/docs/debugging-replace-renderer-api.md

@@ -51,7 +51,7 @@ You'll need to override your plugins' `replaceRenderer` code in your `gatsby-ssr
 
 ### Initial setup
 
-In this example project you're using [`redux`](https://github.com/gatsbyjs/gatsby/tree/master/examples/using-redux) and [Gatsby's Styled Components plugin](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-styled-components).
+In this example project you're using [Redux](https://github.com/gatsbyjs/gatsby/tree/master/examples/using-redux) and [Gatsby's Styled Components plugin](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-styled-components).
 
 ```js:title=gatsby-config.js
 module.exports = {

docs/docs/how-plugins-apis-are-run.md

@@ -16,7 +16,7 @@ _Note: this section only explains how `gatsby-node` plugins are run. Not browser
 
 ## Early in the build
 
-Early in the bootstrap phase, you [load all the configured plugins](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/index.js#L40) (and internal plugins) for the site. These are saved into redux under the `flattenedPlugins` namespace. Each plugin in redux contains the following fields:
+Early in the bootstrap phase, you [load all the configured plugins](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/index.js#L40) (and internal plugins) for the site. These are saved into Redux under the `flattenedPlugins` namespace. Each plugin in Redux contains the following fields:
 
 - **resolve**: absolute path to the plugin's directory
 - **id**: String concatenation of 'Plugin ' and the name of the plugin. E.g. `Plugin query-runner`
@@ -27,7 +27,7 @@ Early in the bootstrap phase, you [load all the configured plugins](https://gith
 - **browserAPIs**: List of browser APIs that this plugin implements
 - **ssrAPIs**: List of SSR APIs that this plugin implements
 
-In addition, you also create a lookup from API to the plugins that implement it and save this to redux as `api-to-plugins`. This is implemented in [load-plugins/validate.js](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/validate.js#L106)
+In addition, you also create a lookup from API to the plugins that implement it and save this to Redux as `api-to-plugins`. This is implemented in [load-plugins/validate.js](https://github.com/gatsbyjs/gatsby/blob/8029c6647ab38792bb0a7c135ab4b98ae70a2627/packages/gatsby/src/bootstrap/load-plugins/validate.js#L106)
 
 ## apiRunInstance
 

docs/docs/how-shadowing-works.md

@@ -76,7 +76,7 @@ exports.onCreateWebpackConfig = (
 }
 ```
 
-We first check for themes in the redux store. This is for backwards-compatibility since themes are now merged with plugins. If the `themes` key was used in the user's `gatsby-config.js` those are passed to the shadowing resolver plugin. Otherwise, the flattened plugin list is passed.
+We first check for themes in the Redux store. This is for backwards-compatibility since themes are now merged with plugins. If the `themes` key was used in the user's `gatsby-config.js` those are passed to the shadowing resolver plugin. Otherwise, the flattened plugin list is passed.
 
 ## Structure of a webpack Plugin
 

docs/docs/html-generation.md

@@ -16,7 +16,7 @@ The high level process is:
 
 1. Create a webpack configuration for Node.js Server Side Rendering (SSR)
 2. Build a `render-page.js` that takes a page path and renders its HTML
-3. For each page in redux, call `render-page.js`
+3. For each page in Redux, call `render-page.js`
 
 ## webpack
 

docs/docs/node-creation.md

@@ -4,7 +4,7 @@ title: Node Creation
 
 Nodes are created by calling the [createNode](/docs/actions/#createNode) action. Nodes can be any object.
 
-A node is stored in redux under the `nodes` namespace, whose state is a map of the node ID to the actual node object.
+A node is stored in Redux under the `nodes` namespace, whose state is a map of the node ID to the actual node object.
 
 ## Sourcing Nodes
 
@@ -16,7 +16,7 @@ There are a few different scenarios for creating parent/child relationships.
 
 ### Node relationship storage model
 
-All nodes in Gatsby are stored in a flat structure in the redux `nodes` namespace. A node's `children` field is an array of node IDS, whose nodes are also at the top level of the redux namespace. Here's an example of the `nodes` namespace.
+All nodes in Gatsby are stored in a flat structure in the Redux `nodes` namespace. A node's `children` field is an array of node IDS, whose nodes are also at the top level of the Redux namespace. Here's an example of the `nodes` namespace.
 
 ```javascript
 {
@@ -30,13 +30,13 @@ An important note here is that we do not store a distinct collection of each typ
 
 ### Explicitly recording a parent/child relationship
 
-This occurs when a transformer plugin implements [onCreateNode](/docs/node-apis/#onCreateNode) in order to create some child of the originally created node. In this case, the transformer plugin will call [createParentChildLink](/docs/actions/#createParentChildLink), with the original node, and the newly created node. All this does is push the child's node ID onto the parent's `children` collection and resave the parent to redux.
+This occurs when a transformer plugin implements [onCreateNode](/docs/node-apis/#onCreateNode) in order to create some child of the originally created node. In this case, the transformer plugin will call [createParentChildLink](/docs/actions/#createParentChildLink), with the original node, and the newly created node. All this does is push the child's node ID onto the parent's `children` collection and resave the parent to Redux.
 
 This does **not** automatically create a `parent` field on the child node. If a plugin author wishes to allow child nodes to navigate to their parents in GraphQL queries, they must explicitly set `childNode.parent: 'parent.id'` when creating the child node.
 
 ### Foreign Key reference (`___NODE`)
 
-We've established that child nodes are stored at the top level in redux, and are referenced via ids in their parent's `children` collection. The same mechanism drives foreign key relationships. Foreign key fields have a `___NODE` suffix on the field name. At query time, Gatsby will take the field's value as an ID, and search redux for a matching node. This is explained in more detail in [schema gqlTypes](/docs/schema-inference#foreign-key-reference-___node).
+We've established that child nodes are stored at the top level in Redux, and are referenced via ids in their parent's `children` collection. The same mechanism drives foreign key relationships. Foreign key fields have a `___NODE` suffix on the field name. At query time, Gatsby will take the field's value as an ID, and search Redux for a matching node. This is explained in more detail in [schema gqlTypes](/docs/schema-inference#foreign-key-reference-___node).
 
 ### Plain objects at creation time
 
@@ -51,25 +51,25 @@ Let's say you create the following node by passing it to `createNode`
 }
 ```
 
-The value for `baz` is itself an object. That value's parent is the top level object. In this case, Gatsby saves the top level node as is to redux. It doesn't attempt to extract `baz` into its own node. It does however track the subobject's root NodeID using [Node Tracking](/docs/node-tracking/)
+The value for `baz` is itself an object. That value's parent is the top level object. In this case, Gatsby saves the top level node as is to Redux. It doesn't attempt to extract `baz` into its own node. It does however track the subobject's root NodeID using [Node Tracking](/docs/node-tracking/)
 
 During schema compilation, Gatsby will infer the sub object's type while [creating the gqlType](/docs/schema-inference#plain-object-or-value-field).
 
 ## Fresh/stale nodes
 
-Every time a build is re-run, there is a chance that a node that exists in the redux store no longer exists in the original data source. E.g. a file might be deleted from disk between runs. We need a way to indicate that fact to Gatsby.
+Every time a build is re-run, there is a chance that a node that exists in the Redux store no longer exists in the original data source. E.g. a file might be deleted from disk between runs. We need a way to indicate that fact to Gatsby.
 
-To track this, there is a redux `nodesTouched` namespace that tracks whether a particular node ID has been touched. This occurs whenever a node is created (handled by [CREATE_NODE](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/redux/reducers/nodes-touched.ts)), or an explicit call to [touchNode](/docs/actions/#touchNode).
+To track this, there is a Redux `nodesTouched` namespace that tracks whether a particular node ID has been touched. This occurs whenever a node is created (handled by [CREATE_NODE](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/redux/reducers/nodes-touched.ts)), or an explicit call to [touchNode](/docs/actions/#touchNode).
 
 When a `source-nodes` plugin runs again, it generally recreates nodes (which automatically touches them too). But in some cases, such as [transformer-screenshot](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-transformer-screenshot/src/gatsby-node.js#L56), a node might not change, but we still want to keep it around for the build. In these cases, we must explicitly call `touchNode`.
 
-Any nodes that aren't touched by the end of the `source-nodes` phase, are deleted. This is performed via a diff between the `nodesTouched` and `nodes` redux namespaces, in [source-nodes.ts](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/source-nodes.ts)
+Any nodes that aren't touched by the end of the `source-nodes` phase, are deleted. This is performed via a diff between the `nodesTouched` and `nodes` Redux namespaces, in [source-nodes.ts](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/source-nodes.ts)
 
 ## Changing a node's fields
 
-From a site developer's point of view, nodes are immutable. In the sense that if you simply change a node object, those changes will not be seen by other parts of Gatsby. To make a change to a node, it must be persisted to redux via an action.
+From a site developer's point of view, nodes are immutable. In the sense that if you simply change a node object, those changes will not be seen by other parts of Gatsby. To make a change to a node, it must be persisted to Redux via an action.
 
-So, how do you add a field to an existing node? E.g. perhaps in onCreateNode, you want to add a transformer specific field? You can call [createNodeField](/docs/actions/#createNodeField) and this will simply add your field to the node's `node.fields` object and then persists it to redux. This can then be referenced by other parts of your plugin at later stages of the build.
+So, how do you add a field to an existing node? E.g. perhaps in onCreateNode, you want to add a transformer specific field? You can call [createNodeField](/docs/actions/#createNodeField) and this will simply add your field to the node's `node.fields` object and then persists it to Redux. This can then be referenced by other parts of your plugin at later stages of the build.
 
 ## Node Tracking
 

docs/docs/node-tracking.md

@@ -47,7 +47,7 @@ Its sub objects are `foo` (value = `{ myfile: "blog/my-blog.md", b: 2}`), and th
 
 ## Find Root Nodes
 
-To access this information, `schema/node-model.js` provides the [findRootNodeAncestor()](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/node-model.js#L403) function. It takes an object, and looks up its parent's nodeID in `rootNodeMap`. It then finds the actual node in redux. It then gets that node's `parent` ID, and gets the parent node from redux. And continues in this way until the root node is found.
+To access this information, `schema/node-model.js` provides the [findRootNodeAncestor()](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/node-model.js#L403) function. It takes an object, and looks up its parent's nodeID in `rootNodeMap`. It then finds the actual node in Redux. It then gets that node's `parent` ID, and gets the parent node from Redux. And continues in this way until the root node is found.
 
 In the above example, `nodeA` has parent `id1`. So `findRootNodeAncestor({ blog: "blog/my-blog.md", b: 2 })` would return the node for `id1` (the parent).
 

docs/docs/page-node-dependencies.md

@@ -28,7 +28,7 @@ Passing `nodeId` tells Gatsby that the page depends specifically on this node. S
 
 ## How dependencies are stored
 
-Page -> Node dependencies are tracked via the `componentDataDependencies` redux namespace.
+Page -> Node dependencies are tracked via the `componentDataDependencies` Redux namespace.
 
 ```javascript
 {

docs/docs/preprocessing-external-images.md

@@ -72,7 +72,7 @@ exports.onCreateNode = async ({
       createNode, // helper function in gatsby-node to generate the node
       createNodeId, // helper function in gatsby-node to generate the node id
       cache, // Gatsby's cache
-      store, // Gatsby's redux store
+      store, // Gatsby's Redux store
     })
 
     // if the file was created, attach the new node to the parent node