react融合进系统的体验

前端之家收集整理的这篇文章主要介绍了react融合进系统的体验前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

引入的背景

在一个庞大的商业系统中引入react这种数据驱动的模式。
希望能够一点点重构去替换以前的模块,逐步的将系统重要部分底层框架替换成react。

同事实践的心得

以下内容都摘自同事使用后的一些感想

心得一

从过程化开发向面向数据的开发转化。后者要求开发者对数据结构和算法和业务需求本身要有理解。React开发的核心是设计一套数据结构使其既方便业务用户界面的展示又能方便的实现业务功能——表现为一组操作数据结构的算法。这与传统的前端开发很不一样,偏激一点的说,相比以前用$搬弄DOM节点,我觉得这样的前端开发更“严肃”了。我希望能够推动团队迎接,适应,实现这个变化,这对于一个技术人员,而不仅仅是前端技术人员都是有益的。

心得二

1.React单向数据流原则是核心中的核心,即整个系统中只存在自上至下的数据流,反向数据流通过绑定自动完成,不存在兄弟间横向数据流。

2.控制数据流属于最强的开发规范,必定会给开发业务的同学带来巨大的思维挑战,从系统整体质量和维护性来看,必须牺牲业务开发的编程自由度。目前就是自由度太高,导致出现五花八门的业务实现,代码根本没法看。

心得三

其实之前我们也是数据驱动视图的,生命周期时用初始化数据渲染了视图,自然这时有了一层数据到视图的映射逻辑关系。数据改变之后绑定视图映射关系会写在model onchange handler中。

这样会有一些问题:

1.数据到设图的映射逻辑关系可能写了两遍,而且会发散在template,action,view等各个地方

2.初始化时数据和视图的关系是同步的,但是初始化之后这两者就可能就不一致,很可能handler没写用jquery直接操作DOM了。

初级阶段觉得React的好处是,把映射关系收敛到render方法中,有一层封装让我们直接操作DOM变得更难。数据如果在任何时候都能表达视图,是有很多事情可以想象的。

心得四

我们需要在React方面思考的技术问题,有下面这些点:

UI组件应当有稳定一致的开发规范。

UI组件应当有充分的UT 。(并尝试是否可以为业务组件加UT)

UI组件乃至业务组件内的数据结构是否应该有一个统一的模式(如immutable或者更轻量的模式),使得对于数据结构的任意位置的修改,都可以有事件冒出做一些统一的处理。

多个兄弟的组件之间的通信有什么范式?

父子组件之间双向通信有什么范式?

目前实现了ER-React,即一个React模块对外表现为一个ER模块。未来在此基础上,将一个ER-React模块的父模块实现为React后,是要脱掉ER-React的ER,变为React-React呢?还是实现为React-ER-React呢?

按照React的开发模式,随着我们自下而上的重构业务,很自然的,下面的组件的“Model”部分会逐渐“上浮“与上层的组件的Model合并成为一个更大的Model。如此往复,我们自然会形成“整个应用只有一个大Model”的局面。我们需要在这一切发生之前想明白这个“大Model”内部要如何组织,会以何种形式存在,并以何种形式和各个组件交互。

类似,从View的角度看,我们最终会形成“整个应用就是一个大的React组件”。对于每一个业务动作,整个应用都会重新render。这个render的性能迟早我们需要关心。如何控制这个render的性能使之不会影响用户体验?

react引入的意义

活力

引入后我觉得最重要的成就就是让一个系统拥有升级换代的活力。就像注入新鲜血液一样,系统能够跟上时代的变化。

对于一个庞大的商业系统而言,系统底层的稳定性是一个很重要的点。不过如果能在在系统上面做一些侵入性的改造,让一个稳定的系统充满活力还是很有意义的。

首先对于业务开发人员,很明显,他们在原有系统上面开发了这么久以后,对于新技术的引入是非常欢迎的,他们是非常乐意去学习新技术的。

提高开发效率

这个是写给老板们看的,花这么大力气去引入一个新技术对于公司的收益就是提高开发人员的效率。

当然这个提高的效率的前提是对于开发人员有更高的要求的。

提高系统的健壮性

react的模式是可以在某种程度上面融入UT的。
以及一个很好的数据驱动模式维护性和扩展性是比现有系统强的。

回放用户行为

数据驱动好处就是可以通过数据记录用户页面状态,用数据就能恢复页面快照,需要分析用户行为,只需要收集到页面的数据变化流即可。

react引入的挑战

  1. 数据驱动最合适的是从根部重构。但是目前我们只能从叶子模块一点点往根部重构。其实是一个反向过程。

  2. 数据驱动模式对于开发人员要求比较高,能不能设计一种模式降低要求,避免出现不同水平的开发者开发出层次不齐的业务模块。

  3. 引入新的模式一个缺点就是以前模式成为了技术债务。因为一个系统存在多种模式,意味着新人学习成本会增加很多。多种模式的共存,如果维护不好,也会出现一种很混乱的现象。

微信公众号

ps:重要开通了微信的打赏功能,大家觉得好的话,去捧个场。。。奉旨打赏^_^

原文链接:/react/307134.html

猜你在找的React相关文章