mirror of
https://github.com/microsoft/frontend-bootcamp.git
synced 2026-01-26 14:56:42 +08:00
more details in step 5
This commit is contained in:
@@ -2,17 +2,17 @@
|
|||||||
|
|
||||||
[Lessons](../) | [Exercise](./exercise/) | [Demo](./demo/)
|
[Lessons](../) | [Exercise](./exercise/) | [Demo](./demo/)
|
||||||
|
|
||||||
Redux is an implementation of the Flux architectural pattern:
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
Ideally React gives us a mental model of:
|
Ideally React gives us a mental model of:
|
||||||
|
|
||||||
```
|
```
|
||||||
f(data) => view
|
f(data) => view
|
||||||
```
|
```
|
||||||
|
|
||||||
And it renders when data changes. However, in the real world, data is shaped like a tree and view is shaped like a tree. They don't always match. There are many approaches to Flux, but Redux promotes the data into a singleton state tree that listens for messages to manipulate the state as appropriate.
|
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.
|
||||||
|
|
||||||
|
Facebook invented a the Flux pattern to solve this shared state issue. Redux is an implementation of the Flux architectural pattern. Redux expects the data to be a singleton state tree that listens for messages to manipulate the state as appropriate:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
## View
|
## View
|
||||||
|
|
||||||
@@ -44,6 +44,8 @@ From the official documentation site:
|
|||||||
|
|
||||||
> Reducers are just pure functions that take the previous state and an action, and return the next state. Remember to return new state objects, instead of mutating the previous state.
|
> Reducers are just pure functions that take the previous state and an action, and return the next state. Remember to return new state objects, instead of mutating the previous state.
|
||||||
|
|
||||||
|
**Mental Model**: think of Reducer as part of the store and should have no side effects outside of defining how data can change from one state to next given action messages.
|
||||||
|
|
||||||
# Exercise
|
# Exercise
|
||||||
|
|
||||||
1. First, take a look at the store interface in the `exercise/src/store/index.tsx` - note that the `Store` interface has two keys: `todos` and `filter`. We'll concentrate on the `todos` which is an object where the keys are IDs and the values are of an `TodoItem` type.
|
1. First, take a look at the store interface in the `exercise/src/store/index.tsx` - note that the `Store` interface has two keys: `todos` and `filter`. We'll concentrate on the `todos` which is an object where the keys are IDs and the values are of an `TodoItem` type.
|
||||||
|
|||||||
Reference in New Issue
Block a user