在 React 中处理数据流问题的一些思考

1、在 react 中处理数据流问题的一些思考背景 信任大家在项目开发中，在页面较复杂的状况下，往往会碰到一个问题，就是在页面组件之间通信会十分困难。 比如说一个商品列表和一个已添加商品列表： 如果这两个列表是自立的两个组件，它们会分享一个数据 被选中的商品，在商品列表选中一个商品，会影响已添加商品列表，在已添加列表中删除一个商品，同样会影响商品列表的选中状态。 它们两个是兄弟组件，在没有数据流框架的协助下，在组件内数据有变幻的时候，只能通过父组件传输数据，往往会有 onselecteddatachange 这种函数浮现，在这种状况下，还尚且能忍受，假如组件嵌套较深的话，那疼痛可以想象一下，所以才

2、有解决数据流的各种框架的浮现。 本质分析 我们知道 react 是 mvc 里的 v，并且是数据驱动视图的，容易来说，就是数据 => 视图，视图是基于数据的渲染结果： v = f(m) 数据有更新的时候，在进入渲染之前，会先生成 virtual dom，前后举行对照，有变幻才举行真正的渲染。 v + δv = f(m + δm) 数据驱动视图变幻有两种方式，一种是 setstate，转变页面的 state，一种是触发 props 的变幻。 我们知道数据是不会自己转变，那么绝对是有外力去推进，往往是远程哀求数据回归或者是 ui 上的交互行为，我们统称

3、这些行为叫 action： δm = perform(action) 每一个 action 都会去转变数据，那么视图得到的数据（state）就是全部 action 叠加起来的变更， state = actions.reduce(reducer, initstate) 所以真切的场景会浮现如下或更复杂的状况： 问题就出在，更新数据比较棘手，混乱，每次要更新数据，都要一层层传递，在页面交互复杂的状况下，无法对数据举行管控。 有没有一种方式，有个集中的地方去管理数据，集中处理数据的接收，修改和分发？答案明显是有的，数据流框架就是做这个事情，认识 redux 的话，就知道其实上面讲

4、的就是 redux 的核心理念，它和 react 的数据驱动原理是相匹配的。 数据流框架 redux 数据流框架目前占主要地位的还是 redux，它提供一个全局 store 处理应用数据的接收，修改和分发。 它的原理比较容易，view 里面有任何交互行为需要转变数据，首先要发一个 action，这个 action 被 store 接收并交给对应的 reducer 处理，处理完后把更新后的数据传递给 view。redux 不依靠于任何框架，它只是定义一种方式控制数据的流转，可以应用于任何场景。 虽然定义了一套数据流转的方式，但真正用法上会有不少问题，我个人总结主要是两个问题： 定义过于繁琐，文件

5、多，简单造成思维跳动。 异步流的处理没有优雅的计划。 我们来看看写一个数据哀求的例子，这是十分典型的案例： actions.js export const fetch_data_start = &39;fetch_data_start&39; export const fetch_data_success = &39;fetch_data_success&39; export const fetch_data_error = &39;fetch_data_error&39; export function fetchdata() return d

6、ispatch => dispatch(fetchdatastart(); axios.get(&39;xxx&39;).then(data) => dispatch(fetchdatasuccess(data); ).catch(error) => dispatch(fetchdataerror(error); ); ; export function fetchdatastart() return type: fetch_data_start, .fetch_data_success .fetch_data_error reducer.js import

7、fetch_data_start, fetch_data_success, fetch_data_error from &39;actions.js&39; export default (state = data: null , action) => switch (action.type) case fetch_data_start: . case fetch_data_success: . case fetch_data_error: . default: return state view.js import createstore, applymiddlewar

8、e from &39;redux&39; import thunk from &39;redux-thunk&39; import reducer from &39;reducer.js&39; import fetchdata from &39;actions.js&39; const store = createstore(reducer, applymiddleware(thunk); store.dispatch(fetchdata(); 第一个问题，发一个哀求，由于需要托管哀求的全部状态，所以需要定义无数的 action

9、，这时很简单会绕晕，就算有人尝试把这些状态再封装抽象，也会充斥着一堆模板代码。有人会挑战说，虽然一开头是比较棘手，繁琐，但对项目可维护性，扩展性都比较友好，我不太认同这样的说法，目前还算容易，真正业务规律复杂的状况下，会显得更恶心，效率低且阅读体验差，信任大家也写过或看过这样的代码，后面自己看回归，需要在 actions 文件搜寻一下 action 的名称，reducer 文件查询一下，绕一圈才渐渐看懂。 其次个问题，根据官方推举用法 redux-thunk 实现异步 action 的办法，只要在 action 里返回一个函数即可，这对有强迫症的人来说，简直受不了，actions 文件显得它很不纯，原来它只是来定义 ac