当下前端开发框架设计显然已经在mvvm方式上又发展了一步,virtual dom提出不久,使用前端代码来调用native的思路就开始被实践。相信大家也知道是什么东西。到了今天,我们不得不承认,mnv* 框架开发时代已经到来。

mnv是什么,具体可以这么理解,model-Native-View-*,而后面的则可以认为是 virtual dom 或mvvm 中的 ViewModel,或者我们也可以自己使用controller来实现的调用方式。想想这样定义是非常合适的。相比之前的不同,就是用nativeView 代替了 htmlView。那么我们再看下从dom api 到mnv*,我们为什么会看到这样的变化。

1.dom交互

在此之前不得不提下之前的dom交互框架,就是直接选择找到特定的dom进行操作,思路十分直接也很实用,通过dom交互框架,相比Java原生API,我们可以比较高效地处理dom的改变和事件绑定了,这种高效的方式给我们带来了效率上的提高,但是页面复杂了就不好处理了。

随着ajax技术的盛行,SPA应用开始被广泛运用。SPA的引入将整个应用的内容都在一个页面中进行异步交互。这样,原有的dom交互方式开发就显得不好管理,例如某SPA页面上交互和异步加载的内容很多,我们的做法是每一次请求渲染后做事件绑定,异步请求后再做另一部分事件绑定,后面以此类推。当所有异步页面全部调用完成,页面上的绑定将变得十分混乱,各种元素绑定,渲染后的视图内容逻辑不清,又不得不声明各种变量保存每次异步加载时返回的数据,因为页面交互需要对这些数据做操作,最后写完,项目代码就成了一锅粥。

2.前端mvc

为了更方便地统一管理页面上的事件、数据和视图内容,就有了早期mvc的框架设计。mvc可以认为是一种设计模式,其基本思路是将dom交互的过程分为调用事件、获取数据、管理视图。即将之前所有的事件、数据、视图分别统一管理。用model来存放数据请求和数据操作,视图来存放对视图的操作和改变,controller用来管理各种事件绑定。

例如,SPA中的每个异步页面可以看成是一个组件,之前的做法是每个组件独立完成自己的数据请求操作、渲染和数据绑定,但是组件多了,每个组件自己去做就比较混乱,逻辑比较混乱。到了mvc里面,所有的组件数据请求、渲染、数据绑定都到一个统一的model、view、controller注册管理。后面的操作我们就不再管你有多少个组件了,你要调用必须要通过统一的model、view、controller来调。通俗来说就像是组件交出了自己控制权到一个统一的地方注册调用,这样就方便了很多,相信大家都已经了解过,这里就省篇幅不举例了。

3.前端mvp

mvp可以跟mvc对照起来看,而且我们也很少专门去关注它。和mvc一样,mvc的M就是Model, V就是View,而P,则代表Presenter,它与Controller有点相似。不同的是,在mvc中V会直接展现M,而在mvp中V会把所有的任务都委托给P。V和P会互相持有reference,因此可以互相调用。

例如我们可以在mvc代码上做一点改变,写成这样:

几个好处,这样将view和Controller的引用关联了起来,而mvc一般是通过事件监听或观察者的异步方式来实现的,我们可以在任意地方定义注册监听事件都不会有问题,这样监听的事件和触发这个事件的html元素脱离了引用,当应用复杂起来后要维护dom的交互逻辑就比较麻烦了。而mvp提供了一个简单的引用,将元素对应的操作与对应的presenter关联起来。我们要查询元素对应的controller时只要通过Controller.vp就可以直接调用了,其实这个时候就和mvvm的定义方式有点类似了,不是吗?

4.前端mvvm

mvvm概念可以认为是一个自动化的presenter,也在这个时候进一步弱化了C层,任何操作都通过viewModel来驱动。Controller最终在页面上的行为通过directives的形式体现,通过对directives的识别来注册事件,这样管理起来就更清晰了。

看一个mvvm框架定义的例子:

和mvp的定义比较,有点类似,mvvm设计一个很大的好处是将mvc中controller中的controller注册到相对应的元素中,让我们后期维护时很快定位,免去了查看controller中event列表的工作,而且初始化后自动做数据绑定,能将页面中所有同类操作复用,大大节省了我们自己写代码做绑定的时间。这段代码中初始化时自动帮我们就做了数值填充、数据双向绑定、事件绑定的事情。

那么框架怎样帮我做的呢。我们来看下newVM做了哪些事情:这里传入了元素、数据、方法列表、自定义directive列表,首先程序找到这个元素,开始对这个元素的属性节点进行遍历,一旦遍历到属性名称含有q-开头的属性是,认为是mvvm框架自定义的属性,然后会对属性的指进行特殊处理;例如遍历到q-html="label"时,将data中的label值赋给这个元素的innerHTML;如果遍历到q-on="click: submit"时,将这这个元素上绑定click事件,事件回调函数为submit;也可以自定义q-mydo的指令,遍历到该节点属性是,调用directive中的mydo方法,输入参数为data中的getValue方法返回的值,getValue输入参数为number值,这里的getValue被称为过滤器。

这里要知道的是q-开头的属性指令是框架约定的,不同的框架约定的不一样,例如ng-、v-、ms-,这些大家也都见过或用过。这里viewModel创建进行绑定的原理就这么简单,按照这个思路去扩充,就可以自己写一个mvvm框架。当然完整的框架涉及东西多的多,含有丰富的directive、filter、表达式、vm完善的api和甚至一些兼容性处理等。

总结来说从mvc到mvp,然后到mvvm,前端设计模式仍然是向着易实现、易维护、易扩展的基本方向发展的。但目前前端各类框架也已经成熟并开始版本迭代。但是,这还没有结束,我们依然没有脱离dom编程的基本套路,一次次框架的改进只是提高了我们的开发效率,但是dom元素的效率仍没有得到本质的提升。

5.前端virtual dom

为了改进dom交互的效率,或者说是尽量减少dom交互的次数,virtual dom的概念当下十分盛行,目前圈内各种大小团队纷纷投入项目使用。因为viewModel的改变最终还是要实时操作dom来刷新view层,而dom对象的操作相对于Java对象的操作仍然是要慢些。原因很简单,dom节点对象的内置属性很多,就创建一个dom对象而言,dom的创建需要处理各种内置属性的初始化,而如果使用Java对象来描述就简单了。

使用virtual dom,页面的渲染过程不再是数据直接通过前端模板渲染到页面,也不是初始化viewModel进行页面模板填充和事件绑定,而是通过dom衍生描述语法(这为什么称为DOM衍生描述语法,通常我们通过html来描述,但是目前一些框架是通过非标准的html的方式描述的,定义的一套迎合自己框架的方式,其实使用html也是可以的)解析生成virtual dom,页面交互变成了是修改virtual dom,然后将virtual dom的改变反映到htmlView层上。

可以使用如下java来表示:

如果java对象children属性第三个元素要被移除,同时,添加一个class为ui-list-item2的li节点,则首先需要对java对象进行修改记录所有的操作,最后将修改的vitual dom变化反映到页面上:

这里的java对象就相当于virtual dom,用户的某个交互操作可能导致dom的多个地方,如果没有vitual dom,那可能就要进行多次dom操作,virtual dom则可以将多个用户交互操作反映在virtual dom上,最后做的virtual dom DIFF算法然后再dispatch到页面view层上。相对于mvvm,在页面初始化渲染阶段,也避免了扫面节点,解析directives,要知道这些操作都是dom操作,使用virtual dom显然能将页面渲染速度提高不少。

6.前端mnv*

如果说vitual dom减少了dom的交互次数,那么mnv*想要做的一件事情就是完全抛弃使用dom,那样就只能在view层做改进了,使用nativeView来代替目前html的view,而交互逻辑依然可以使用viewModel、virtual Dom或者controller来实现,具体就看实现的方式了。

要做到NativeView的操作,这里与之前不同之处就是调用时通过衍生HTML语法通过解释器执行nativeView的渲染,这时就需要在native和衍生HTML语法之间添加一层解释器来解析现有的view描述语法了。比如我们看一个渲染Native的例子:

这里和vitual dom框架类似的地方都是都使用衍生的html描述语法来表示view层,而不同的是mnv模式是调用的nativeView来实现的衍生html的view展示。其实这里和上节中的实现唯一不同的地方是这里的view是native view。当然这只是一种实现,目前mnv的实现方案已经不止一种了,有人已经实践了通过mvvm的编程方式来将viewModel渲染转化为native view的方案。

7.总结

总结下来,前端框架一次次进化,先从效率的方向上提升,然后在性能上完善,这里只是想提出mnv*的一个概念来描述前端native开发的这个阶段。目前mnv的开发模式开始进入视线,也在快速地形成和建立生态。但尽管如此,我们如果需要选择技术栈方案,当然还是以最适合我们的作为最高原则。切忌过度设计。

作者简介:张成文,英文名Ouven,校导web前端开发工程师,前腾讯web前端工程师,对前端领域的技术知识具有较高的职业能力和探究精神。对前端响应式页面设计、工程构建组件化、mv*设计实现、前端优化、ES6开发体系、前端开发知识体系等有深入的研究和项目实践。

1.《校导张成文 | mnv*框架开发时代》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。

2.《校导张成文 | mnv*框架开发时代》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。

3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/guonei/367.html