MVVM及其组件体系_angular_react_vue by 杨文坚

AirJD

没有录音文件

00:00/00:00

加收藏

MVVM及其组件体系_angular_react_vue by 杨文坚

发布者 FEer 简介前端技术

发布于 1456707667572 浏览 6407 关键词 前端, JavaScript, HTML5

分享到

第1页

MVVM及其组件体系

第2页

IMWeb资深前端开发工程师
负责IMWeb部分技术架构研发工作
互动视频
在线教育
……

第3页

Summary

为什么需要MVVM？
有什么可供选择的MVVM框架？
海量业务场景下挑战
IMWeb的解决方案

第4页

So, why me need MVVM？

第5页

小孩换衣模型

第6页

第7页

第8页

邮箱模型

第9页

第10页

第11页

第12页

Interesting!
But how to do it?

第13页

这里有个简版实现大家可以参考下：

https://github.com/imweb/Q.js

第14页

OK，挺有意思。
那么有什么可以选择的框架么？

第15页

第16页

Angular之父Misko Hevery称Angular的灵感来自于FLEX。

Angular just like FLEX

自成体系大而全的框架

英雄级的大型Web开发框架。

一旦拥有，别无所求（换句话说：用了我的就别想用别人的）
注重面向对象设计，比如引入依赖注入，Typescript等（换句话说：设计复杂，对后台友好，对前端需要更多学习）
被诟病的directive语法设计

第17页

React as the V in MVC

Angular 是 React 的假想敌，你懂

精巧高效的UI层组件化库

性能较佳
小而精，和别的东西组合容易
以Javascript为核心的组件化
奇怪的JSX写法令前端不爽

Web Component 未成熟前的极好替代品，甚至可以说，Web Component 的出现有React深刻的影响。

第18页

Diff

Patch(s)

虚拟DOM

数据

DOM

Virtual DOM

https://github.com/miniflycn/qvd

说到 React 的性能就必须提Virtual DOM

减少浏览器引擎需要修改的DOM
减少浏览器在DOM与Javascript两个引擎中切换

如果对Virtual DOM算法有兴趣可以参考下面链接

第19页

多快？

第20页

React-Native

React 杀手级应用，可以用同样的技术开发iOS和Andriod应用。

第21页

Vue.js is a library for building modern web interfaces.

简单而灵活的界面交互库

本质上，Vue.js 并没有带来什么新东西，但：

接口设计简单，灵活
面向未来，通过构建进行类Web Component式开发
抛弃了IE8……

第22页

海量业务场景下的挑战

第23页

访问一个页面的网络过程

？

第24页

多普勒测速

t1 – t2 = DNS
t2 – t3 = TCP/IP
T3 = RTT

多普勒测速方案：
http://a-doppler.facebook.com/test_pixel?HTTP1.0&t=1&size=0k
        t1= DNS + TCP/IP  + RTT
http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=2&size=0k
        t2= TCP/IP  + RTT
http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=3&size=0k
        t3= RTT
http://a-doppler.facebook.com/test_pixel?HTTP1.1&t=4&size=10k
        10k/(t4- t3 ) ≈ bandwidth

第25页

我们的方案

t2 = RTT
t1 – t3 = DNS
t1 – RTT – DNS = TCP/IP

我们自己的方案：
http://1.url.cn?t=1&size=0k
 t1= DNS + TCP/IP + RTT
http://1.url.cn?t=2&size=0k
 t2= RTT
<link rel=“dns-prefetch” href=“//2.url.cn” />
 dns 被浏览器缓存
http://2.url.cn?t=3&size=0k
 t3 = tcp/ip + RTT

第26页

多普勒测速

第27页

市面上的MV*库要不太大，要不不支持IE8......

第28页

我们的MVVM库——Q.js

足够小 - gzip 6k

兼容性 - IE6+ (with jQuery and es5-shim) & All Mobile Browser (with Zepto)

足够小，gzip之后只有6k
基于jQuery和es5-shim能支持IE6+，基于Zepto可以支持安卓2.3
节省约20%-30%代码量，例如下面的例子，之前需要48.5kb，之后只需要33.6kb便能完成同样功能。

第29页

仅仅使用MV*还不够，还需要组件化

第30页

通常的组件化代码

第31页

如果使用组件能跟使用原生DOM元素一样，该多好？

如果使用组件能跟使用原生DOM元素一样，该多好？
例如上面的例子变成这样：

第32页

Yes, Web Component!

全平台？全场景？(IE8？安卓2.3？Web侧？PC客户端？手机客户端？)
重用性与易扩展性如何解决？
如何降低调试成本？
迁移成本

是的，Web Component便能解决。但想融入我们的业务场景还要解决下面几个问题：

兼容性，如何兼容IE8，安卓2.3，如何覆盖Web侧、PC客户端、手机客户端？
如何重用，如何扩展？
如何降低调试成本？
怎么解决迁移成本？

Ques 为什么不使用React？

我觉的React很好，甚至Web Component本身也深受其影响，但是：

* React的JSX其实是反标准的，在Web历史进程中我们可以发现，反标准最终都混的不怎么样，即使技术上是超前的(IE在VBScript引入getter和setter、prototype.js通过修改prototype扩展原生对象方法)

第33页

基于动态编译和MVVM的类Web Component组件化方案——Ques

线下编译解决兼容性：IE8(甚至IE6)兼容

那么我们怎么解决IE8的兼容问题呢？

实际上，大部分线上解决不了的问题都可以通过线下解决：

没有HTTP2，所以通过线下打包来节省请求
LESS刚出来的时候在浏览器编译，但太慢了，所以就线下构建了
react通过创建对象创建虚拟dom，太晦涩，所以现在来做个jsx线下转js

第34页

可组合：复杂UI可拆分成多个简单UI

这里是有技术难点的，也就是说如何控制组件的能控制到的DOM的范围，即DOM的作用域。

简单的说，如果父级组件能控制子组件的DOM的话，那父级组件就能删掉子组件的元素，导致子组件找不到对应元素，甚至产生致命错误。

这也是为什么需要将DOM操作托管给库的原因之一。

第35页

可继承：相似组件可通过基类扩展

可重用：可在不同场景使用

接下来开发同学需要一种方式来扩展组件，因为他们发现很多组件只有很少的地方不一样，但全部写成一个组件又困难重重，例如dialog组件。

组件继承便可以解决这个问题，例如下面的例子，我们制作了一个基类组件dialog之后，通过extend属性来声明继承，新建一个新的组件，修改了组件部分内容后，并继承了dialog所有的数据、方法以及事件。

组件还是可以重用的，那么一个组件就能用在多个场景，避免重造轮子。

第36页

单例调试 + 自动文档化

把多个组件集成到一起调试太困难？
业务组件基本没时间写文档？

所以我们又做了一个组件单例调试功能，顺带带了自动文档化，通过扫描代码来生成简单的文档。

第37页

第三方组件 = less组件开发成本 + less迁移成本

高亮代码组件，通过第三方库highlight.js来实现非常快

旧项目很难迁移？
为什么我要花时间开发一个datepicker或者富文本？

第三方组件来解决这个问题，例如这是一个第三方代码高亮组件，用MVVM开发一遍很麻烦。而利用highlight.js就很简单：

写容器的模版
实现bind(容器出现时该干什么)，unbind(容器销毁时该干什么)

就可以在整个组件系统中使用，唯一的缺点是该组件内部不可以嵌套。

第38页

符合人类通常思维模式：
将事物拆分成有机个体，
再各个击破

最终效果: 结构有迹可循，代码可预测

所以当我们想改变业务逻辑的时候，我们可以只关注逻辑层；
如果我们想要改CGI与组件的数据对接，就可以改数据处理层；
如果我们想修改上报，就只需要去上报层修改。

第39页

更多的想象力

前后端代码重用 —— Q.tpl
前终端同构——Q-native

https://github.com/miniflycn/Ques

第40页

<%= _filterValue("list | length") %>

4

编译

data

模版复用

第41页

Thanks & QA