หัวใจของ Redux มีอยู่ 3 ข้อ

Globalize Selectors if Needed​

[...]

We refer to this pattern as "globalizing" selectors. A "globalized" selector is one that accepts the Redux root state as an argument, and knows how to find the relevant slice of state to perform the real logic. A "localized" selector is one that expects just a piece of the state as an argument, without knowing or caring where that is in the root state:

// "Globalized" - accepts root state, knows to find data at `state.todos`
const selectAllTodosCompletedGlobalized = state =>
  state.todos.every(todo => todo.completed)

// "Localized" - only accepts `todos` as argument, doesn't know where that came from
const selectAllTodosCompletedLocalized = todos =>
  todos.every(todo => todo.completed)

"Localized" selectors can be turned into "globalized" selectors by wrapping them in a function that knows how to retrieve the right slice of state and pass it onwards.

Redux Toolkit's createEntityAdapter API is an example of this pattern. If you call todosAdapter.getSelectors(), with no argument, it returns a set of "localized" selectors that expect the entity slice state as their argument. If you call todosAdapter.getSelectors(state => state.todos), it returns a set of "globalized" selectors that expect to be called with the Redux root state as their argument.

There may also be other benefits to having "localized" versions of selectors as well. For example, say we have an advanced scenario of keeping multiple copies of createEntityAdapter data nested in the store, such as a chatRoomsAdapter that tracks rooms, and each room definition then has a chatMessagesAdapter state to store the messages. We can't directly look up the messages for each room - we first have to retrieve the room object, then select the messages out of that. This is easier if we have a set of "localized" selectors for the messages.

Balance Selector Usage​

[...]

Similarly, don't make every single selector memoized!. Memoization is only needed if you are truly deriving results, and if the derived results would likely create new references every time. A selector function that does a direct lookup and return of a value should be a plain function, not memoized.

Some examples of when and when not to memoize:

// ❌ DO NOT memoize: will always return a consistent reference
const selectTodos = state => state.todos
const selectNestedValue = state => state.some.deeply.nested.field
const selectTodoById = (state, todoId) => state.todos[todoId]

// ❌ DO NOT memoize: deriving data, but will return a consistent result
const selectItemsTotal = state => {
  return state.items.reduce((result, item) => {
    return result + item.total
  }, 0)
}
const selectAllCompleted = state => state.todos.every(todo => todo.completed)

// ✅ SHOULD memoize: returns new references when called
const selectTodoDescriptions = state => state.todos.map(todo => todo.text)

Creating Unique Selector Instances​

There are many cases where a selector function needs to be reused across multiple components. If the components will all be calling the selector with different arguments, it will break memoization - the selector never sees the same arguments multiple times in a row, and thus can never return a cached value.

The standard approach here is to create a unique instance of a memoized selector in the component, and then use that with useSelector. That allows each component to consistently pass the same arguments to its own selector instance, and that selector can correctly memoize the results.

For function components, this is normally done with useMemo or useCallback:

import { makeSelectItemsByCategory } from './categoriesSlice'

function CategoryList({ category }) {
  // Create a new memoized selector, for each component instance, on mount
  const selectItemsByCategory = useMemo(makeSelectItemsByCategory, [])

  const itemsByCategory = useSelector(state =>
    selectItemsByCategory(state, category)
  )
}

Using Selectors with React-Redux​

• Calling Selectors with Parameters​

It's common to want to pass additional arguments to a selector function. However, useSelector always calls the provided selector function with one argument - the Redux root state.

The simplest solution is to pass an anonymous selector to useSelector, and then immediately call the real selector with both state and any additional arguments:

import { selectTodoById } from './todosSlice'

function TodoListitem({ todoId }) {
  // Captures `todoId` from scope, gets `state` as an arg, and forwards both
  // to the actual selector function to extract the result
  const todo = useSelector(state => selectTodoById(state, todoId))
}

Selector Factories​

createSelector only has a default cache size of 1, and this is per each unique instance of a selector. This creates problems when a single selector function needs to get reused in multiple places with differing inputs.

One option is to create a "selector factory" - a function that runs createSelector() and generates a new unique selector instance every time it's called:

const makeSelectItemsByCategory = () => {
  const selectItemsByCategory = createSelector(
    [state => state.items, (state, category) => category],
    (items, category) => items.filter(item => item.category === category)
  )
  return selectItemsByCategory
}

This is particularly useful when multiple similar UI components need to derive different subsets of the data based on props.

Passing Input Parameters​

A Reselect-generated selector function can be called with as many arguments as you want: selectThings(a, b, c, d, e). However, what matters for re-running the output is not the number of arguments, or whether the arguments themselves have changed to be new references. Instead, it's about the "input selectors" that were defined, and whether their results have changed. Similarly, the arguments for the "output selector" are solely based on what the input selectors return.

This means that if you want to pass additional parameters through to the output selector, you must define input selectors that extract those values from the original selector arguments:

const selectItemsByCategory = createSelector(
  [
    // Usual first input - extract value from `state`
    state => state.items,
    // Take the second arg, `category`, and forward to the output selector
    (state, category) => category
  ],
  // Output selector gets (`items, category)` as args
  (items, category) => items.filter(item => item.category === category)
)

For consistency, you may want to consider passing additional parameters to a selector as a single object, such as selectThings(state, otherArgs), and then extracting values from the otherArgs object.

Reselect Usage Patterns and Limitations​

Nesting Selectors​

It's possible to take selectors generated with createSelector, and use them as inputs for other selectors as well. In this example, the selectCompletedTodos selector is used as an input to selectCompletedTodoDescriptions:

const selectTodos = state => state.todos

const selectCompletedTodos = createSelector([selectTodos], todos => todos.filter(todo => todo.completed) )

const selectCompletedTodoDescriptions = createSelector( [selectCompletedTodos], completedTodos => completedTodos.map(todo => todo.text) )

Because of this, it's important that all of the "input selectors" you provide should accept the same types of parameters. Otherwise, the selectors will break.

const selectItems = state => state.items;

// expects a number as the second argument
const selectItemId = (state, itemId) => itemId;

// expects an object as the second argument
const selectOtherField (state, someObject) => someObject.someField;

const selectItemById = createSelector(
    [selectItems, selectItemId, selectOtherField],
    (items, itemId, someField) => items[itemId]
);

In this example, selectItemId expects that its second argument will be some simple value, while selectOtherField expects that the second argument is an object. If you call selectItemById(state, 42), selectOtherField will break because it's trying to access 42.someField.

const selectItems = state => state.items
const selectItemId = (state, itemId) => itemId

const selectItemById = createSelector(
  [selectItems, selectItemId],
  (items, itemId) => items[itemId]
)

const item = selectItemById(state, 42)

/*
Internally, Reselect does something like this:

const firstArg = selectItems(state, 42);  
const secondArg = selectItemId(state, 42);  

const result = outputSelector(firstArg, secondArg);  
return result;  
*/

const a = someSelector(state, 1) // first call, not memoized
const b = someSelector(state, 1) // same inputs, memoized
const c = someSelector(state, 2) // different inputs, not memoized
const d = someSelector(state, 1) // different inputs from last time, not memoized

const state = {
  a: {
    first: 5
  },
  b: 10
}

const selectA = state => state.a
const selectB = state => state.b

const selectA1 = createSelector([selectA], a => a.first)

const selectResult = createSelector([selectA1, selectB], (a1, b) => {
  console.log('Output selector running')
  return a1 + b
})

const result = selectResult(state)
// Log: "Output selector running"
console.log(result)
// 15

const secondResult = selectResult(state)
// No log output
console.log(secondResult)
// 15

Note that the second time we called selectResult, the "output selector" didn't execute. Because the results of selectA1 and selectB were the same as the first call, selectResult was able to return the memoized result from the first call.

// ❌ BROKEN: this will not memoize correctly, and does nothing useful!
const brokenSelector = createSelector(
  state => state.todos,
  todos => todos
)

When you call the selector, Reselect will run your input selectors with all of the arguments you gave, and looks at the returned values. If any of the results are === different than before, it will re-run the output selector, and pass in those results as the arguments. If all of the results are the same as the last time, it will skip re-running the output selector, and just return the cached final result from before.

This means that "input selectors" should usually just extract and return values, and the "output selector" should do the transformation work.

const selectA = state => state.a
const selectB = state => state.b
const selectC = state => state.c

const selectABC = createSelector([selectA, selectB, selectC], (a, b, c) => {
  // do something with a, b, and c, and return a result
  return a + b + c
})

// Call the selector function and get a result
const abc = selectABC(state)

// could also be written as separate arguments, and works exactly the same
const selectABC2 = createSelector(selectA, selectB, selectC, (a, b, c) => {
  // do something with a, b, and c, and return a result
  return a + b + c
})

Memoization is a form of caching. It involves tracking inputs to a function, and storing the inputs and the results for later reference. If a function is called with the same inputs as before, the function can skip doing the actual work, and return the same result it generated the last time it received those input values. This optimizes performance by only doing work if inputs have changed, and consistently returning the same result references if the inputs are the same.

function TodoList() {
  // ❌ WARNING: this _always_ returns a new reference, so it will _always_ re-render!
  const completedTodos = useSelector(state =>
    state.todos.map(todo => todo.completed)
  )
}

Optimizing Selectors with Memoization​

• Selectors used with useSelector or mapState will be re-run after every dispatched action, regardless of what section of the Redux root state was actually updated. Re-running expensive calculations when the input state sections didn't change is a waste of CPU time, and it's very likely that the inputs won't have changed most of the time anyway.
• useSelector and mapState rely on === reference equality checks of the return values to determine if the component needs to re-render. If a selector always returns new references, it will force the component to re-render even if the derived data is effectively the same as last time. This is especially common with array operations like map() and filter(), which return new array references.

// Bad: always returning a new reference
const selectTodoDescriptions = state => {
  // This creates a new array reference!
  return state.todos.map(todo => todo.text)
}

useSelector compares its results using strict === reference comparisons, so the component will re-render any time the selector result is a new reference! This means that if you create a new reference in your selector and return it, your component could re-render every time an action has been dispatched, even if the data really isn't different.

On indirection through multiple action creators and reducers for managing different parts of an application

global vs local state management. Solutions are not one size fits all.

Reasons why redux was so successful

store enhancers for redux; All compose does is let you write deeply nested function transformations without the rightward drift of the code. Don't give it too much credit!

SPAs:

• popularised by client-side web frameworks like Angular, React and Vue.js
• real difference between the MVP app is shifting most of its work on the client side
• there's client side MVC, MVVM (model-view-view-model) and FRP (functional reactive programming)

Angular - client side MVC framework following its pattern, except it's running inside the users web browser.

React - implementation of FRP. A little more flexible, but more concerned with state change events in data (often using some event store like Redux)

redux-thunk 默认加入

Redux Toolkit作者说了，RTK并没有改变任何异步操作的调用。还是可以使用中间件（象redux-thunk）获取数据和分发结果动作。

不同类型的函数。

comineReucers只是简化通用案例的应用函数。

函数最好是单一职责

应用风格指南，值得参考的部分

强烈建议，应用将文件夹结构按照功能特性划分

Catching actions to accumulate and group them

从示例看出来，connect可以连接函数式组件，不仅仅是类组件。

react-redux包很简单，暴露了两个东西：Provider和connnect

还是需要Provider哦

React Redux提供的一些hook api可以用来替代connect高阶组件。用来订阅Redux Store和分发动作，而无需connect()

Redux Toolkit并没有侵入Redux。可以用在React，Angular，Vue和其它UI层。所以，我想，应该也可以用在Taro上面！

Redux-Toolkit不再需要安装redux-thunk和redux-devtools-extension。

文章讲解了作者在使用React Redux时的文件夹架构。作为他的最佳实践，可以参考一下。

Redux Toolkit的用意是以标准方式编写Redux逻辑，帮助解决下面三个问题：

• 配置store太复杂
• 需要添加太多的包
• 需要很多模板代码

react-redux带来两样东西： 一个叫Provider的组件 一个叫connect的函数

Reducer规则2:必须是纯函数，不能用副作用。

默认为返回当前状态。

所以说，有时候使用createSlice就同时有了createReducer和createActions.

整个App状态存在单个Store对象树。改变状态的只有action，一个描述发生个么的对象。然后reducer负责状态改变。

Good explanation of how to convert to using react hooks with redux store.

probably a common and useful example that is used with Redux

非模拟时，由redux-saga内部的调度器帮我们执行 next（在异步函数或副作用函数执行获得结果后）；

模拟时，由测试函数自己根据需要执行 next，所以说无需模拟 Api.fetch 函数的具体返回结果，从而为测试带来了方便

This is a selector

This is a memoized selector. items.reduce will be evaluated during the first call. Any subsequent call with the same parameters will return the result without computing items.reduce.

Twitter's mobile app is useful as a "production" example of what an application state tree can look like.

This also looks like an interesting and potentially relatively simple take on supporting effects in reducers.

Very interesting thread with a discussion on how to improve handling of effects in Redux and make Redux applications composable ala. the Elm Architecture.

Redux Loop looks like a very interesting take on supporting the Elm arch with the current version of Redux

This is a useful introduction through recent developments in client-side data management and an overview of the different choices available when building a new application and guidance on what is appropriate for different sizes of app.

Useful explanation of how state storage in Redux differs from other frameworks.

Useful tutorial that covers combined usage on the client and server.

For an example of dispatch at regular intervals, the SoundRedux media player app dispatches an action every time the play time of the current song, measured in seconds, changes.

This is great for the simple case where there is no interdependent state. For ideas on what to do when one part of the state tree depends on another, see http://stackoverflow.com/questions/34782948/how-can-i-model-interdependent-data-with-cascading-updates-in-redux/34796163#34796163

Very useful overview of the conceptual differences between several modern UI architectures

Recommends "deepFreeze" lib to protect against unexpected mutations to objects and arrays.

I find this slightly disturbing to read in the documentation (!)

Probably the best explanation I've seen yet on the why and how of a functional approach to UI state management with Redux