使用react的好处_Vue 和 React 的优点分别是什么?

感谢王雷知乎用户指出我的一个错误,错误地把制约性能的地方定位在diff而不是patch。

这个错误也显示了我作为一个Angular开发者的思维定式,是,我承认,也希望大家共勉——

Angular开发者错误思维定式之一:

因为Angular是操作真实DOM就以为virtaul到actual中的patch没有性能开销

不过观点依然如此,不能活在自己的领域内无法自拔。

比如其他答案下出现的一些矛盾:

-你看Reat有fiber所以vue一定要抄?

-抄fiber干嘛?实现都不一样…

-你看你拒绝时间分片,尤大都说要用时间分片…

-fiber什么时候变成时间分片了?

这种谬误可以等同于…

-我写的setInterval动画有点卡,该怎么优化?

-用fiber啊!

-…

-你看我用requestAnimationFrame优化了,现在一点也不卡~

-你看,我就跟你说用了fiber就会很好,浏览器渲染得都快了!你看你写个动画都要抄fiber~

用一个自己领域内的一个实现指代所有相关算法和相关实现,真是恐怖。本来vue的patch都在watcher中进去schedule,然后再提交,你可以说我用时间分片优化这个schedule里的提交队列。你说用fiber优化vue什么鬼?

看来cocos已经被fiber优化过了…

另外还有好多人没有意识到这种说法有什么问题,我再说明一下:

浏览器已经有事件循环了,已经有异步环境了,不然你不可能在js里处理事件。

react的scheduler里清清楚楚地requestAnimationFrame和自己实现requestAnimationFrameWithSettimeout,是在浏览器空闲的时候请求一个新的浏览器帧。

到你们这儿成生造一个协程系统了。

单线程里做异步,比如tornado,你在python圈子里用tornado指代事件循环,别人最多说一句其他平台也有事件循环罢了。

你在本来就事件循环的浏览器请求帧运行自己代码,然后说自己实现了协程,这种言论就有奇怪,然后说还直接用自己平台发明的词类比别人还说别人也得学?还用自己平台的词类比协程啊,时间分片啊之类的。

另外做游戏的框架哪个不实现这一套,又变成是React首发了?React领域内自己的更新,非要用来说服其他平台的人。

我想问是不是React平台的每一个人,都是这么狂妄,当然我也知道产生这样的思想有点不好,不过甚至有某些大厂的员工也有这种想法,还说我对浏览器一无所知,言下之意就是React能够突破浏览器的限制,做浏览器不许他做的事咯?。

这样的环境真的让我有些不由自主地怀疑这个技术栈,真的。

不过当年React想要摆脱由浏览器钳制自己的应用性能,使用virtual dom来让自己代码层面平台无关,这其实是一种有些hack的行为,也就是并不是浏览器中代码的正常工作流程,所以一句happy hacking在你写代码的时候放出来给你看,那些无端鼓吹React的人,并没有认识到这一点,应该不是React的真正主力,也不可能是。

平台内部的同学很多惯性思维特别严重,总以为大家用的框架实现原理都是一样的,然后你抄我,我抄你,然后我遇到的问题你们肯定都会遇到,你们都快来学我。

这种心态要不得。

现在理性客观分析vue和React的响应式流程,评论区敞开来说。

React reconciliation

首先附上连接,大家也可以根据文档纠正一下我的鄙陋,毕竟细节的理解是有区别的。

React的reconciliation(调和)是一个过程,描述的是React如何将virtual dom转化成actual dom的实现,为甚么要用virtual dom?因为document.createElement方法有性能损失(浏览器机制)。

局限在React框架下的朋友,很容易就得出结论——

document.createElement有性能损失,所以肯定要做virtual dom到actual dom之间的变更检测,并使得变更的部分能够被识别出来,然后用create和delete的api修改真实DOM。

实现的结果是这样的:首先setState函数告诉组件我要更新了,这个方法会把state放入状态队列中,如果一个事件循环状态队列没有更新,则视为不会更新,否者,更新组件(virtaul dom),并标记为脏(这部分不是reconciliation)。

当前virtual dom有脏节点,怎么办?react从当前节点出发,向下遍历所有子节点和子组件。找到变更的部分,patch(conmmit)也就是调用createElement或者removeElement或者重新赋值。当然这个遍历过程是有算法优化的,也就是diff算法,优化有:比较同级节点,比较节点类型——比如component编程了string,比较空和非空等等,将O(n3)的问题优化为近似O(n)的问题。(这就是reconciliation)

这样做有什么好处?你自己随意书写变量,函数,等编程元素,只要在需要变更视图的时候,setState就可以了

你可以有更多方式声明组件和节点,什么hoc啊,pure啊之类的,能够有更加灵活的编程体验,适合更多的编程范式。

这样做有什么坏处?直接setInterval(()=>{setState(...)},1),就能发现——如果我不停地将节点标记为脏,不停地运行那个diff过程,导致不停重绘,当前事件循环会被阻塞——也就是卡。

setState导致你在编程过程中,虽然不用考虑类似getElement,removeElement之类的操作,但是setState无形之中还是用两个”树“制约了你的思想,也就是React惯性思维的一种——一定要等数据都变更完成了再渲染啊?

脏节点以下所有子组件都要渲染,如果页面大了,顶层数据一改变,diff的工作量就会变大,也会导致大量重绘,同样也会出现阻塞。

接下来,React想到一种方式优化这个操作,这个方式就是——requestAnimationFrame。

用过requestAnimationFrame的同学应该也深有体会,一旦将setTimeout的动画用requestAnimationFrame写,就可以很顺畅了,为什么?

因为底层逻辑不同:setTimeout是将函数绑定到事件循环的底部,导致一旦线程阻塞,运行会被推迟:

2.而requestAnimationFrame是将帧暴露给你,当前帧内浏览器空闲就执行你的代码。

而这个requestAnimationFrame,就是浏览器的时间分片,有没有办法让React容易阻塞的diff过程在这种机制下运行呢?

于是有了fiber这样的数据结构:将单纯的diff算法中每层的比较记录下来——以前是只标记改变的值:

function FiberNode(

tag: WorkTag,

pendingProps: mixed,

key: null | string,

mode: TypeOfMode,

) {

// Instance this.tag = tag;

this.key = key;

this.elementType = null;

this.type = null;

this.stateNode = null;

// Fiber this.return = null;

this.child = null;

this.sibling = null;

this.index = 0;

this.ref = null;

this.mode = mode;

// Effects this.effectTag = NoEffect;

this.nextEffect = null;

this.firstEffect = null;

this.lastEffect = null;

}

将Effect标记在fiber这样的结构中,并且他的child和sibling都已经被记录,这样变更和位于virtual dom中的位置都会被记录。

2. 然后,用workInPregress封装fiberNode

// This is used to create an alternate fiber to do work on.

export function createWorkInProgress(

current: Fiber,

pendingProps: any,

expirationTime: ExpirationTime,

): Fiber {

let workInProgress = current.alternate;

if (workInProgress === null) {

// We use a double buffering pooling technique because we know that we'll

// only ever need at most two versions of a tree. We pool the "other" unused

// node that we're free to reuse. This is lazily created to avoid allocating

// extra objects for things that are never updated. It also allow us to

// reclaim the extra memory if needed.

workInProgress = createFiber(

current.tag,

pendingProps,

current.key,

current.mode,

);

workInProgress.elementType = current.elementType;

workInProgress.type = current.type;

workInProgress.stateNode = current.stateNode;

}

3.scheduler中实现了requestAnimationFrame一样的机制,并做了个响应式的tracing(目前他的说明是希望做平台无关的,但是源码中有浏览器相关api)。

4.在enableSchedulerTracing为真的时候,开始workingPregress的处理。

这样就保证了React的渲染virtual dom总是能够异步地进行,将那些React的setState带来的坏处降低到用户感知不到的程度。(不过造成了新的问题,那是后话)

但是肯定要做virtual dom到actual dom之间的变更检测么?

相继出现的Vue找到了另一种优化方法——组件响应式。

原理是,我为什么要把setState这样会引起性能开销的api交给用户呢?即——为什么要用户setState的时候再进行diff呢?并且,如果我准确知道了哪一个组件会变更,我直接修改这个组件就行了,为什么还要遍历所有子组件树?

很快Vue给出了解决方案:不进行组件间的diff递归,只在组件内进行diff,摒弃掉函数式组件等其他的方式,规定统一api——vue.component。

用代理模式,将data中的值用getter和setter绑定起来,并设置响应式watcher,压入队列。如果watcher发现了变更,启动组件内的diff,直接将新的组件patch到dom。

这里的watcher回调就是有数据变更组件的变更后virtual dom,粒度大小与优化后的一个React fiber相同。

这样做的优点是:不需要在思维上想象diff过程,因为我修改一个组件,diff被限制在了组件内,用户的使用过程中不需要思考性能优化的问题。

组建内的diff可以直接使用jsx,vue的vnode也支持了jsx的编译,可以利用React的生态。

这样做的缺点是:灵活度下降,不能支持很多编程范式(给出了强制api)。

组件相关变量被限制在了data中,setState的问题相对容易察觉,但是循环修改data值虽然性能开销小得多,但是更加难以发现。但是patch带来的性能开销依然存在,下一步的优化方向,也有考虑使用requestAnimationFrame的方式优化watcher的绑定和组件的patch。

但是真的真的需要virtual dom么?

直接在dom里响应式?

有请render2

以及,ivy

另一种思考方式,我为什么要用数据驱动的方式思考问题?该干啥干啥不行?

然后有些自以为是的React平台内的朋友,觉得Vue就该学fiber,两个问题fiber是个数据结构,描述的是一次统计diff节点操作的快照。

就算你说的是时间分片,你也要说时间分片,不是什么fiber!fiber不代表时间分片。

fiber是个数据结构不假,你甚至可以说fiber架构代表了用时间分片异步化diff流程以及patch流程的一种实现方式,你说fiber代表了时间分片?乖乖……

这暴露了一个问题,React社区很容易形成以自我为中心的思考方式,总结以下思维误区以供参考:一定需要virsual dom到actual dom的diffing 过程(全局的)

fiber和轮询调用是同义词

fiber和时间切片是同义词

类型声明或者class就是面向对象

template一定要写在js中

shadow dom是react实现的

react的某些优化可以加速浏览器渲染

redux就是函数式

数据驱动是前端的发展趋势

....

是是是,啥概念都应该以React的为准!

应用领域不一样,完全不不构成竞争关系,跟你说React比Vue牛皮的人,下次怼回去,职业素养真的太低。

首先React和Vue有非常多的相似之处,比如:都是数据驱动

都能使用jsx进行编程

但是两者数据驱动实现不同,React是传统消息驱动模式,setState通知变更检测,Vue是proxy模式。

实现不同,必然导致编程风格的差异:getter,setter对用户不可见,必然会隐藏很多渲染细节,好处是让用户更专注于逻辑部分,坏处是渲染时间和运算不可控。setState虽然需要用户手动进行,暴露了一些细节,但是用户权限更多,对性能的控制更强。

Vue的jsx只能实现模板的组装(比如你想要动态注入一段jsx,只能像iview一样写render函数了),本质和html一样,React的jsx能实现更多的技巧。既Vue结构确定,是一种声明式的v-vm映射工具,而React更偏命令式一点,是一种由vm驱动v的工具(hooks的发布更加坐实了这一点)。

优劣点有哪些呢?声明式的Vue上手更加简单(对象映射template,直观),开发效率高,但是api更多,约束也更多。

React上手偏难一点点(命令式反直觉),开发效率要低一点,但是api少,约束也少,更加灵活。

生态的话:状态管理方面React要丰富一点,毕竟消息驱动是它的根,状态管理就是它的命,不可能不重视。

SSR个人认为nuxt要比next完善很多。

UI库是因为antd才有React UI库质量高的映像,iview也不错但是逐利心较重(没办法一个是kpi一个要活下去)。

对Typescript的支持因为Vue声明式编程要差一点,不过可能大家误解了Typescript,不是用了静态类型写几个class,interface就叫工程化了,感兴趣的话还是建议多多阅读spring或者.net平台的代码,面向对象不是类型检查器,因此React也并没有比Vue强多少。

根本就不是谁牛皮的问题,而是面对一个项目需求谁更适合的问题。

你可以试试事件驱动的ng,change after check劝退你~zone暴力事件代理,响应式流约束数据副作用,让你明白什么是止不住的忧伤。

为防止大家产生歧义

声明式和命令式指的是状态变更

你说react是声明式啊?你是指的描述ui,这不废话?html本来就是声明式的

vue是修改data对象自然就patch

react是调用setState函数

你可能感兴趣的:(使用react的好处)