From 3d7223ac6f546025220ef924d5d2c35adae20621 Mon Sep 17 00:00:00 2001 From: Elizabeth Craig Date: Thu, 28 Feb 2019 22:15:58 -0800 Subject: [PATCH] doc links and PR feedback --- step2-05/demo/README.md | 16 +++++++--------- step2-06/README.md | 6 +++--- 2 files changed, 10 insertions(+), 12 deletions(-) diff --git a/step2-05/demo/README.md b/step2-05/demo/README.md index 75aba06..71e8ce9 100644 --- a/step2-05/demo/README.md +++ b/step2-05/demo/README.md @@ -10,8 +10,6 @@ Ideally React gives us a mental model of: f(data) => view ``` -This is fine if the data never changes. However, React exists to deal with data updates via props (immutable) and state (changes based on `setState()` API). In the real world, data is shaped like a tree and view is shaped like a tree. They don't always match. - We can pass shared state data down to components using props and update it using callbacks, but as an application grows larger, passing around callbacks becomes unwieldy and the state data flow becomes hard to understand. To keep the application maintainable, we need a well-defined pattern for sharing and updating application state. Facebook invented the [Flux](https://facebook.github.io/flux/) architectural pattern to solve this shared state issue. [Redux](https://redux.js.org/) is an implementation of Flux. @@ -28,21 +26,21 @@ A view is a React component that consumes the store as its data. There is a spec ### Action -Actions are messages that represent some event, such as a user's action or a network request. With the aid of _reducers_, they affect the overall state. +[Actions](https://redux.js.org/basics/actions) are messages that represent some event, such as a user's action or a network request. With the aid of *reducers*, they affect the overall state. ### Store -The store contains a singleton state tree. The state tree is immutable and needs to be re-created at every action. This helps connected views easily to know when to update by allowing them to do a simple reference comparison rather than a deep comparison. You can think of each state as a snapshot of the app at that point in time. +The [store](https://redux.js.org/basics/store) contains a singleton state tree. The state tree is immutable and needs to be re-created at every action. This helps connected views easily to know when to update by allowing them to do a simple reference comparison rather than a deep comparison. You can think of each state as a snapshot of the app at that point in time. ### Dispatcher -There is a single dispatcher. It simply informs the store of all the actions that need to be performed. Additional middleware (explained later) can be applied to the store, and the dispatcher's job is to dispatch the message through all the middleware layers. +There is a single [dispatcher](https://redux.js.org/basics/data-flow), provided by the store. It simply informs the store of all the actions that need to be performed. Additional middleware (explained later) can be applied to the store, and the dispatcher's job is to dispatch the message through all the middleware layers. ### Reducers -Redux uses reducers to manage state changes. This name comes from the "reducer" function passed to `Array.reduce()`. +Redux uses [reducers](https://redux.js.org/basics/reducers) to manage state changes. This name comes from the "reducer" function passed to `Array.reduce()`. -A Redux reducer is a simple stateless **pure function** (no side effects). Its only job is to change the state from one immutable snapshot to another. It takes state + an action message as input, makes a modified copy of the state based on the action message type and payload, and returns the new state. (Reducers should not modify the previous state.) +A Redux reducer is a simple **pure function** (no side effects). Its only job is to transform the state from one immutable snapshot to another. It takes state + an action message as input, makes a modified copy of the state based on the action message type and payload, and returns the new state. (Reducers [should not modify](https://redux.js.org/introduction/three-principles#state-is-read-only) the previous state.) **Mental Model**: Think of a reducer as part of the store. It should have no side effects and only define how data changes from one state to the next given action messages. @@ -64,7 +62,7 @@ We begin the journey into Redux by looking at the store. The store consists of s ### Create store -The `createStore()` function is provided by Redux and can take in several arguments. The simplest form just takes in reducers. +The [`createStore()`](https://redux.js.org/api/createstore) function is provided by Redux and can take in several arguments. The simplest form just takes in reducers. ```ts const store = createStore(reducer); @@ -85,7 +83,7 @@ const store = createStore(reducer, { ### Reducers -Remember that the reducers are **pure**. Pure functions have no side effects. They always return the same output given the same input (idempotent). They are easily testable. +Remember that the [reducers are **pure**](https://redux.js.org/introduction/three-principles#changes-are-made-with-pure-functions). Pure functions have no side effects. They always return the same output given the same input (idempotent). They are easily testable. Reducers look at the action's message to decide what to do to the state. A convention established in the Flux community is that the action message (payload) should include a `type` key. Another convention is using switch statements against the `type` key to trigger further reducer functions. diff --git a/step2-06/README.md b/step2-06/README.md index 755d352..b127633 100644 --- a/step2-06/README.md +++ b/step2-06/README.md @@ -8,7 +8,7 @@ We also see how to compose reducers to make up the complete state shape. ## Dispatch -Given a store reference, you can dispatch an action to trigger the middleware and reducers. This changes the store and causes the view to re-render. (We'll look at how to pass the store and the dispatch function into the view later.) +Given a store reference, you can [dispatch](https://redux.js.org/api/store#dispatch) an action to trigger the middleware and reducers. This changes the store and causes the view to re-render. (We'll look at how to pass the store and the dispatch function into the view later.) ```ts const store = createStore(reducers); @@ -21,7 +21,7 @@ store.dispatch(actions.addTodo('id0', 'hello world')); In general, when an application grows, so does the complexity of the state tree. In a Redux application, it is best to have reducers that deal with only a sub-portion of the tree. -In our example, we have two parts of our state: `todos` and `filter`. We will split the reducer to pass the todos to a `todosReducer()` function and just return `all` to the `filter` key for now. This organization helps in navigating and understanding the reducers because it matches the shape of the state one-to-one: there's a separate reducer for each key in state. +In our example, we have two parts of our state: `todos` and `filter`. We will [split the reducer](https://redux.js.org/basics/reducers#splitting-reducers) to pass the todos to a `todosReducer()` function and just return `all` to the `filter` key for now. This organization helps in navigating and understanding the reducers because it matches the shape of the state one-to-one: there's a separate reducer for each key in state. Compare this example which handles the whole state in one reducer... @@ -59,7 +59,7 @@ With the second example, it is easy to understand which reducer changed a given To examine the state of the store, you can call `store.getState()` to get a snapshot of the current state. -In general, you should only store serializable things in the state so that you can easily save or transfer it. You can even save this state into a browser's local storage and restore for the next boot of your application! +In general, you should only include serializable things in the state so that you can easily save or transfer it. You can even save this state into a browser's local storage and restore for the next boot of your application! ## Visualizing the reducer and store change