react-redux实践总结

时间 2019-11-21

标签 react redux 实践总结栏目 React 繁體版

原文原文链接

标题

做者：赵玮龙前后就任于面包旅行，阿里体育，如今就任于美团。涉及技术范围React, AngularJS, gulp, grunt, webpack, redux, canvas, node等，如今专一于前端react周边技术栈研究javascript

特此声明:本篇文章都是围绕react技术栈展开的若是你要跟我辩解是React,Vue,AngularJS之间区别，网络上文章数不胜数，能够移步别处.我假设你已经对react,redux有一些实战经验，基本的东西不会涉及

文章专著于如何尽可能作到react-redux最佳实践前端

redux的必要性:

Eric在Medium上发文喷setState

这件事情很早就引发热议

其实无非就是setState的对于新手不友好以及文档的晦涩致使的

React抽象来讲，就是一个公式

UI=f(state)

咱们把最终绘制出来的UI当作一个函数f运行的结果，f就是React和咱们基于React写得代码，而f的输入参数就是state。

做为React管理state的一个重要方法，setState确定很是重要，若是只是简单用法，也不会有任何问题，可是若是用得深，就会发现很……尴尬。

我刚开始接触React的时候，就意识到React至关于一个jQuery的替代品，可是就像单独依靠jQuery难以管理大型项目，因此也须要给配合使用的MVC框架找一个替代品，我选择的替代品是Redux，我很早就将React和Redux配合使用；如今，回过头来看看React的setState，发现坑真的很多，不由感叹本身仍是挺走运的。

对setState用得深了，就容易犯错，因此咱们开门见山先把理解setState的关键点列出来。

setState不会马上改变React组件中state的值；
setState经过引起一次组件的更新过程来引起从新绘制；
屡次setState函数调用产生的效果会合并。
这几个关键点实际上是相互关联的

setState不会马上改变React组件中state的值(他是异步触发的，也就是考虑到列队处理的必要性)

在React中，一个组件中要读取当前状态用是访问this.state，可是更新状态倒是用this.setState

若是须要同步咱们仍是更须要

函数式的setState用法

若是传递给this.setState的参数不是一个对象而是一个函数，那游戏规则就变了。

这个函数会接收到两个参数，第一个是当前的state值，第二个是当前的props，这个函数应该返回一个对象，这个对象表明想要对this.state的更改，换句话说，以前你想给this.setState传递什么对象参数，在这种函数里就返回什么对象，不过，计算这个对象的方法有些改变，再也不依赖于this.state，而是依赖于输入参数state。

能够这么写一个函数。

function increment(state, props) {
  return {count: state.count + 1};
}复制代码

能够看到，一样是把状态中的count加1，可是状态的来源不是this.state，而是输入参数state。

对应incrementMultiple的函数就是这么写。

function incrementMultiple() {
  this.setState(increment);
  this.setState(increment);
  this.setState(increment);
}复制代码

对于屡次调用函数式setState的状况，React会保证调用每次increment时，state都已经合并了以前的状态修改结果。

简单说，加入当前this.state.count的值是0，第一次调用this.setState(increment)，传给increment的state参数是0，第二调用时，state参数是1，第三次调用是，参数是2，最终incrementMultiple的效果，真的就是让this.state.count变成了3，这个函数incrementMultiple终于实至名归。

值得一提的是，在increment函数被调用时，this.state并无被改变，依然，要等到render函数被从新执行时（或者shouldComponentUpdate函数返回false以后）才被改变。

让setState接受一个函数的API设计很棒！由于这符合函数式编程的思想，让开发者写出没有反作用的函数，咱们的increment函数并不去修改组件状态，只是把“但愿的状态改变”返回给React，维护状态这些苦力活彻底交给React去作。

正由于流程的控制权交给了React，因此React才能协调多个setState调用的关系。

让咱们再往前推动一步，试着若是把两种setState的用法混用，那会有什么效果？

咱们把incrementMultiple改为这样。

function incrementMultiple() {
  this.setState(increment);
  this.setState(increment);
  this.setState({count: this.state.count + 1});
  this.setState(increment);
}复制代码

在几个函数式setState调用中插入一个传统式setState调用（嗯，咱们姑且这么称呼之前的setState使用方式），最后获得的结果是让this.state.count增长了2，而不是增长4。

缘由也很简单，由于React会依次合并全部setState产生的效果，虽然前两个函数式setState调用产生的效果是count加2，可是半路杀出一个传统式setState调用，一会儿强行把积攒的效果清空，用count加1取代。

这么看来，传统式setState的存在，会把函数式setState拖下水啊！只要有一个传统式的setState调用，就把其余函数式setState调用给害了。

若是说setState这儿API未来如何改进，也许就该彻底采用函数为参数的调用方法，废止对象为参数的调用方法。

固然，React近期确定不会有这样的惊世骇俗的改变，可是你们能够先尝试函数式setState用法，这才是setState的将来。

固然这还不是问题所在这里

关注react的人都知道，facebook提出的flux单向数据流控制，业界也出现了不少相似的flux数据流实现方式

他们其实起到的做用无非是如何去在全局状态下再也不让你的组建分而治之，而是具备统一管理state的能力

如今业界比较火的是Mobx和Redux

先对比下两个库的实现方式:

那么具体到这两种模型，又有一些特定的优缺点呈现出来

先谈谈 Redux 的优点：

数据流流动很天然，由于任何 dispatch 都会致使广播，须要依据对象引用是否变化来控制更新粒度。
若是充分利用时间回溯的特征，能够加强业务的可预测性与错误定位能力。
时间回溯代价很高，由于每次都要更新引用，除非增长代码复杂度，或使用 immutable。
时间回溯的另外一个代价是 action 与 reducer 彻底脱节，数据流过程须要自行脑补。缘由是可回溯必然不能保证引用关系。
引入中间件，其实主要为了解决异步带来的反作用，业务逻辑或多或少参杂着 magic。
可是灵活利用中间件，能够经过约定完成许多复杂的工做。
对 typescript 支持困难。

Mobx：

数据流流动不天然，只有用到的数据才会引起绑定，局部精确更新，但免去了粒度控制烦恼。
没有时间回溯能力，由于数据只有一份引用。
自始至终一份引用，不须要 immutable，也没有复制对象的额外开销。
没有这样的烦恼，数据流动由函数调用一鼓作气，便于调试。
业务开发不是脑力活，而是体力活，少一些 magic，多一些效率。
因为没有 magic，因此没有中间件机制，无法经过 magic 加快工做效率（这里 magic 是指 action 分发到 reducer 的过程）。
完美支持 typescript。

如何来确认这两个库的适用场景，实际中若是你的数据结构足够复杂那么仍是redux带来的灵活性以及数据管理模式更加天然，

mobx上手会更快，若是数据结构通常则比较建议这种方式

那么当咱们确认redux符合复杂业务场景后(后台业务通常都是复杂业务场景的必发处)

如何善于利用redux为咱们带来更好的开发体验和可维护性高的代码是此次探讨的重点

大致上，Redux 的数据流是这样的：

界面 => action => reducer => store => react => virtual dom => 界面

每一步都很纯净，看起来很美好对吧？对于一些小小的尝试性质的 DEMO #### 来讲确实很美好。但其实当应用变得愈来愈大的时候，这其中存在诸多问题：

如何优雅地写异步代码？（从简单的数据请求到复杂的异步逻辑）

状态树的结构应该怎么设计？

状态树中的状态愈来愈多，结构愈来愈复杂的时候，和 react #### 的组件映射如何避免混乱？

每次状态的细微变化都会生成全新的 state #### 对象，其中大部分无变化的数据是不用从新克隆的，这里如何提升性能？

如何拆分reducer？

state如何解耦选择数据分片呢?

我只能从业务中一一示范，固然并非上面的问题都解决了，并且以一个更好的方式解决了，这里只作到抛砖引玉的做用

官方文档里介绍了一种很朴素的异步控制中间件 redux-thunk（若是你还不了解中间件的话请看 Middleware | Redux 中文文档，事实上 redux-thunk 的代码很简单，简单到只有几行代码：

function createThunkMiddleware(extraArgument) {
    return ({ dispatch, getState }) => next => action => {
        if (typeof action === 'function') {
            return action(dispatch, getState, extraArgument);
        }
        return next(action);
    };
}

//普通action
function foo(){
    return {
        type: 'foo',
        data: 123
    }
}

//异步action
function fooAsync(){
    return dispatch => {
        setTimeout(_ => dispatch(123), 3000);
    }
}复制代码

但这种简单的异步解决方法在应用变得复杂的时候，并不能知足需求，反而会使 action 变得十分混乱。

举个简单的例子

用普通的 redux-thunk 是这样写的：

function upload(data){
    return dispatch => {
        // view
        dispatch({ type: 'SHOW_WAITING_MODAL' });
        // upload
        api.upload(data)
            .then(res => {
            // 成功
            dispatch({ type: 'PRELOAD_IMAGES', data: res.images });
            dispatch({ type: 'HIDE_WAITING_MODAL' });
            })
        .catch(err => {
            // 错误
            dispatch({ type: 'SHOW_ERROR', data: err });
            dispatch({ type: 'HIDE_WAITING_MODAL' });
            setTimeout(_ => dispatch({ type: 'HIDE_ERROR' }), 2000);
        })
    }
}复制代码

这里的问题在于，一个异步的 upload action 执行过程当中会产生好几个新的 action，更可怕的是这些新的 action 也是包含逻辑的（好比要判断是否错误），这直接致使异步代码中处处都是 dispatch(action)，是很不可控的状况。若是还要进一步考虑取消、超时、队列的状况，就更加混乱了。

下面咱们来看看若是换成 redux-saga 的话会怎么样：

import { take, put, call, delay } from 'redux-saga/effects'
// 上传的异步流
function *uploadFlow(action) {
    // 显示出加载效果
      yield put({ type: 'SHOW_WAITING_MODAL' });
      // 简单的 try-catch
      try{
          const response = yield call(api.upload, action.data);
        yield put({ type: 'PRELOAD_IMAGES', data: response.images });
        yield put({ type: 'HIDE_WAITING_MODAL' });
      }catch(err){
          yield put({ type: 'SHOW_ERROR', data: err });
        yield put({ type: 'HIDE_WAITING_MODAL' });
        yield delay(2000);
          yield put({ type: 'HIDE_ERROR' });
      }     
}

function* watchUpload() {
  yield* takeEvery('BEGIN_REQUEST', uploadFlow)
}复制代码

是否是规整不少呢？redux-saga 容许咱们使用简单的 try-catch 来进行错误处理，更神奇的是居然能够直接使用 delay 来替代 setTimeout 这种会形成回调和嵌套的不优雅的方法。

本质上讲，redux-sage 提供了一系列的『反作用（side-effects）方法』，好比如下几个

put（产生一个 action）
call（阻塞地调用一个函数）
fork（非阻塞地调用一个函数）
take（监听且只监听一次 action）
delay（延迟）
race（只处理最早完成的任务）

而且经过 Generator 实现对于这些反作用的管理，让咱们能够用同步的逻辑写一个逻辑复杂的异步流。

下面这个例子出自于官方文档，实现了一个对于请求的队列，即让程序同一时刻只会进行一个请求，其它请求则排队等待，直到前一个请求结束：

import { buffers } from 'redux-saga';
import { take, actionChannel, call, ... } from 'redux-saga/effects';

function* watchRequests() {
  // 1- 建立一个针对请求事件的 channel
  const requestChan = yield actionChannel('REQUEST');
  while (true) {
    // 2- 从 channel 中拿出一个事件
    const {payload} = yield take(requestChan);
    // 3- 注意这里咱们使用的是阻塞的函数调用
    yield call(handleRequest, payload);
  }
}复制代码

可是我在项目中并无适用redux-saga一个是由于会增长组员的学习成本，一个是代码迭代过快形成的落差

因此我在代码中把请求异步处理封装成一个简单的只有开始，成功，和错误处理的机制

import 'whatwg-fetch'
import handleError from './handleError'

// 设定一个symbol类型作为惟一的属性名
export const CALL_API = Symbol('call_api')

const API_HOST = process.env.API_HOST || 'http://localhost:8080/pc'

export default store => next => action => {
  const callApi = action[CALL_API]
  if (typeof callApi === 'undefined') {
    return next(action)
  }

  // 获取action中参数
  let { endpoint,
        types: [requestType, successType, failureType],
        method,
        body,
        ...options
      } = callApi
  let finalBody = body

  if (method) {
    options.method = method.toUpperCase()
  }
  if (typeof body === 'function') {
    finalBody = body(store.getState())
  }
  if (finalBody) {
    options.body = JSON.stringify(finalBody)
    options.headers = { 'content-type': 'application/json', 'agent': 'pc' }
  } else {
    options.headers = { 'cache-control': 'no-cache', 'agent': 'pc' }
  }
  // 替换action标记方法
  const actionWith = data => {
    const finalAction = Object.assign({}, action, data)
    delete finalAction[CALL_API]
    return finalAction
  }

  next(actionWith({ type:requestType }))

  return fetch(`${API_HOST}${endpoint}`,{
    credentials: 'include',
    ...options,
  })
  .then(response => {
    if (response.status === 204) {
      return { response }
    }
    const type = response.headers.get('content-type')
    if (type && type.split(';')[0] === 'application/json') {
      return response.json().then(json => ({ json, response }))
    }
    return response.text().then(text => ({ text, response }))
  })
  .then(({ json, text, response }) => {
    if (response.ok) {
      if (json) {
        if (json.status === 200 && json.data) {
          next(actionWith({ type: successType, payload: json.data }))
        } else if (json.status === 500) {
          next(actionWith({ type: successType, payload: json.msg }))
        } else {
          next(actionWith({ type: successType }))
        }
      }
    } else {
      if (json) {
        let error = { status: response.status }
        if (typeof json === 'object') {
          error = { ...error, ...json }
        } else {
          error.msg = json
        }
        throw error
      }
      const error = {
        name: 'FETCH_ERROR',
        status: response.status,
        text,
      }
      throw error
    }
  })
  .catch((error) => {
    next(actionWith({ type: failureType, error }))
    handleError(error)
  })
}复制代码

咱们能够利用symbol定一个咱们须要处理的机制而后去处理每次返回的结果，只是用到了redux-thunk 做为一个thunk函数去返回有反作用的请求

结构状态state应该如何去设计呢?vue

咱们考虑到官方给出的建议用entities去维护咱们所须要的数据，由于业务中表单居多，而且表单复杂，

考虑到适用场景咱们会根据reducer的概念去讲解

reducer就是实现(state, action) => newState的纯函数，也就是真正处理state的地方。值得注意的是，Redux并不但愿你修改老的state，并且经过直接返回新state的方式去修改。

在讲如何设计reducer以前，先介绍几个术语：

reducer：实现(state, action) -> newState的纯函数，能够根据场景分为如下好几种

root reducer：根reducer，做为createStore的第一个参数
slice reducer：分片reducer，相对根reducer来讲的。用来操做state的一部分数据。多个分片reducer能够合并成一个根reducer
higher-order reducer：高阶reducer，接受reducer做为参数的函数/返回reducer做为返回值的函数。
case function：功能函数，接受指定action后的更新逻辑，能够是简单的reducer函数，也能够接受其余参数。

reducer的最佳实践主要分为如下几个部分

抽离工具函数，以便复用。
抽离功能函数（case function），精简reducer声明部分的代码。
根据数据类别拆分，维护多个独立的slice reducer。
合并slice reducer。
经过crossReducer在多个slice reducer中共享数据。
减小reducer的模板代码。

接下来，咱们详细的介绍每一个部分

如何抽离工具函数？

抽离工具函数，几乎在任何一个项目中都须要。要抽离的函数须要知足如下条件：

纯净，和业务逻辑不耦合
功能单一，一个函数只实现一个功能java

因为reducer都是对state的增删改查，因此会有较多的重复的基础逻辑，针对reducer来抽离工具函数，简直恰到好处。

// 好比对象更新，浅拷贝
export const updateObject = (oldObj, newObj) => {
    return assign({}, oldObj, newObj);
}
// 好比对象更新，深拷贝
export const deepUpdateObject = (oldObj, newObj) => {
    return deepAssign({}, oldObj, newObj);
}复制代码

工具函数抽离出来，建议放到单独的文件中保存。

如何抽离 case function 功能函数？

不要被什么case function吓到，直接给你看看代码你就清楚了，也是体力活，目的是为了让reducer的分支判断更清晰

// 抽离前，全部代码都揉到slice reducer中，不够清晰
function appreducer(state = initialState, action) {
    switch (action.type) {
        case 'ADD_TODO':
            ...
            ...
            return newState;
        case 'TOGGLE_TODO':
            ...
            ...
            return newState;
        default:
            return state;
    }
}

// 抽离后，将全部的state处理逻辑放到单独的函数中，reducer的逻辑格外清楚
function addTodo(state, action) {
    ...
    ...
    return newState;
}
function toggleTodo(state, action) {
    ...
    ...
    return newState;
}
function appreducer(state = initialState, action) {
    switch (action.type) {
        case 'ADD_TODO':
            return addTodo(state, action);
        case 'TOGGLE_TODO':
            return toggleTodo(state, action);
        default:
            return state;
    }
}复制代码

case function就是指定action的处理函数，是最小粒度的reducer。

抽离case function，可让slice reducer的代码保持结构上的精简。

#### 如何设计slice reducer？

咱们须要对state进行拆分处理，而后用对应的slice reducer去处理对应的数据，好比article相关的数据用articlesReducer去处理，paper相关的数据用papersReducer去处理。

这样能够保证数据之间解耦，而且让每一个slice reducer保持代码清晰而且相对独立。

好比业务中有shopInfo和bankInfol两个类别的数据，咱们拆分state并扁平化改造

export default (state = initialState, action) => {
  switch (action.type) {
    case allTypes.SHOPINFO_REQ:
      return {
        ...state,
        isloading: true,
      }
    case allTypes.SHOPINFO_SUCCESS:
      return {
        ...state,
        isloading: false,
        productId: action.payload.productId,
      }
    default:
      return state
}复制代码

注意一下这里的解构对于shopinfo来讲他并不感知到state的存在对于他来讲他就是shop

那么这里的select对于要渲染的组建来说是一个道理，咱们不敢知如何在组建中渲染，只是选择咱们这个分片中的数据

因为咱们的state进行了扁平化改造，因此咱们须要在case function中进行normalizr化。

根据state的拆分，设计出对应的slice reducer，让他们对本身的数据分别管理，这样后代码更便于维护，但也引出了两个问题。

拆分多个slice reducer，但createStore只能接受一个reducer做为参数，因此咱们怎么合并这些slice reducer呢？

每一个slice reducer只负责管理自身的数据，对state并不知情。那么shop怎么去改变state.entities的数据呢？

这两个问题，分别引出了两部份内容，分别是：slice reducer合并、slice reducer数据共享。

如何合并多个slice reducer？

redux提供了combineReducer方法，能够用来合并多个slice reducer，返回root reducer传递给createStore使用。直接上代码，很是简单。

combineReducers({
    entities: entitiesreducer,

    // 对于shopReducer来讲，他接受(state, action) => newState,
    // 其中的state，是shop，也就是state.shopinfo
    // 它并不能获取到state的数据，更不能获取到state.papers的数据
    shopinfo: shopinfoReducer,
    bankinfo: bankinfoReducer
})复制代码

传递给combineReducer的是key-value 键值对，其中键表示传递到对应reducer的数据，也就是说：slice reducer中的state并非全局state，而是state.articles/state.papers等数据。

结语

若是解决多个slice reducer间共享数据的问题？

slice reducer本质上是为了实现专门数据专门管理，让数据管理更清晰。那么slice reducer间如何共享数据呢？

如何在一个回传数据中拿到另外一个共享数据的的数据呢?透传给一个reducer吗?固然一点都不优雅。。。。预计下次再讲

最后，团队为了招聘方便，整了个公众号，主要是一些招聘信息，团队信息，全部的技术文章在公众号里也能够看到，对了，若是你想去美团其余团队，咱们也能够帮你内推哦 ~ node