React + Redux 最佳实践
sorrycc opened this issue · comments
更新：我们基于此最佳实践做了一个封装方案：dva，可以简化使用 redux 和 redux-saga 时很多繁杂的操作。
前端变化虽快，但其实一直都围绕这几个概念在转：
- URL - 访问什么页面
- Data - 显示什么信息
- View - 页面长成什么样
- Action - 对页面做了什么操作
- API Server - Data 数据的来源
在 redux 的生态圈内，每个环节有多种方案，比如 Data 可以是 immutable 或者 plain object，在你选了 immutable 之后，用 immutable.js 还是 seamless-immutable，以及是否用 redux-immutable 来辅助数据修改，都需要选择。
本文总结目前 react + redux 的最佳实践，解释原因，并提供可选方案。
心急的朋友可以直接看代码：https://github.com/sorrycc/github-stars
一、URL > Data
需求
routing
选择
react-router + react-router-redux: 前者是业界标准，后者可以同步 route 信息到 state，这样你可以在 view 根据 route 信息调整展现，以及通过 action 来修改 route 。
可选
无
二、Data
需求
为 redux 提供数据源，修改容易。
方案
plain object: 配合 combineReducer 已经可以满足需求。
同时在组织 Store 的时候，层次不要太深，尽量保持在 2 - 3 层。如果层次深，可以考虑用 updeep 来辅助修改数据。
可选
immutable.js: 通过自定义的 api 来操作数据，需要额外的学习成本。不熟悉 immutable.js 的可以先尝试用 seamless-immutable，JavaScript 原生接口，无学习门槛。
另外，不推荐用 redux-immutable 以及 redux-immutablejs，一是没啥必要，具体看他们的实现就知道了，都比较简单；更重要的是他们都改写了 combineReducer，会带来潜在的一些兼容问题。
三、Data > View
需求
数据的过滤和筛选。
方案
reselect: store 的 select 方案，用于提取数据的筛选逻辑，让 Component 保持简单。选 reselct 看重的是 可组合特性 和 缓存机制 。
可选
无
四、View 之 CSS 方案
需求
合理的 CSS 方案，考虑团队协作。
方案
css-modules: 配合 webpack 的 css-loader 进行打包，会为所有的 class name 和 animation name 加 local scope，避免潜在冲突。
直接看代码：
Header.jsx
import style from './Header.less';
export default () => <div className={style.normal} />;Header.less
.normal { color: red; }编译后，文件中的 style.normal 和 .normal 在会被重命名为类似 Header__normal___VI1de 。
可选
bem, rscss ，这两个都是基于约定的方案。但基于约定会带来额外的学习成本和不遍，比如 rscss 要求所有的 Component 都是两个词的连接，比如 Header 就必须换成类似 HeaderBox 这样。
radium，inline css 方案，没研究。
五、Action <> Store，业务逻辑处理
需求
统一处理业务逻辑，尤其是异步的处理。
方案
redux-saga: 用于管理 action，处理异步逻辑。可测试、可 mock、声明式的指令。
可选
redux-loop: 适用于相对简单点的场景，可以组合异步和同步的 action 。但他有个问题是改写了 combineReducer，会导致一些意想不到的兼容问题，比如我在特定场景下用不了 redux-devtool 。
redux-thunk, redux-promise 等: 相对原始的异步方案，适用于更简单的场景。在 action 需要组合、取消等操作时，会不好处理。
saga 入门
在 saga 之前，你可能会在 action creator 里处理业务逻辑，虽然能跑通，但是难以测试。比如：
// action creator with thunking
function createRequest () {
return (dispatch, getState) => {
dispatch({ type: 'REQUEST_STUFF' });
someApiCall(function(response) {
// some processing
dispatch({ type: 'RECEIVE_STUFF' });
});
};
}然后组件里可能这样：
function onHandlePress () {
this.props.dispatch({ type: 'SHOW_WAITING_MODAL' });
this.props.dispatch(createRequest());
}这样通过 redux state 和 reducer 把所有的事情串联到起来。
但问题是：
Code is everywhere.
通过 saga，你只需要触发一个 action 。
function onHandlePress () {
// createRequest 触发 action `BEGIN_REQUEST`
this.props.dispatch(createRequest());
}然后所有后续的操作都通过 saga 来管理。
function *hello() {
// 等待 action `BEGIN_REQUEST`
yield take('BEGIN_REQUEST');
// dispatch action `SHOW_WAITING_MODAL`
yield put({ type: 'SHOW_WAITING_MODAL' });
// 发布异步请求
const response = yield call(myApiFunctionThatWrapsFetch);
// dispatch action `PRELOAD_IMAGES`, 附上 response 信息
yield put({ type: 'PRELOAD_IMAGES', response.images });
// dispatch action `HIDE_WAITING_MODAL`
yield put({ type: 'HIDE_WAITING_MODAL' });
}可以看出，调整之后的代码有几个优点：
- 所有业务代码都存于 saga 中，不再散落在各处
- 全同步执行，就算逻辑再复杂，看起来也不会乱
六、Data <> API Server
需求
异步请求。
方案
isomorphic-fetch: 便于在同构应用中使用，另外同时要写 node 和 web 的同学可以用一个库，学一套 api 。
然后通过 async + await 组织代码。
示例代码：
import fetch from 'isomorphic-fetch';
export async function fetchUser(uid) {
return await fetch(`/users/${uid}`).then(res => res.json());
};可选
最终
（完）
updeep 也说了，对于大数据量效率没有 immutable.js 高效，不如推荐 immutable.js
saga这个词是cqrs来的，是用来监听多个事件，同步事件的，比如创建订单会锁定库存，创建订单对象，当锁定库存和创建订单对象都成功时会处理的方法，所有的action都放里面感觉不是很合适
虽然没用过react，但看看前边说围绕着几个概念在转比较赞同，开发思维感觉又清晰了点
Nice introduction!
赞，急需
saga 的用途在这个例子里面没有讲清楚。
function createRequest () {
return (dispatch, getState) => {
dispatch({ type: 'REQUEST_STUFF' });
someApiCall(function(response) {
// some processing
dispatch({ type: 'RECEIVE_STUFF' });
});
};
}这段代码和下面 saga 的代码区别只是 dispatch 变成了 put。someApiCall 变成了 generator 。
saga 的作用最主要还是解决复杂的异步交互情况，特别是竞争状态。参见 http://stackoverflow.com/questions/34930735/pros-cons-of-using-redux-saga-with-es6-generators-vs-redux-thunk-with-es7-async/34933395 saga 作者自己的回答。不过感觉对我们目前的业务来说 overkill 了。
saga 是通用方案，不管是简单还是复杂，有些业务看起来简单，但说不定有一个点的异步逻辑比较复杂呢。竞争状态是其中的一个场景，我觉得他最重要的点是可以统一管理业务代码，并且只需要接收一个 action 来触发。
👍
看着 saga 就觉得好熟悉。
上面例子，saga 在前端用，使用 generator 似乎区别只是异步改为同步写法而已。
generator 最大的问题，如果是高级浏览器还好，要兼容低版本的浏览器，需要一堆转换代码，感觉不是很好。在我们的业务中，异步请求是很小的一部分操作，如果后台是自己控制，页面中的数据，基本上一次请求就都拿过来了。同样，可以在前端操作页面，最终完成后，进行一次提交，完成所有的修改。这种情况下，异步操作，用最简单的 thunk 就够了。
看成了 Soga 😄
赞，正在学习~
赞！
saga, 一开始还以为是日文， 这前台的概念真是越来越多了...
👍，正在学习
好文！
前人栽树后人乘凉，很棒，公司内部项目准备就这么玩
@oConnerCooper 推荐用 dva 搭建 react 项目，是基于这套最佳实践的封装。 #8
dva中saga的takeLatest可以在哪里设置？
多个应用整合的场景不知道大家有没有考虑过，有没有一些好的实践方式？
比如，后台管理类系统，非常庞大，是由N多个业务领域相对独立的管理系统组成的。
虽然应用开发与部署相对独立，但是我们肯定希望对于用户来讲，能提供较为统一的体验：将各个系统整合起来，提供统一的导航、菜单、页面布局等等。
以往传统的开发形式，可能有 iframe、后端渲染 import 等等方法。
但在 React 这种 SPA 的应用中，不知道有啥好的处理方式。尤其是公共的部分，是可能会包含业务逻辑，不是纯粹的“展示组件”。
即使，在不考虑与老系统的兼容情况下，只是多个React 的 SPA 整合，路由的处理之类的也还没想到很顺畅的方法。
我说的这种场景，有点类似于阿里云的管理控制台（从使用上来看，觉得相似）。阿里的管理控制台应该是 angularjs 实现。其细节不太清楚。
@clarkhan 我们是把公共部分提取成 npm 包。
@clarkhan
这个问题可以参考Elm的架构，如果每个公共组件都分别提供reducer/action/view/model，使用者将这些碎片自由组合的话就没什么问题，elm中ajax是在Reducer中触发的，所以ajax也可以复用。这种程度的复用即使是redux-saga也做不到(因为依赖顶层的middleware)
但是，个人认为这种针对副作用的复用是非常非常极端的情况，比如ajax，即使组件拆成了对全局无依赖的碎片，ajax本身通常也会依赖到全局的token
@sorrycc 我的意思是，即使是elm也很难较好地处理这类情况
elm分形的基础是组件没有对全局的依赖。而事实上涉及到副作用，对全局的依赖(比如token)是不可避免的。
全局依赖基于约定? 比如 token 就约定从 cookie 里获取。
@sorrycc 工程上可以这么做，有异步行为的通常是针对一定业务领域的复用了，使用范围有限定的话加这些约定没啥问题。
但从架构的角度这种约定其实还是比较弱的，这也是我对elm架构的一个concern，所谓的完全分形在实际场景下是受限制的。
还有个concern是leaf节点问题，同样的问题cycle.js也有，虽然他们宣称是分形架构，但最终的叶子节点(比如一个div)还是基于属性 + 事件、不可分形的。
这种差异会带来分形的边界问题，比如cycle的作者最近就支持Web Component，因为基于某个架构创建组件的成本更高、通用性更低(只能适配一个架构)，而基于WC的组件大家都可以用。理论上答案可以概括为"无业务的通用组件做成WC，有业务的按项目架构来"，实际工程中这个边界的把握就完全看团队水平了。
不过上面这个concern是针对elm/cycle类强制分形流的，react/redux本来就不用管这个
好文，学习
redux-saga 的替代方案：redux-observable。
原因：
- 同样解决了异步 action 处理。
- 其实是利用了 rxjs 对数据流处理的优势，解决了交互产生的数据流复杂处理的痛点，顺便解决了异步问题。
劣势：
- star 比 redux-saga 少，因为推出的晚，加上 rxjs 的学习成本，可能不会成为主流，但不代表不好用。
关于 redux-saga
可以看出，调整之后的代码有几个优点：
所有业务代码都存于 saga 中，不再散落在各处
全同步执行，就算逻辑再复杂，看起来也不会乱
全同步执行
- 首先 callback hell 是不好的, 然后不一定要用 generator 啊, async/await/promise 方案也不错
看下 redux thunk 的新版介绍
Any return value from the inner function will be available as the return value of dispatch itself. This is convenient for orchestrating an asynchronous control flow with thunk action creators dispatching each other and returning Promises to wait for each other’s completion:
就是说一个 action creator 返回一个 async function 的话, dispatch 这个 async function 的返回值是一个 Promise, 又可以 await 了
拿 redux-saga readme 例子来说 https://redux-saga.github.io/redux-saga/index.html
export function USER_FETCH_REQUESTED(){
return async (dispatch, getState) => {
try{
const user = await Api.fetchUser(action.payload.userId)
} catch(e) {
dispatch({type: "USER_FETCH_FAILED", message: e.message})
return
}
dispatch({type: "USER_FETCH_SUCCEEDED", user: user})
}
}
// 然后在 View里
diapatch(USER_FETCH_REQUESTED())所有业务代码都存于 saga 中
redux-thunk + promise 这个业务也都在 action creator 中, 而且显式的 dispatch 一个 thunk, 比 redux-saga 使用 takeEvery/takeLatest 将一个操作与 action type 关联的做法要好, 俨然一个黑箱. 如果是引用的话编辑器或IDE可以直接点击跳过去
redux-saga takeEvery / takeLatest / 数据相关的可能比较好用...但文中这两点不那么有力...
对于公司项目, 我还是倾向简单一些, 有时候入口 action creator 都不写了, 直接写在 event handler 里
btw Vuex 的 action 也是可以使用 async/await. 方便多了
赞
云谦师兄我现在也在阿里的技术栈中 在使用dva 但是现在遇到很多不懂得问题 想请教你
您好，我在使用dva roadhog，现在每次build都是index.css index.js 请问怎么能自动加上版本号 比如 index323232.css index232323.js 谢谢。
@albafica2015 还不支持，请关注这个 issue，sorrycc/roadhog#69
@albafica2015 html 需要通过 htmlwebpackplugin 生成，现在是直接 copy 的。
云谦师兄 dva的**不好懂啊
我想问一下，如果我的项目有一千多个页面，那么我该以什么粒度去区分modal？我觉得modal以route页面来区分，可能开发过程modal会拆分的比较好，但是在redux的store下面会存一千多个平级的state；而如果以一类相似对route页面来区分，大概有两百多个modal，感觉这样的话每一个modal会略复杂，多个route共用一个modal。
@sunopar 我觉得平级state不是问题，本身你这些页面之间没什么关系的话，最好是分开。如果要做一定程度的复用，可以从业务实体的角度出发，但最好还是跟state隔离开
请问考虑过mobxjs吗
搞c++的路过，原来我不会看代码。。。。
@xiemeilong 我用 MobX 实现了一套 https://github.com/djyde/cans
大神，借宝地一用。
想请教一下：在项目中使用了redux,知道智能组件和展示组件的区别。可不可以在智能组件中使用react原始的this.state来控制自身内容展示和隐藏。即操作this.setState()的方法。
我觉得按route拆model(modal一般指模态窗吧？)是对的，elm的状态树本身就是随着组件树组合的，根结点自然就是route。redux里需要预定义state tree才引申出了怎么拆的问题。
按这个思路平级state是【不必要】存在的，每个页面都单独初始化store就行了，单独拥有自己的root reducer，这也更接近redux的模仿对象——elm的做法
至于复用，创建reducer所需要的函数本来就是可复用的，创建的过程也可以进行抽象，所以页面间逻辑复用不会有问题。
跨页面之间数据共享的需求，不应该走redux store，而应该由localstorage/api等手段来解决，因为store是存在内存中的，一刷新就没了。严格区分页面的external resource我认为是更好的实践
请问dva 与mobx 区别有什么？
thumbup
为啥ajax库不选择superagent?
各位大佬：有几个疑问。
- state 和 props 都能触发 render，这两者如何选择？
- 接口请求，封装到 action 还是单独页面，单独请求？
- props 传递的层级一般控制在几层比较合适
- 看你的 state 需不需要共享了，如果要共享，状态提升肯定涉及到 props 传递，子组件就是根据 props 触发 re-render。选择肯定是看场景啊，简单的 ui 组件，自己有个 state 就够了。业务中大部分都是 smart + dumb 组件，props 多一些，尤其是引入 antd 等 ui 库。
- 如果这个页面所在的项目，有 redux 这样的状态管理，那数据流交给 redux 处理比较好一些，项目内一般有封装好的 fetch，saga 等方法，把 effects -> reducer -> store 。不过这个数据可能不是共享的，放 redux 唯一的 store 不太好。用 mobx 的话就容易解决这个问题了，起码比 state 好，我最不喜欢用 state 去处理 effects ，保存接口数据了。
- 两层。毕竟现在都是 smart + dumb，只要 store，组件拆分的好。
奥，忘了说 dva 也可以很好的解决你的问题 😆
项目要使用Dva...前来学习... 🐤
😢 dva generate is disabled since we don't have enough time currently.
各位大神们，看看下面两张图给点意见呗~~
- 参照MVC，设计的。
2.一个详细一点的数据流动图
下面这篇文章是有关react项目重构的思考
请教一下data部分如果使用了normalizr，应该如何于immutable配合呢？谢谢
不要用 normalizr 了，用 dva + dva-immer 就好。
根据上面的流程图，view 是 通过 action 改变 data。然后data再渲染 view。
那么页面的 未加载/加载中/加载完成/请求失败 等状态放在哪里呢？
如果是使用 saga ,页面调用 action 后，除非外部传入，是不知道请求状态的。
上面例子，saga 在前端用，使用 generator 似乎区别只是异步改为同步写法而已。
generator 最大的问题，如果是高级浏览器还好，要兼容低版本的浏览器，需要一堆转换代码，感觉不是很好。在我们的业务中，异步请求是很小的一部分操作，如果后台是自己控制，页面中的数据，基本上一次请求就都拿过来了。同样，可以在前端操作页面，最终完成后，进行一次提交，完成所有的修改。这种情况下，异步操作，用最简单的 thunk 就够了。
我觉得saga文档中login flow的例子就很好。相当于实现了简易的有限状态机来处理logIn和loginOut flow。可以少很多validation。比如在触发loginOut的时候，不必检查是否loginIn了，因为只有loginIn之后才能触发loginOut。应用中这种类似的状态转换其实挺常见的。
最后的图结构很清晰了！
这两张图太赞了！
