为了账号安全,请及时绑定邮箱和手机立即绑定

请问该如何评价数据流管理架构 Redux?

/ 猿问

请问该如何评价数据流管理架构 Redux?

缥缈止盈 2019-08-17 11:11:39

如何评价数据流管理架构 Redux


查看完整描述

5 回答

?
30秒到达战场

首先,其实 Vue 也完全可以全量赋值的,唯一需要的小优化就是给 v-repeat 列表一个 track-by 属性,提示一下如何判断两个对象是否是同一份数据。如果是没有复杂交互的列表,可以直接 track-by="$index" 原地复用 DOM 元素。
合理使用 track-by 的情况下,Vue 甚至可以比 React 更快(这里渲染的是 100 * 5 的数据表,每一帧都是全量新数据赋值):
dbmon (Vue)
dbmon (react)
在超大量数据的首屏渲染速度上,React 有一定优势,因为 Vue 的渲染机制启动时候要做的工作比较多,而且 React 支持服务端渲染。
需要指出的一点:React 的 Virtual DOM 也不是不需要优化的。复杂的应用里你有两个选择 1. 手动添加 shouldComponentUpdate 来避免不需要的 vdom re-render;2. Components 尽可能都用 pureRenderMixin,然后采用 Flux 结构 + Immutable.js。其实也不是那么简单的。相比之下,Vue 由于采用依赖追踪,默认就是优化状态:你动了多少数据,就触发多少更新,不多也不少。
说起 Flux 架构,FB 提供的标准实现非常繁琐,所以社区的各种造轮子版本层出不穷,目前其实还没有找到一个公认的最佳实践,而且大部分新 Flux 实现都引入了很多函数式概念,你如果对函数式编程不熟悉,光搞清楚那些概念就得花很久。
如果你真的理解了 Flux,你又会发现其实 Vue 也是可以应用 Flux 架构的。比如 optimizely/nuclear-js · GitHub 是一个 Flux 变种,他们就是同时把这个东西用在了 React 和 Vue 上面。
再谈谈开发风格的偏好:React 推荐的做法是 JSX + inline style,也就是把 HTML 和 CSS 全都整进 JavaScript 了。Vue 的默认 API 是以简单易上手为目标,但是进阶之后推荐的是使用 webpack + vue-loader 的单文件组件格式:
依然是熟悉的 HTML 和 CSS,但是可以放在一个文件里。而且你还可以使用你想要的预处理器,比如 LESS, Jade, Coffee, Babel,都可以。
然后扯一扯模板 vs. JSX 的问题。JSX 在逻辑表达能力上虽然完爆模板,但是很容易写出凌乱的 render 函数,不如模板看起来一目了然。当然这里也有个人偏好的问题。
React 的社区/组件生态比 Vue 大很多,这个是很显然的。不过说实话我很少见到现成的第三方组件完全符合我的要求。
最后,使用场景上来说:React 配合严格的 Flux 架构,适合超大规模多人协作的复杂项目。理论上 Vue 配合类似架构也可以胜任这样的用例,但缺少类似 Flux 这样的官方架构。小快灵的项目上,Vue 和 React 的选择更多是开发风格的偏好。对于需要对 DOM 进行很多自定义操作的项目,Vue 的灵活性优于 React。
---
更新:
楼下有些回答说 Vue 的核心是 MVVM 双向绑定,然后就直接跳跃到了『不适合持续工程迭代』的结论。且不说这样的跳跃太草率,这样的看法本身对于双向绑定的理解也是有偏差的。表单的双向绑定,说到底不过是 (value 的单向绑定 + onChange 事件侦听)的一个语法糖,你如果不想用 v-model,像 React 那样处理也是完全可以的。另一方面,组件间的数据传递,Vue 默认是单向的,和 React 一样。
React 本身并不存在所谓的『单向数据流』,这完全是 Flux 引入的概念。其核心还是在于避免组件的 local state,强调把 state 抽取出来进行集中的管理。没有 Flux 的情况下 React 一样会有状态难以管理的问题,其根源在于在哪里存放和管理 state,和双向绑定没有本质联系。那难道 Vue 就不能这样管理状态吗?当然是可以的,Vue 现在可以通过 egoist/revue · GitHub 和 Redux 进行配合,也可以用 Vue 专属的状态管理架构 Vuex: vuejs/vuex · GitHub ,『单向数据流』并没有 React 吹的那么神,直接因为这一点就觉得 Vue 不适合工程迭代,完全站不住脚。


查看完整回答
反对 回复 2019-08-18
?
慕斯709654


一套很优秀的框架。

主要优点:
1. 大幅降低了 Facebook 官方的 Flux 实现的冗余和不必要的复杂度,整体结构更为清晰和容易理解。
2. 在 react-redux的配合下,完全分离了对数据的修改操作( Action / Reducer ) 和对数据的更新( Selector ),使得开发时可以在不考虑数据修改的情况下,优先完成整体视图逻辑,然后在添加对数据的修改操作等业务逻辑时几乎不用修改视图逻辑代码
3. 单一数据源( Store )的模式使得数据管理持久层方案选择和可调试性( Redux-Dev-Tools )都非常方便

主要缺点:
1. 对从 OOP 开发转过来的程序猿来说,函数式编程的概念接受起来需要一点门槛。
2. JavaScript 对不变对象的支持并不是特别的友好,无论是引入 immutable.js 还是 ES6 的解构语法糖有时候都觉得 Reducer 里的代码读起来有些费力,特别是对刚接触 ES6的同学来说。
3. 所有的 rackt · GitHub 旗下的框架,比如 rackt/react-router · GitHub 和 rackt/redux · GitHub ,以及 React 本身,都流露出一种 “ 老子就是要做最牛逼的东西,向下兼容这种事情根本就不是老子考虑的问题 ” 的态度。而且很多时候不是简单的不向下兼容,而是给人一种回炉重做的感觉。针对项目开发,一定要慎重选择版本。关于这一点 @杨森 可能会有话要说,他的博客里对 react-router 的教程已经更新了 N 版,仍然多次赶不上官方的 API 变化速度。

综合结论:
Redux 非常优秀,但是目前来看,比较适合喜欢折腾、自学能力强、熟练阅读 GitHub 上的官方英文文档并于官方在 issue 里谈笑风生的开发者去学习。当然,也许再过几个月,API 真的稳定了,然后诸位大神的中文文档也普及了,就能在国内有更大的发展了吧






查看完整回答
反对 回复 2019-08-18
?
RISEBY

React+Redux非常精炼,良好运用将发挥出极强劲的生产力。但最大的挑战来自于函数式编程(FP)范式。在工程化过程中,架构(顶层)设计将是一个巨大的挑战。要不然做出来的东西可能是一团乱麻。说到底,传统框架与react+redux就是OO与FP编程范式的对决。

简单学习某项技术并不能让建立起一个全局理解,也很难工程化。所以,我们必须要看以下几方面:

了解其独特的东西。如React中组件是pure render函数。

置新技术于上下文中。将React放在flux、redux中。才能真正看到数据单向流动。

对比看到优势。比其它的解决方案(vue, angluar,adobe flex),看其优势。

挑战。软件领域里没有银弹,有好处一定有挑战。


查看完整回答
反对 回复 2019-08-18
?
哆啦的时光机

要确定redux架构时候,可以先思考一下,redux实质上做了什么。事实上,redux一直都被宣称为一个状态管理器。使用react作为前端组件化工程类库,每一个组件必然有自己的状态以及需要传递到子孙组件的状态。redux准确来说,是管理“共享状态”,这些状态都是可以被自己以及子孙组件,通过action进行调用修改的。

回到楼主的问题,既然明白了redux的实质用处,就可以开始架构了。
在很多boilerplate或者示例里面,redux一直被作为顶级的状态管理器。对于大型前端项目,这样不仅导致reducers非常庞大,而且在多模块加载情况下导致非常多冗余代码,而且constant会非常容易重复

最后结论是,模块化开发,可以将每一个模块作为一个Web组件。独立使用Redux进行管理,这样既有利于代码分离,前端工程,又不会让redux代码量复杂冗余、难以管理。


查看完整回答
反对 回复 2019-08-18
?
明月笑刀无情

通常的情况是:写游戏的人非常容易接受React的模式,写服务器端的非常容易接受Angular的模式 但是两者相比React会更容易上手; 为啥ionic的项目用React就很难下手了? 因为之前ionic的各种组件都写好了呀,各种拼装就是了,而用React重构各种组。

查看完整回答
反对 回复 2019-08-18

添加回答

回复

举报

0/150
提交
取消
意见反馈 邀请有奖 帮助中心 APP下载
官方微信