单页应用详解(Single page apps in depth)
本文为译文,原文:http://singlepageappbook.com/detail1.html
5.什么是View? 看看替代方案
在这章节中,我们来看看各个框架中实现view的一些概念和区别。我写这章的时候写了一些代码来比较(基于TodoMVC),但是决定移除它,你的代码通常也会差不多,但是底层的机制和抽象使用的不一样。
view层是当代单页应用框架中最复杂的部分。毕竟,这是整个单页应用的关键:简单的创造相当丰富有交互性的视图。正如你将看到的,一般有2种方式实现view层:一种是基于代码,另一种是基于标记和相当复杂的模板系统。这就导致了不同架构的选择。
view需要完成下面几个任务:
- 渲染模板,我们需要有一种方式来处理数据,并把它映射/输出到HTML。
- 在数据响应和change事件之后更新views。当model中的数据改变之后,需要更新相关的views,引用新的数据。
- 通过event handlers绑定事件到HTML。当用户触发与view中HTML元素的交互,需要一种方式来触发行为。
view层的实现期望提供一种标准的机制和惯例来完成这些任务。下面这个图标展示view是如何与models和HTML交互的:
![](https://i-blog.csdnimg.cn/blog_migrate/6df7d82513db4c2b84ab5085e2b6de8b.png)
这里有2个问题:
- 事件处理器如何绑定到HTML/从HTML解绑
- 什么样粒度的数据需要重新更新
解答了这2个问题,你就能确定view层的实现有多复杂,模板系统应该如何输出。
事件的绑定通过DOM选择,数据更新通过"view-granular",有点像Backbone.js
在这个章节里,我会分析人们在写view层的一些选择,我做了些对比:
- 低交互性 vs 高交互性
- 近服务器端 vs 近客户端
- 标记驱动视图 vs 模型支持的视图
- 视图粒度 vs 元素粒度 vs 字符串粒度的更新
- 基于css vs 框架生成 的事件绑定
低交互性 vs 高交互性
低交互性
| 高交互性
|
|
|
Github和Gmail都是当代的web应用,但是他们有不同的需求。Github的页面是大量的表单驱动,通过碎片的数据来触发整个页面的刷新。Gmail里的行为会触发复杂的变化:添加和触发一个新的消息来更新多个地方而不刷新这个页面。
你在做哪种类型的应用决定了选择什么样的架构/框架。
近服务器端 vs 近客户端
UI的构建靠近服务器端跟接近数据库,数据的访问将会更早,更少的延迟。UI的构建靠近客户端可以更靠近用户,可以让响应/复杂的UI更容易开发。
![](https://i-blog.csdnimg.cn/blog_migrate/68dd89b277726b74786a0db1e66e74fb.png)
待续...