微信号:FrontDev

介绍:分享 Web 前端相关的技术文章、工具资源、精选课程、热点资讯

在 2017 年学习 React + Redux 的一些建议(中篇)

2017-09-14 20:30 前端大全

(点击上方公众号,可快速关注)


作者:郭永峰

github.com/iuap-design/blog/issues/179

如有好文章投稿,请点击 → 这里了解详情



对于学习 Redux 的一些建议


React 和 Redux 经常结合在一起使用,Redux 是 flux 架构模式的一种优秀实现,并且在 React 社区被广泛使用,但也不是完全和 React 耦合在一起的。


全局 state


并不是所有的全局state都需要被存储起来,一些组件可以使用 setState 来管理组件的内部状态,这也是为什么在学习 Redux 前要掌握 React 中的 setState ,否则你将习惯式的把所有的global state都存储在store里面。所以思考一下,在大型开发团队里面开发的复杂应用,你更不能将应用的所有 state 都切换成全局状态。


项目目录如何组织


这篇文章organizing-redux-application 给出了三种建议方式来组织项目结构。


第一种方式是按功能划分


React + Redux 的一些教程经常给我们展示按功能划分的目录,这也是一种很好的 React + Redux 学习方式,不过,将应用的所有 reducers 和 actions 都放在专门的文件夹维护的方案,并不是所有人都能赞同。


src/

--actions/

--reducers/

--components/


经常听到的有建设性的想法是,目录划分应该以组件为核心,每个目录应该有组件本身以及它所对应的 reducers、actions,那么一个示例的目录结构应该是这样的:


message/

--components

--reducer.js

--actions.js


一个包含 container component 、presenter component以及测试相关的详细的组件目录会是这样的:


message/

--components/

----messageItem/

------presenter.js

------spec.js

----messageList/

------container.js

------presenter.js

------spec.js

--reducer/

----index.js

----spec.js

--actions/

----index.js

----spec.js


当然了,也并不是大家都会喜欢这种方式。(其实,我个人是很赞同这样的就近维护组件的原则的,因为将各个功能性的reducer和action都丢到对应的目录,这以后维护起来会更加困难,文件也不好找,这可不像是MVC那样的分层结构。)尤其是将reducer隐藏在各个功能目录中,这也不利于全局性的来理解使用 redux 的架构意图。所以建议是适当的在最初就抽取一些 reducers 来共享他们所包含的功能。


但在现实场景中,尤其是多个团队在同一个应用项目中协作的时候,在开发进度的压力之下,并没有那么多机会来正确的抽象出一些 reducers。反而通常是一口气的封装所有的功能模块,只为了感觉把活给干完了,让需求按时上线。


第二种方式是对功能模块划分清晰的界限


给每个模块都设置一个 index.js 文件作为入口,这个文件只是用于导出一些API给其他的模块使用。在基于 React + Redux 的应用中,index.js 文件可以用于导出一个 container components ,或是一个presenter components、action creators、能用于其他地方的 reducer(但不是最终的reducer)。那么,基于这样的思考,我们的目录就可以变成这样了:


message/

--index.js

--components/

----messageItem/

------index.js

------presenter.js

------spec.js

----messageList/

------index.js

------container.js

------presenter.js

------spec.js

--reducer/

----index.js

----spec.js

--actions/

----index.js

----spec.js


那么,在当前功能模块下的 index.js 文件应该包含这些代码:


import MessageList from './messageList';

 

export default MessageList;

 

export MessageItem from './messageItem';

export reducer from './reducer';

export actions from './actions';


好了,这样外部的其他模块就可以这样在他的 index.js 文件中调用 message 模块了。


// bad

import { reducer } from ./message/reducer;

 

// good

import { reducer } from ./message;


收获:按功能模块以及清晰的界限可以帮助我们很好的组织代码和目录。


命名约定


在软件编程中命名可真是一件令人头疼的事情,这跟给孩子取名一样费劲,哈哈。合适的命名是实现可维护性、易于理解的代码的最好实践,React + Redux 的应用中提供了大量的约束来帮助我们组织代码,而且不会在命名上固执己见。无论你的函数封装在 reducer 还是 component 中,在action creator 或是 selector 中,你都应该有一个命名约束,并且在扩展应用之前就确定如何命名,否则经常会让我们陷入难以捉摸的回调和重构当中。


而我习惯为每个类型的函数都加上一个前缀。


  • 在组件的callback中,为每个函数都加上 on 作为前缀,比如 onCreateRplay

  • 在改变 state 的 reducer 中加上 applay 作为前缀,比如 applyCreateReply

  • 在 selector 中 加上 get 作为前缀,比如 getReply

  • 在 action creator 中加上 do 作为前缀,比如 doCreateReply


也许你不一定习惯这种加上前缀的方式,不过我还是推荐给你,同时也建议找到自己喜欢的命名约束规则。


追踪状态的改变


在持续迭代中的应用免不了定义大量的 action,而且还需要追溯 state 是如何改变的,redux-logger 可以帮助你看到所有的 state change。每条日志都会显示出 previous state、执行的 action、next state。


不过你得确保 actions 是可被设备的,因此我建议为不同类型的 action 都加上一个前缀,比如这样:


const MESSAGE_CREATE_REPLY = 'message/CREATE_REPLY';


这样的话,无论你在何时触发了信息回复这个动作,你都能看到 message/CREATE_REPLY 这一条日志,如果出现 state 异常,便能迅速查到是那条错误的 state 改变而导致的。


尽可能让 state tree 扁平化


在 Redux 中,扁平化的 state tree可以让你的 reducers 更加的简单,这样你就不需要在整个 store 的状态树中深层的查找到某个 state 后再将其修改,而是可以很轻松的就能实现。不过,在 Redux 中却不能做这么做,因为 state 是不可变的。


如果你正在开发一个博客应用,需要维护一个类似这样的列表对象,列表中包含 author 和 comment 字段:


{

  post: {

    author: {},

    comments: [],

  }

}


不过实际情况是每个对象都需要有对应的 id 来进行维护:


{

  post: {

    id: '1',

    author: {

      id: 'a',

      ...

    },

    comments: [

      {

        id: 'z',

        ...

      },

      ...

    ],

  }

}


这个时候,我们将数据序列化之后将会变得更有意义,数据解构变得更加扁平化了。序列化之后的数据通过 id 关联其他字段,之后,你就可以通过实体对象来将其报酬,通过 id 来进行关联数据的查找。


{

  posts: {

    1: {

      authorId: 'a',

      commentIds: ['z', ...]

    }

  },

  authors: {

    a: {

      ...

    }

  },

  comments: {

    z: {

      ...

    }

  },

}


这样,数据结构看起来就不在那么深层嵌套了,当你需要改变数据的时候,就可以轻松的实现数据的不可变性了。


normalizr 是个强大的 library,可以帮助我们进行数据格式化,噢耶~!


单一数据源原则


格式化之后的数据可以帮助你按同步的方式来管理 state ,而假如请求后端接口后返回的是深层嵌套的 blog 的 posts 数据结构呢,是不是欲哭无泪啊?! post 字段依然包含 author 和 comments字段,不过这次,comments 是一个数组,数组中的每个对象都有 author 字段:


{

  post: {

    author: { id: 'a' },

    comments: [

      {

        author: { id: 'b' },

        reply: {},

      },

      {

        author: { id: 'a' },

        reply: {},

      },

    ],

  }

}


我们可以看到数据结构中 author 字段在 post 和 comments 中都有维护,这就导致嵌套的数据结构中出现了两次,这就不是单一数据源,当你改变了author 字段的时候就会变得很困难了。


这个时候当你将数据格式化之后, author 这个字段就只有一个了。


{

  authors: {

    a: {},

    b: {},

  }

}


当你想 follow 一个 author 的时候,就可以轻松的更新一个字段了 — 数据源是单一的:


{

  authors: {

    a: { isFollowed: true },

    b: {},

  }

}


应用中所有依赖了 author 这个字段的地方都能得到更新。


Selectors


你还没使用 selectors 吗?没关系,在 redux 中依然可以通过 mapStateToProps 来计算 props:


function mapStateToProps(state) {

  return {

    isShown: state.list.length > 0,

  };

};


而如何你一旦使用了 selectors 之后的话,你就可以将这部分计算的工作放到 selectors,从而让 mapStateToProps 更加的简洁:


function mapStateToProps(state) {

  return {

    isShown: getIsShown(state),

  };

};


你可以使用 reselect 来帮助你完成这些事情,它可以帮助你从 state 中计算得到衍生的数据,并且让你的应用的性能得到提升:


  • Selectors 可以推导出衍生数据,并传递所需数据的最小集,不用一次把所有数据都给组件,解决性能问题

  • Selectors是可组合的,它可以作为其他 Selectors 的输入

  • Reselect所提供的 selector 是非常高效,除非它的参数改变了,否则 selector 不会重新计算,这在复杂应用中对性能提升是非常有帮助的。


不断的重构


随着时间得推移,你会想要重构你的代码,无论是你在应用中使用了 React 、React + Redux 或者其他前端框架,你总会不断的掌握更加高效的代码组织方式,或者是一些很好的设计模式。


如果你的应用中的组件非常的多,你可以找到一个更好的方式来分离和组织木偶组件和容器组件,你会发现他们之间的关系并做一些公共的抽取;如果你还没有使用合适的命名约束,你也可以在重构的时候去做这些事情。


Generators, Sagas, Observables, Epics, …


Redux 是一个非常优秀的 library,让我们可以体验不同的编程范式和技术。而大家又常常需要不构建不同的类库来实现 async action,这里有几种不同的方式来处理这些 side effects:


  • Redux Thunk – (Delayed) Functions

  • Redux Promise – Promises

  • Redux Saga – Generators

  • Redux Observable – Observables

  • Redux Loop – Elm Effects


新手的话建议使用 redux thunk 来处理一些异步操作;等你慢慢的熟悉整个生态及其相关的应用的时候,可以看看其他的相关类库。Redux Saga 是目前被广泛采用的一种实现方式。不过,Redux Observables 目前也被越来越多的人所接受,这可是需要掌握不少关于 rxjs 及其响应式编程的概念及其使用方式。


其实,整体看来,redux 生态圈的本身就产生了非常多的前端类库,真是让人应接不暇啊。但也别烦恼,那些你不需要用到的东西,自然也不需要都去掌握,对吧。


多阅读一下 Redux 的实现源码


Redux 本身的源码并不多,总共也才五六个关键文件,不超千行代码。如果你想对 Redux 更加熟悉,那么强烈建议你要抽些时间多分析一下他的源码。


在开始学习的时候,也推荐部分学习视频给你:


  • Redux 的作者 Dan Abramov 自己录制的入门级视频 《getting-started-with-redux》 ,大家都说录制的很棒,不过说实话,这个对理解实现原理是很有帮助的。javascript-redux-implementing-store-from-scratch 和 javascript-redux-implementing-combinereducers-from-scratch 两个视频可以帮助你理解 store 和 combineReducer 的实现原理。

  • 第二个系列的视频是《building-react-applications-with-idiomatic-redux》,你可以从中学习到如何实现你自己的 middleware 中间件,学完后就可以学习如何在 store 中使用它们。然后,你就能掌握到如何使用 applayMiddleware 将中间件应用到 store 中


这些视频内容不仅可以教你快速掌握如何使用 Redux,还可以让你理解 Redux 的实现原理。最后,你就可以啃一啃 Redux 的源码了,可以学习到很多有意思的编程思想和函数式的运用。



觉得本文对你有帮助?请分享给更多人

关注「前端大全」,提升前端技能

 
前端大全 更多文章 如何写出好的 JavaScript —— 浅谈 API 设计 在 2017 年学习 React + Redux 的一些建议(上篇) 为什么总有人黑 JavaScript 用 CSS3 制作导航条和毛玻璃效果 前端历史课:那些来自洪荒时代的编码知识
猜您喜欢 知识点归纳(2) 我的爸爸是个做云计算的 | \b内容涉及亲情、教育、民族、战争、环境等 java cpu高达100%问题 排查 博客虫资源分享系列三:Spark相关资源 netmap源码读后感