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

68747470733a2f2f7777772e726f62696e776965727563682e64652f696d672f706f7374732f746970732d746f2d6c6561726e2d72656163742d72656475782f62616e6e65722e6a7067对于学习 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 都放在专门的文件夹维护的方案,并不是所有人都能赞同。

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

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

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

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

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

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

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

好了,这样外部的其他模块就可以这样在他的 index.js 文件中调用 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 都加上一个前缀,比如这样:

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

尽可能让 state tree 扁平化

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

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

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

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

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

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

单一数据源原则

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

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

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

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

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

Selectors

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

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

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

  • Selectors 可以推导出衍生数据,并传递所需数据的最小集,不用一次把所有数据都给组件,解决性能问题
  • Selectors是可组合的,它可以作为其他 Selectors 的输入
  • Reselect所提供的 selector 是非常高效,除非它的参数改变了,否则 selector 不会重新计算,这在复杂应用中对性能提升是非常有帮助的。

不断的重构

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

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

Generators, Sagas, Observables, Epics, …

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

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

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

多阅读一下 Redux 的实现源码

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

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

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

编后语

本篇内容完结,更多内容请前往在 2017 年学习 React + Redux 的一些建议(下篇)

如果你想系统学习 React + Redux 技术栈的所有内容,请点我前往

2 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部