Redux进阶系列3:如何设计action、reducer、selector

前端之家收集整理的这篇文章主要介绍了Redux进阶系列3:如何设计action、reducer、selector前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

Redux进阶系列文章

1. React+Redux项目结构最佳实践
2. 如何合理地设计Redux的State

在前面两篇文章中,我们介绍了Redux项目结构的组织方式和如何设计State。本篇,我们将以前面两篇文章为基础,继续介绍如何设计action、reducer、selector。

依然以博客项目为例,我们在第2篇中最后设计的state结构如下:

{
  "app":{
    "isFetching": false,"error": "",},"posts":{
    "byId": {
      "1": {
        ...
      },...
    },"allIds": [1,...],} 
  "comments": {
    ...
  },"authors": {
    ...
  }
}

根据这个结构,我们很容易想到可以拆分成4个reducer分别处理app、posts、comments、authors这4个子state。子state相关的action和这个state对应的reducer放到一个文件中,作为一个state处理模块。注意:本文定义的action、reducer、selector并不涵盖真实博客应用中涉及的所有逻辑,仅列举部分逻辑,用以介绍如何设计action、reducer、selector。

state中的 app 管理应用状态,应用状态与领域状态不同,领域状态是应用用来显示、操作的数据,一般需要从服务器端获取,例如posts、comments、authors都属于领域状态;而应用状态是与应用行为或应用UI直接相关的状态,例如当前应用中是否正在进行网络请求,应用执行时的错误信息等。app 包含的应用状态有:isFetching(当前应用中是否正在进行网络请求)和error(应用执行时的错误信息)。对应的action可以定义为:

// 所在文件:app.js
//action types
export const types = {
  const START_FETCH  : 'app/START_FETCH',const FINISH_FETCH : 'app/FINISH_FETCH',const SET_ERROR : 'app/SET_ERROR'
}

//action creators
export const actions = {
  startFetch: () => {
    return {type: types.START_FETCH};
  },finishFetch: ()=> {
    return {type: types.FINISH_FETCH};
  },setError: (error)=> {
    return {type: types.SET_ERROR,payload: error};
  }
}

types定义了app模块使用的action types,每一个action type的值以模块名作为命名空间,以避免不同模块的action type冲突问题。actions定义了该模块使用到的action creators。我们没有直接导出每一个action type和action creator,而是把所有的action type封装到types常量,所有的action creators封装到actions常量,再导出types和actions这两个常量。这样做的好处是方便在其他模块中引用。(在第1篇中已经介绍过)
现在再来定义处理app的reducer:

// 所在文件:app.js

export const types = {
 //...
}

export const actions = {
 //...
}

const initialState = {
  isFetching: false,error: null,}

// reducer
export default function reducer(state = initialState,action) {
  switch (action.type) {
    types.START_FETCH: 
      return {...state,isFetching: true};
    types.FINISH_FETCH:
      return {...state,isFetching: false};
    types.SET_ERROR:
      return {...state,error: action.payload}
    default: return state;
  }
}

现在,app.js就构成了一个基本的处理state的模块。

我们再来看下如何设计posts.js。posts是这几个子状态中最复杂的状态,包含了posts领域数据的两种组织方式:byId定义了博客ID和博客的映射关系,allIds定义了博客在界面上的显示顺序。这个模块需要使用异步action调用服务器端API,获取博客数据。当网络请求开始和结束时,还需要使用app.js模块中的actions,用来更改app中的isFetching状态。代码如下所示:

// 所在文件:posts.js
import {actions as appActions} from './app.js'

//action types
export const types = {
  const SET_POSTS : 'posts/SET_POSTS',}

//action creators
export const actions = {
  // 异步action,需要redux-thunk支持
  getPosts: () => {
    return (dispatch) => {
      dispatch(appActions.startFetch());
      return fetch('http://xxx/posts')
        .then(response => response.json())
        .then(json => {
          dispatch(actions.setPosts(json));    
          dispatch(appActions.finishFetch());    
        });      
    }
  },setPosts: (posts)=> {
    return {type: types.SET_POSTS,payload: posts};
  }
}

// reducer
export default function reducer(state = [],action) {
  switch (action.type) {
    types.SET_POSTS:
      let byId = {};
      let allIds = [];
      /* 假设接口返回的博客数据格式为:
      [{
        "id": 1,"title": "Blog Title","create_time": "2017-01-10T23:07:43.248Z","author": {
          "id": 81,"name": "Mr Shelby"
        },"comments": [{id: 'c1',authorId: 81,content: 'Say something'}]
        "content": "Some really short blog content. "
      }] 
      */
      action.payload.each((item)=>{
        byId[item.id] = item;
        allIds.push(item.id);
      })
      return {...state,byId,allIds};
    default: return state;
  }
}

我们在一个reducer函数中处理了byId和allIds两个状态,当posts的业务逻辑较简单,需要处理的action也较少时,如上面的例子所示,这么做是没有问题的。但当posts的业务逻辑比较复杂,action类型较多,byId和allIds响应的action也不一致时,往往我们会拆分出两个reducer,分别处理byId和allIds。如下所示:

// 所在文件:posts.js
import { combineReducers } from 'redux'

//省略无关代码

// reducer
export default combineReducers({
  byId,allIds
})

const byId = (state = {},action) {
  switch (action.type) {
    types.SET_POSTS:
      let byId = {};
      action.payload.each((item)=>{
        byId[item.id] = item;
      })
      return {...state,byId};
    SOME_SEPCIAL_ACTION_FOR_BYID:
      //...
    default: return state;
  }
}

const allIds = (state = [],action) {
  switch (action.type) {
    types.SET_POSTS:
      return {...state,allIds: action.payload.map(item => item.id)};
    SOME_SEPCIAL_ACTION_FOR_ALLIDS:
      //...
    default: return state;
  }
}

从上面的例子中,我们可以发现,redux的combineReducers可以在任意层级的state上使用,而并非只能在第一级的state上使用(示例中的第一层级state是app、posts、comments、authors)

posts.js模块还有一个问题,就是byId中的每一个post对象,包含嵌套对象author。我们应该让post对象只应用博客作者的id即可:

// reducer
export default function reducer(state = [],action) {
  switch (action.type) {
    types.SET_POSTS:
      let byId = {};
      let allIds = [];
      action.payload.each((item)=>{
        byId[item.id] = {...item,author: item.author.id};
        allIds.push(item.id);
      })
      return {...state,allIds};
    default: return state;
  }
}

这样,posts只关联博客作者的id,博客作者的其他属性由专门的领域状态author来管理:

// 所在文件:authors.js
import { types as postTypes } from './post'

//action types
export const types = {
  
}

//action creators
export const actions = {
  
}

// reducer
export default function reducer(state = {},action){
  switch (action.type) {
    postTypes.SET_POSTS:
      let authors = {};
      action.payload.each((item)=>{
        authors[item.author.id] = item.author;
      })
      return authors;
    default: return state;
}

这里需要注意的是,authors的reducer也处理了posts模块中的SET_POSTS这个action type。这是没有任何问题的,一个action本身就是可以被多个state的reducer处理的,尤其是当多个state之间存在关联关系时,这种场景更为常见。

comments.js模块的实现思路类似,不再赘述。现在我们的redux(放置redux模块)目录结构如下:

redux/
  app.js
  posts.js 
  authors.js
  comments.js

在redux目录层级下,我们新建一个index.js文件,用于把各个模块的reducer合并成最终的根reducer。

// 文件名:index.js
import { combineReducers } from 'redux';
import app from './app';
import posts from './posts';
import authors from './authors';
import commments from './comments';

const rootReducer = combineReducers({
  app,posts,authors,commments
});

export default rootReducer;

action和reducer的设计到此基本完成,下面我们来看selector。Redux中,selector的“名声”不如action、reducer响亮,但selector其实非常有用。selector是用于从state中获取所需数据的函数,通常在connect的第一个参数 mapStateToProps中使用。例如,我们在AuthorContainer.js中根据作者id获取作者详情信息,不使用selector的话,可以这么写:

//文件名:AuthorContainer.js

//省略无关代码

function mapStateToProps(state,props) {
  return {
    author: state.authors[props.authorId],};
}

export default connect(mapStateToProps,mapDispatchToProps)(AuthorContainer);

这个例子中,因为逻辑很简单,直接获取author看起来没什么问题,但当获取状态的逻辑变得复杂时,需要通过一个函数获取,这个函数就是一个selector。selector是可以复用的,不同的容器组件,只要获取状态的逻辑相同,就可以复用同样的selector。所以,selector不能直接定义在某个容器组件中,而应该定义在其关联领域所在的模块中,这个例子需要定义在authors.js中。

//authors.js

//action types

//action creators

//reducer

// selectors
export function getAuthorById(state,id) {
  return state[id]
}

在AuthorContainer.js中使用selector:

//文件名:AuthorContainer.js
import { getAuthorById } from '../redux/authors';

//省略无关代码

function mapStateToProps(state,props) {
  return {
    author: getAuthorById(state.authors,props.authorId),};
}

export default connect(mapStateToProps)(AuthorContainer);

我们再来看一个复杂些的selector:获取一篇博客评论列表。获取评论列表数据,需要posts和comments两个领域的数据,所以这个selector并不适合放到comments.js模块中。当一个selector的计算参数依赖多个状态时,可以把这个selector放到index.js中,我们把index.js看做所有模块层级之上的一个根模块。

// index.js

// 省略无关代码

// selectors
export function getCommentsByPost(post,comments) {
  const commentIds = post.comments;
  return commentIds.map(id => comments[id]);
}

我们在第2篇 如何合理地设计Redux的State讲过,要像设计数据库一样设计state,selector就相当于查询表的sql语句,reducer相当于修改表的sql语句。所以,本篇的总结是:像写sql一样,设计和组织action、reducer、selector。

猜你在找的React相关文章