React学习笔记--通过Redux 的三个基本原则来理解Redux

####澄清一个事实
严格的说来,Redux属于一种编程思想,类似于Flux,但是不同于Flux, Redux中并没有 dispatcher 的概念。事实上Redux 和 React 之间没有任何直接的关系。Redux 可以通过 React、Angular、jQuery 甚至纯 JavaScript来使用。当然,Redux 还是和 React 这类框架搭配使用才能更加有效的体现其作用,类React的前端框架通过 state 函数的形式来描述界面状态,Redux 通过 action 的形式来发起 state 变化。

为什么需要Redux

前后端分离的思潮越来越浓烈以及单页应用开发日趋复杂,前端JavaScript 需要管理越来越多的应用状态(state)。 这里的应用状态可能包括:
-Ajax请求
-服务器响应
-数据缓存
-本地生成但是尚未持久化到服务器的数据
-UI 状态,如:当前激活的路由,被选中的标签,是否需要显示加载动效,分页……
由于这些状态呈现出一种既相互独立取又彼此关联的错综复杂的状态,要妥善的管理这些状态是一件极具挑战的工作。举个列子:如果 model-A 的变化会引起 model-B 变化,那么当 view-A 变化时,就可能引起对应 model-A变化,同时可能引发 model-B 的变化(model-A),model-B的变化会进一步可引发 view-B 的变化,这时组件大的变化将如同裂变一样。这时的开发者脸上总是一副生无可恋的样纸,state 在什么时候,由于什么原因变化的,都发生了什么(state的如何变化已然不受控制)。 这个时候,想重现问题或者添加新功能就会变得举步维艰。Redux 试图让 state 的变化变得可预测。

Redux的三大原则

单一数据源

整个应用的 state 被储存在一棵 object tree 中,并且这个 object tree 只存在于唯一一个 store 中。这让同构应用(同构应用通俗的理解:前后端使用同一语言或技术进行开发)开发变得非常容易。来自服务端的 state 可以在无需编写更多代码的情况下被序列化并注入到客户端中。由于是单一的 state tree ,调试也变得非常容易。在开发中,通常将应用的 state 保存在本地,从而加快开发速度。

console.log(store.getState())

/* Prints { visibilityFilter: 'SHOW_ALL',todos: [ { text: 'Consider using Redux',completed: true,},{ text: 'Keep all state in a single tree',completed: false } ] } */

State 是只读的

state的改变只能通过触发特定的action完成(action 是一个用于描述已发生事件的普通对象)。这样设计的好处在于,确保了视图和网络请求都不能直接修改 state,相反它们只能表达想要修改的意图。因为所有的修改都被集中化处理,且严格按照一个接一个的顺序执行,因此不用担心 race condition 的出现。 Action 就是普通对象而已。同时通过这样的设计开发后期调试或测试时对于复现问题。

store.dispatch({
  type: 'COMPLETE_TODO',index: 1
});

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',filter: 'SHOW_COMPLETED'
});

使用纯函数来执行修改

为了可控的,详细的描述 action 如何改变 state tree ,需要开发人员自己完成 reducers 的编写工作。
Reducer 只是一些纯函数,它接收先前的 state 和 action,并返回新的 state。良好的应用设计实现中每一个educer应该被设计为,分别独立地操作 state tree 的不同部分。因为 reducer 只是函数,所以开发人员可以控制它们被调用的顺序,传入附加数据,甚至编写可复用的 reducer 来处理一些通用任务,如数据加载,分页等等。

function visibilityFilter(state = 'SHOW_ALL',action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [],action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,{
          text: action.text,completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo,index) => {
        if (index === action.index) {
          return Object.assign({},todo,{
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers,createStore } from 'redux';

let reducer = combineReducers({ visibilityFilter,todos });
let store = createStore(reducer);

总结

通过上面三个原则的理解学习,我们知道。想要开发一个设计良好的React应用,需要对业务逻辑又一个良好的感知与理解,这样便于在项目初期就构建好 object tree, 明确数据流向。有效的划分每一个 state , action,reducer。达到事半功倍的作用。

相关文章

react 中的高阶组件主要是对于 hooks 之前的类组件来说的,如...
我们上一节了解了组件的更新机制,但是只是停留在表层上,例...
我们上一节了解了 react 的虚拟 dom 的格式,如何把虚拟 dom...
react 本身提供了克隆组件的方法,但是平时开发中可能很少使...
mobx 是一个简单可扩展的状态管理库,中文官网链接。小编在接...
我们在平常的开发中不可避免的会有很多列表渲染逻辑,在 pc ...