作者:郭永峰,用友网络公共前端团队负责人
本次系列文章分为上中下三篇,《在 2017 年学习 React + Redux 的一些建议(上篇)》 和 《在 2017 年学习 React + Redux 的一些建议(下篇)》 可点击阅读。
原创文章,版权所有,转载请注明出处。
React 和 Redux 经常结合在一起使用,Redux 是 flux 架构模式的一种优秀实现,并且在 React 社区被广泛使用,但也不是完全和 React 耦合在一起的。
并不是所有的全局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 改变而导致的。
在 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
吗?没关系,在 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 或者其他前端框架,你总会不断的掌握更加高效的代码组织方式,或者是一些很好的设计模式。
如果你的应用中的组件非常的多,你可以找到一个更好的方式来分离和组织木偶组件和容器组件,你会发现他们之间的关系并做一些公共的抽取;如果你还没有使用合适的命名约束,你也可以在重构的时候去做这些事情。
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 的作者 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 的源码了,可以学习到很多有意思的编程思想和函数式的运用。
注:《在 2017 年学习 React + Redux 的一些建议(上篇)》
公众号
前端达人
长按识别左边二维码关注我