前端的数据库,浅谈移动前端的最佳实践

前端的数据库:IndexedDB入门

2014/12/27 · 未分类 · IndexedDB

本文由 伯乐在线 –
cucr
翻译,黄利民
校稿。未经许可,禁止转载!
英文出处:www.codemag.com。欢迎加入翻译组。

应用程序需要数据。对大多数Web应用程序来说,数据在服务器端组织和管理,客户端通过网络请求获取。随着浏览器变得越来越有能力,因此可选择在浏览器存储和操纵应用程序数据。

本文向你介绍名为IndexedDB的浏览器端文档数据库。使用lndexedDB,你可以通过惯于在服务器端数据库几乎相同的方式创建、读取、更新和删除大量的记录。请使用本文中可工作的代码版本去体验,完整的源代码可以通过GitHub库找到。

读到本教程的结尾时,你将熟悉IndexedDB的基本概念以及如何实现一个使用IndexedDB执行完整的CRUD操作的模块化JavaScript应用程序。让我们稍微亲近IndexedDB并开始吧。

什么是IndexedDB

一般来说,有两种不同类型的数据库:关系型和文档型(也称为NoSQL或对象)。关系数据库如SQL
Server,MySQL,Oracle的数据存储在表中。文档数据库如MongoDB,CouchDB,Redis将数据集作为个体对象存储。IndexedDB是一个文档数据库,它在完全内置于浏览器中的一个沙盒环境中(强制依照(浏览器)同源策略)。图1显示了IndexedDB的数据,展示了数据库的结构

图片 1

图1:开发者工具查看一个object
store

全部的IndexedDB API请参考完整文档

渐进式Web应用(PWA)入门教程(上)

2018/05/23 · 基础技术 ·
PWA

原文出处: Craig
Buckler   译文出处:葡萄城控件   

最近关于渐进式Web应用有好多讨论,有一些人还在质疑渐进式Web应用是否就是移动端未来。

但在这篇文章中我并不会将渐进式APP和原生的APP进行比较,但有一点是可以肯定的,这两种APP的目标都是使用户体验变得更好。

移动端Web应用有很多优秀的概念让人应接不暇,但好在编写一个渐进式Web应用不是一个很困难的事情。在这篇文章里将向你介绍如何把一个普通的网站转换成渐进式Web应用。你可以按照这篇文章一步一步地做,做完之后你的网站将可以实现离线访问,并且可以在桌面上创建该网站的图标。那么下面即将开始入门教程。

浅谈移动前端的最佳实践

2015/07/13 · HTML5,
JavaScript ·
移动前端

原文出处:
叶小钗(@欲苍穹)   

设计典范

IndexedDB的架构很像在一些流行的服务器端NOSQL数据库实现中的设计典范类型。面向对象数据通过object
stores(对象仓库)进行持久化,所有操作基于请求同时在事务范围内执行。事件生命周期使你能够控制数据库的配置,错误通过错误冒泡来使用API管理。

什么是渐进式Web应用?

渐进式Web应用是一种全新的Web技术,让Web应用和原生APP的体验相近或一致。

渐进式Web应用它可以横跨Web技术及Native
APP开发的解决方案,对于开发者的优势如下:

  1. 你只需要关心W3C的Web标准,不用关心各种Native APP的代码。
  2. 用户可以在安装应用之前先试用。
  3. 在渐进式Web应用中,你不需要使用各种应用商店来分发应用,也不用关心应用发布时奇怪的审核标准以及应用内购的平台抽成。另外,应用程序更新是自动进行的,无需用户交互,所以整体的使用体验对于用户来讲更为的平滑。
  4. 渐进式Web应用的“安装”过程很快,只需要在主屏幕上添加一个图标即可。
  5. 渐进式Web应用启动时可以显示一个好看的启动画面。
  6. 你可以在渐进式Web应用中提供具有全屏体验的应用。
  7. 通过系统通知等形式提高用户的粘性。
  8. 渐进式Web应用将会在本地缓存必要的文件,所以渐进式Web应用会比普通的Web应用的性能更好。
  9. 轻量级安装——你只需要缓存几百KB的数据即可。
  10. 所有的数据传输必须使用安全的HTTPS连接
  11. 渐进式Web应用可以离线缓存数据,并且会在重新连接互联网时重新同步数据。

前言

这几天,第三轮全站优化结束,测试项目在2G首屏载入速度取得了一些优化成绩,对比下来有10s左右的差距:

图片 2

这次优化工作结束后,已经是第三次大规模折腾公司框架了,这里将一些自己知道的移动端的建议提出来分享下,希望对各位有用

文中有误请您提出,以免误人自误

对象仓库

object
store是IndexedDB数据库的基础。如果你使用过关系数据库,通常可以将object
store等价于一个数据库表。Object
stores包括一个或多个索引,在store中按照一对键/值操作,这提供一种快速定位数据的方法。

当你配置一个object
store,你必须为store选择一个键。键在store中可以以“in-line”或“out-of-line”的方式存在。in-line键通过在数据对象上引用path来保障它在object
store的唯一性。为了说明这一点,想想一个包括电子邮件地址属性Person对象。您可以配置你的store使用in-line键emailAddress,它能保证store(持久化对象中的数据)的唯一性。另外,out-of-line键通过独立于数据的值识别唯一性。在这种情况下,你可以把out-of-line键比作一个整数值,它(整数值)在关系数据库中充当记录的主键。

图1显示了任务数据保存在任务的object
store,它使用in-line键。在这个案例中,键对应于对象的ID值。

渐进式Web应用发展的现状

渐进式Web应用才刚刚开始发展,但实际上在国内,有些网站已经实际开始PWA的实践了,例如:微博、豆瓣、淘宝等平台。可能这时候聪明的你可能就会产生疑问,那这个PWA不就是和微信小程序一样吗,对是这样,二者的目的是一致的,就是在移动端为用户提供足够轻量且与原生应用使用体验相近的“轻”应用。

但就目前来讲,PWA是Google主推的一项技术标准,FireFox,Chrome以及一些基于Blink的浏览器已经支持渐进式Web应用了,Edge上对渐进式Web应用的支持还在开发。Apple公司也表示会考虑在自己Safari支持PWA。然而这项功能已经进入了WebKit内核的五年计划中。长期来看,对浏览器兼容性的支持方面应该已经不算太大问题了。况且在现阶段,在不支持渐进式Web应用的浏览器中,你的应用也只是无法使用渐进式Web应用的离线功能而已,除此之外的功能均可以正常使用。

而在微信这边,凭借庞大的用户基数和体量能否与PWA分庭抗礼乃至笑到最后目前还不得而知。

技术选型

基于事务

不同于一些传统的关系数据库的实现,每一个对数据库操作是在一个事务的上下文中执行的。事务范围一次影响一个或多个object
stores,你通过传入一个object store名字的数组到创建事务范围的函数来定义。

创建事务的第二个参数是事务模式。当请求一个事务时,必须决定是按照只读还是读写模式请求访问。事务是资源密集型的,所以如果你不需要更改data
store中的数据,你只需要以只读模式对object stores集合进行请求访问。

清单2演示了如何使用适当的模式创建一个事务,并在这片文章的 Implementing
Database-Specific Code
 部分进行了详细讨论。

示例代码

大多数教程都讲述的是如何在Chrome上从零开始制作一个类似原生界面的应用。然而在这篇教程中,我们并不打算做一个单页面应用程序,所以在这我们也不必了解诸如Material
Design等知识。那么下面我们就直接看示例吧。

你可以从GitHub中获取本教程对应的示例代码。

本示例中提供了一个有四个网页的网站,一个CSS文件和一个JavaScript文件。这个网站可以在所有的现代浏览器上正常工作(IE10+)。如果你的浏览器支持渐进式Web应用,用户可以在离线状态下将会直接访问缓存中的页面。

要想运行此示例,请确保你已经安装了Node.js。并请打开命令行,使用以下命令来运行该示例:

node ./server.js [port]

1
node ./server.js [port]

以上命令中,[port]是可选部分,默认为8888。使用 Ctrl + C 即可停止Web服务器。

打开基于Blink内核的浏览器(Opera,Vivaldi,Chrome),然后在地址栏中输入 或者 Cmd/Ctrl + Shift +
I)来查看控制台信息。

图片 3图片 4

查看首页,也可以在页面上点击一下,然后使用以下方法进入离线模式:

选中Network标签或者Application -> Service Workers
标签下的“离线”选项。重新访问之前访问过的网页,之前网页仍然会加载:

图片 5图片 6

单页or多页

spa(single page
application)也就是我们常常说的web应用程序webapp,被认为是业内的发展趋势,主要有两个优点:

① 用户体验好

② 可以更好的降低服务器压力

但是单页有几个致命的缺点:

① SEO支持不好,往往需要单独写程序处理SEO问题

② webapp本身的内存管理难,Javascript、Css非常容易互相影响

当然,这里不是说多页便不能有好的用户体验,不能降低服务器压力;多页也会有变量污染的问题发生,但造成webapp依旧是“发展趋势”,而没有大规模应用的主要原因是:

webapp模式门槛较高,很容易玩坏

1
webapp模式门槛较高,很容易玩坏

其实webapp的最大问题与上述几点没有关系,实际上阻碍webapp的是技术门槛与手机性能,硬件方面不必多说,这里主要说技术门槛。

webapp做的好,可以玩动画,可以玩真正意义上的预加载,可以玩无缝页面切换,从某些方面甚至可以媲美原生APP,这也是webapp受到追捧的原因。

但是,以上很容易被玩坏!因为webapp模式不可避免的需要用到框架,站点需要一个切实可行的控制器来管理History以及页面view实例化工作,于是大家会选择诸如:

Backbone、angularJS、canJs之类的MVC框架,于是整个前端的技术要求被平白无故的提升了一个等级,原来操作dom可以做的事情,现在不一定能做了。

很多人对以上框架只停留在使用层面,几轮培训后,对底层往往感到一头雾水,就算开发了几个项目后,仍然还是只能了解View层面的东西;有对技术感兴趣的同事会慢慢了解底层,但多数仍然只关注业务开发,这个时候网站体验便会受到影响,还让webapp受到质疑。

所以这里建议是:

① 精英团队在公司有钱并且网站周期在两年以上的话可以选用webapp模式

② 一般团队还是使用多页吧,坑不了


更好的建议是参考下改变后的新浪微博,采用伪单页模式,将网站分为几个模块做到组件化开发,碰到差距较大的页面便刷新也无不可

PS:事实上webapp模式的网站体验确实会好一点

基于请求

直到这里,有一个反复出现的主题,您可能已经注意到。对数据库的每次操作,描述为通过一个请求打开数据库,访问一个object
store,再继续。IndexedDB
API天生是基于请求的,这也是API异步本性指示。对于你在数据库执行的每次操作,你必须首先为这个操作创建一个请求。当请求完成,你可以响应由请求结果产生的事件和错误。

本文实现的代码,演示了如何使用请求打开数据库,创建一个事务,读取object
store的内容,写入object store,清空object store。

连接移动端安装

除了在PC浏览器访问外,你也可以在移动设备上访问该示例。使用USB线缆将你的移动设备连接到电脑上,然后从右上角三个点菜单中打开More
tools – Remote devices标签

图片 7图片 8

点击左侧的Settings菜单,然后添加一条端口映射(Port Forwarding)的规则,将8888映射为localhost:8888,现在你可以直接在手机打开Chrome然后访问http://localhost:8888 。

你可以使用浏览器的“添加到主屏幕”功能将当前网页添加到主屏幕,在你访问了几个页面之后,浏览器会将这个Web应用“安装”到你的设备上。浏览几个页面,关闭Chrome并将设备与电脑断开连接,点击桌面上生成的图标,你会看到一个Splash页面,并且你可以继续浏览之前浏览过的页面。

图片 9图片 10

框架选择

移动前端依旧离不开框架,而且框架呈变化状态,以我厂为例,我们几轮框架选型是:

① 多页应用+jQuery

② jQuery mobile(这个坑谁用谁知道)

③ 开始webapp模式(jQuery+requireJS+Backbone+underscore)

④ 瘦身(zepto+requireJS+Backbone View部分+underscore)

……

移动大潮来临后,浏览器基本的兼容得到了保证,所以完整的jQuery变得不是那么必须,因为尺寸原因,所以一般被zepto替换,zepto与jQuery有什么差异呢?

打开数据库的请求生命周期

IndexedDB使用事件生命周期管理数据库的打开和配置操作。图2演示了一个打开的请求在一定的环境下产生upgrade
need事件。

图片 11

图2:IndexedDB打开请求的生命周期

所有与数据库的交互开始于一个打开的请求。试图打开数据库时,您必须传递一个被请求数据库的版本号的整数值。在打开请求时,浏览器对比你传入的用于打开请求的版本号与实际数据库的版本号。如果所请求的版本号高于浏览器中当前的版本号(或者现在没有存在的数据库),upgrade
needed事件触发。在uprade
need事件期间,你有机会通过添加或移除stores,键和索引来操纵object stores。

如果所请求的数据库版本号和浏览器的当前版本号一致,或者升级过程完成,一个打开的数据库将返回给调用者。

小结

通过本节对渐进式Web应用的介绍,相信大家对PWA是什么已经有了基本的认识。PWA有无需担心有无网络的特点,并具有独立入口与独立的保护机制。新标准的推出很可能会带着
Web 应用在移动设备上浴火重生。所以满足 PWA
模型的前端控件,如纯前端表格控件SpreadJS,将逐渐成为移动操作系统的一等公民,并将向Native
APP发起挑战。

在下节中我们将带你一起去看看,PWA的原理是什么,以及它究竟是如何工作的,敬请期待。

1 赞 1 收藏
评论

图片 12

jQuery VS Zepto

首先,Zepto与jQuery的API大体相似,但是实现细节上差异甚大,我们使用Zepto一般完成两个操作:

① dom操作

② ajax处理

但是我们知道HTML5提供了一个document.querySelectorAll的接口,可以解决我们90%的需求,于是jQuery的sizzle便意义不大了,后来jQuery也做了一轮优化,让用户打包时候选择,需要sizzle才用。

其次jQuery的一些属性操作上做足了兼容,比如:

JavaScript

el.css(‘transform’, ‘translate(-968px, 0px) translateZ(0px)’)
//jQuery会自动根据不同浏览器内核为你处理为: el.css(‘-webkit-transform’,
‘translate(-968px, 0px) translateZ(0px)’)

1
2
3
el.css(‘transform’, ‘translate(-968px, 0px) translateZ(0px)’)
//jQuery会自动根据不同浏览器内核为你处理为:
el.css(‘-webkit-transform’, ‘translate(-968px, 0px) translateZ(0px)’)

又比如说,以下差异比比皆是:

JavaScript

el.hide(1000);//jQuery具有动画,Zepto不会鸟你

1
el.hide(1000);//jQuery具有动画,Zepto不会鸟你

然后,jQuery最初实现animate是采用js循环设置状态记录的方式,所以可以有效的记住状态暂停动画元素;Zepto的animate完全依赖于css3动画,暂停需要再想办法
图片 13 View
Code
其实,我们简单从实现上就可以看出,Zepto这里是偷懒了,其实现最初就没有想考虑IE,所以winphone根本不能愉快的玩耍

图片 14

JavaScript

zepto.Z = function(dom, selector) { dom = dom || [] dom.__proto__
= $.fn dom.selector = selector || ” return dom }

1
2
3
4
5
6
zepto.Z = function(dom, selector) {
  dom = dom || []
  dom.__proto__ = $.fn
  dom.selector = selector || ”
  return dom
}

图片 15

真实的差异还有很多,我这里也没法一一列出,这里要说明的一个问题其实就是:

jQuery大而全,兼容、性能良好;Zepto针对移动端定制,一些地方缺少兼容,但是尺寸小

1
jQuery大而全,兼容、性能良好;Zepto针对移动端定制,一些地方缺少兼容,但是尺寸小

图片 16

zepto设计的目的是提供jquery的类似的APIs,不以100%覆盖jquery为目的,一个5-10k的通用库、下载并执行快、有一个熟悉通用的API,所以你能把你主要的精力放到应用开发上。

上图是1.8版本与Zepto完整版的对比,Gzip在2G情况下20K造成的差距在2-5s之间,3G情况会有1s的差距,这也是我们选择Zepto的原因,下面简单介绍下Zepto。

错误冒泡

当然,有时候,请求可能不会按预期完成。IndexedDB
API通过错误冒泡功能来帮助跟踪和管理错误。如果一个特定的请求遇到错误,你可以尝试在请求对象上处理错误,或者你可以允许错误通过调用栈冒泡向上传递。这个冒泡天性,使得你不需要为每个请求实现特定错误处理操作,而是可以选择只在一个更高级别上添加错误处理,它给你一个机会,保持你的错误处理代码简洁。本文中实现的例子,是在一个高级别处理错误,以便更细粒度操作产生的任何错误冒泡到通用的错误处理逻辑。

Zepto清单

模块 建议 描述
ZEPTO Core module; contains most methods

核心模块,包含初始化Zepto对象的实现,以及dom选择器、css属性操作、dom属性操作

EVENT Event handling via on() & off()

Zepto事件处理库,包含整个dom事件的实现

AJAX XMLHttpRequest and JSONP functionality

Zepto ajax模块的实现

FORM Serialize & submit web forms

form表单相关实现,可以删去,移动端来说意义不大

IE Support for Internet Explorer 10+ on the desktop and Windows Phone 8

这个便是为上面那段实现还账的,几行代码将方法属性扩展至dom集合上(所以标准浏览器返回的是一个实例,ie返回的是一个加工后的数组)

DETECT  ✔ Provides $.os and $.browser information

设备判断,检测当前设备以及浏览器型号

FX  ✔ The animate() method

animate方法,这里叫fx模块有点让人摸不着头脑

FX_METHODS Animated showhidetoggle, and fade*() methods.

一些jQuery有的方法,Zepto没有的,这里做修复,比如fadeIn fadeOut意义不大

ASSETS Experimental support for cleaning up iOS memory after removing image elements from the DOM.

没有实际使用过,具体用处不明

DATA A full-blown data() method, capable of storing arbitrary objects in memory.

数据存储模块

DEFERRED Provides $.Deferred promises API. Depends on the “callbacks” module.

神奇的deferred模块,语法糖,为解决回调嵌套而生

CALLBACKS Provides $.Callbacks for use in “deferred” module.

服务于deferred,实际未使用过

SELECTOR   ✔ Experimental jQuery CSS extensions support for functionality such as$('div:first') and el.is(':visible').

扩展选择器,一些语法糖

TOUCH  X Fires tap– and swipe–related events on touch devices. This works with both touch (iOS, Android) and pointer events (Windows Phone).

提供简单手势库,这个大坑,谁用谁知道!!!几个有问题的地方:

① 事件直接绑定至document,性能浪费

② touchend时候使用settimeOut导致event参数无效,所以preventDefault无效,点透等情况也会发生

GESTURE Fires pinch gesture events on touch devices

对原生手势操作的封装

STACK Provides andSelf & end() chaining methods

语法糖,链式操作

IOS3 String.prototype.trim and Array.prototype.reduce methods (if they are missing) for compatibility with iOS 3.x.

没有用过

你真实项目时,完全可以按照需要选取模块即可,下面简单再列几个差异:

浏览器支持

也许在开发Web应用程序最重要的问题是:“浏览器是否支持我想要做的?“尽管浏览器对IndexedDB的支持在继续增长,采用率并不是我们所希望的那样普遍。图3显示了caniuse.com网站的报告,支持IndexedDB的为66%多一点点。最新版本的火狐,Chrome,Opera,Safar,iOS
Safari,和Android完全支持IndexedDB,Internet
Explorer和黑莓部分支持。虽然这个列表的支持者是令人鼓舞的,但它没有告诉整个故事。

图片 17

图3:浏览器对IndexedDB的支持,来自caniuse.com

只有非常新版本的Safari和iOS Safari
支持IndexedDB。据caniuse.com显示,这只占大约0.01%的全球浏览器使用。IndexedDB不是一个你认为能够理所当然得到支持的现代Web
API,但是你将很快会这样认为。

其它差异

① selector
如上所述,Zepto的选择器只是jQuery的一个子集,但是这个子集满足我们90%的使用场景

② clone
Zepto的clone不支持事件clone,这句话的意思是dom
clone后需要自己再处理事件,举个例子来说:

JavaScript

var el = $(‘.el’); el.on(‘click’, function() { alert(1) })

1
2
3
4
5
var el = $(‘.el’);
 
el.on(‘click’, function() {
  alert(1)
})

JavaScript

//true的情况jQuery会连带dom事件拷贝,Zepto没有做这个处理
//jQuery库,点击clone的节点会打印1,Zepto不会 var el1 = el.clone(true);
$(‘#wrap’).append(el1);

1
2
3
4
5
//true的情况jQuery会连带dom事件拷贝,Zepto没有做这个处理
//jQuery库,点击clone的节点会打印1,Zepto不会
 
var el1 = el.clone(true);
$(‘#wrap’).append(el1);

这个差异还比较好处理,现在都会使用事件代理,所以没clone事件也在没问题的……

这里简单看看细节实现:

JavaScript

clone: function (elem, dataAndEvents, deepDataAndEvents) { var i, l,
srcElements, destElements, clone = elem.cloneNode(true), inPage =
jQuery.contains(elem.ownerDocument, elem); // Fix IE cloning issues if
(!support.noCloneChecked && (elem.nodeType === 1 || elem.nodeType ===
11) && !jQuery.isXMLDoc(elem)) { // We eschew Sizzle here for
performance reasons: destElements =
getAll(clone); srcElements = getAll(elem); for (i = 0, l =
srcElements.length; i < l; i++) { fixInput(srcElements[i],
destElements[i]); } } // Copy the events from the original to the
clone if (dataAndEvents) { if (deepDataAndEvents) { srcElements =
srcElements || getAll(elem); destElements = destElements ||
getAll(clone); for (i = 0, l = srcElements.length; i < l; i++) {
cloneCopyEvent(srcElements[i], destElements[i]); } } else {
cloneCopyEvent(elem, clone); } } // Preserve script evaluation history
destElements = getAll(clone, “script”); if (destElements.length > 0)
{ setGlobalEval(destElements, !inPage && getAll(elem, “script”)); } //
Return the cloned set return clone; }, function cloneCopyEvent(src,
dest) { var i, l, type, pdataOld, pdataCur, udataOld, udataCur, events;
if (dest.nodeType !== 1) { return; } // 1. Copy private data: events,
handlers, etc. if (dataPriv.hasData(src)) { pdataOld =
dataPriv.access(src); pdataCur = dataPriv.set(dest, pdataOld); events =
pdataOld.events; if (events) { delete pdataCur.handle; pdataCur.events =
{}; for (type in events) { for (i = 0, l = events[type].length; i <
l; i++) { jQuery.event.add(dest, type, events[type][i]); } } } } //

  1. Copy user data if (dataUser.hasData(src)) { udataOld =
    dataUser.access(src); udataCur = jQuery.extend({}, udataOld);
    dataUser.set(dest, udataCur); } }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
clone: function (elem, dataAndEvents, deepDataAndEvents) {
   var i, l, srcElements, destElements,
         clone = elem.cloneNode(true),
         inPage = jQuery.contains(elem.ownerDocument, elem);
 
   // Fix IE cloning issues
   if (!support.noCloneChecked && (elem.nodeType === 1 || elem.nodeType === 11) &&
             !jQuery.isXMLDoc(elem)) {
 
     // We eschew Sizzle here for performance reasons: http://jsperf.com/getall-vs-sizzle/2
     destElements = getAll(clone);
     srcElements = getAll(elem);
 
     for (i = 0, l = srcElements.length; i < l; i++) {
       fixInput(srcElements[i], destElements[i]);
     }
   }
 
   // Copy the events from the original to the clone
   if (dataAndEvents) {
     if (deepDataAndEvents) {
       srcElements = srcElements || getAll(elem);
       destElements = destElements || getAll(clone);
 
       for (i = 0, l = srcElements.length; i < l; i++) {
         cloneCopyEvent(srcElements[i], destElements[i]);
       }
     } else {
       cloneCopyEvent(elem, clone);
     }
   }
 
   // Preserve script evaluation history
   destElements = getAll(clone, "script");
   if (destElements.length > 0) {
     setGlobalEval(destElements, !inPage && getAll(elem, "script"));
   }
 
   // Return the cloned set
   return clone;
},
function cloneCopyEvent(src, dest) {
   var i, l, type, pdataOld, pdataCur, udataOld, udataCur, events;
 
   if (dest.nodeType !== 1) {
     return;
   }
 
   // 1. Copy private data: events, handlers, etc.
   if (dataPriv.hasData(src)) {
     pdataOld = dataPriv.access(src);
     pdataCur = dataPriv.set(dest, pdataOld);
     events = pdataOld.events;
 
     if (events) {
       delete pdataCur.handle;
       pdataCur.events = {};
 
       for (type in events) {
         for (i = 0, l = events[type].length; i < l; i++) {
           jQuery.event.add(dest, type, events[type][i]);
         }
       }
     }
   }
 
   // 2. Copy user data
   if (dataUser.hasData(src)) {
     udataOld = dataUser.access(src);
     udataCur = jQuery.extend({}, udataOld);
 
     dataUser.set(dest, udataCur);
   }
}

JavaScript

clone: function(){ return this.map(function(){ return
this.cloneNode(true) }) },

1
2
3
clone: function(){
  return this.map(function(){ return this.cloneNode(true) })
},

下面是Zepto的clone实现,我啥也不说了,为什么jQuery这么大呢,是有道理的。

③ data

Zepto的data只能存储字符串,你想存储复杂对象的话便把他先转换为字符串

④ offset

图片 18

JavaScript

el.offset() //Zepto返回 Object {left: 8, top: 8, width: 485, height: 18}
//jQuery返回 Object {top: 8, left: 8}

1
2
3
4
5
6
7
el.offset()
 
//Zepto返回
Object {left: 8, top: 8, width: 485, height: 18}
 
//jQuery返回
Object {top: 8, left: 8}

图片 19

getBoundingClientRect 函数是W3C组织在第一版本的W3C CSSOM View
specification草案中确定的一个标准方法,在此之前,只有IE浏览器是支持该方法的,W3C在这次草案中把它扶正成为标准。

getBoundingClientRect
方法返回的是调用该方法的元素的TextRectangle对象,该对象具有top、left、right、bottom四个属性,分别代表该元素上、左、右、下四条边界相对于浏览器窗口左上角(注意,不是文档区域的左上角)的偏移像素值。

JavaScript

offset: function(coordinates){ if (coordinates) return
this.each(function(index){ var $this = $(this), coords = funcArg(this,
coordinates, index, $this.offset()), parentOffset =
$this.offsetParent().offset(), props = { top: coords.top –
parentOffset.top, left: coords.left – parentOffset.left } if
($this.css(‘position’) == ‘static’) props[‘position’] = ‘relative’
$this.css(props) }) if (this.length==0) return null var obj =
this[0].getBoundingClientRect() return { left: obj.left +
window.pageXOffset, top: obj.top + window.pageYOffset, width:
Math.round(obj.width), height: Math.round(obj.height) } },

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
offset: function(coordinates){
  if (coordinates) return this.each(function(index){
    var $this = $(this),
        coords = funcArg(this, coordinates, index, $this.offset()),
        parentOffset = $this.offsetParent().offset(),
        props = {
          top:  coords.top  – parentOffset.top,
          left: coords.left – parentOffset.left
        }
 
    if ($this.css(‘position’) == ‘static’) props[‘position’] = ‘relative’
    $this.css(props)
  })
  if (this.length==0) return null
  var obj = this[0].getBoundingClientRect()
  return {
    left: obj.left + window.pageXOffset,
    top: obj.top + window.pageYOffset,
    width: Math.round(obj.width),
    height: Math.round(obj.height)
  }
},

JavaScript

   jQuery offsetoffset: function (options) { if (arguments.length) {
return options === undefined ? this : this.each(function (i) {
jQuery.offset.setOffset(this, options, i); }); } var docElem, win, elem
= this[0], box = { top: 0, left: 0 }, doc = elem &&
elem.ownerDocument; if (!doc) { return; } docElem = doc.documentElement;
// Make sure it’s not a disconnected DOM node if
(!jQuery.contains(docElem, elem)) { return box; } // Support: BlackBerry
5, iOS 3 (original iPhone) // If we don’t have gBCR, just use 0,0 rather
than error if (typeof elem.getBoundingClientRect !== strundefined) { box
= elem.getBoundingClientRect(); } win = getWindow(doc); return { top:
box.top + win.pageYOffset – docElem.clientTop, left: box.left +
win.pageXOffset – docElem.clientLeft }; },

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
 
 jQuery offsetoffset: function (options) {
  if (arguments.length) {
    return options === undefined ?
            this :
            this.each(function (i) {
              jQuery.offset.setOffset(this, options, i);
            });
  }
 
  var docElem, win,
        elem = this[0],
        box = { top: 0, left: 0 },
        doc = elem && elem.ownerDocument;
 
  if (!doc) {
    return;
  }
 
  docElem = doc.documentElement;
 
  // Make sure it’s not a disconnected DOM node
  if (!jQuery.contains(docElem, elem)) {
    return box;
  }
 
  // Support: BlackBerry 5, iOS 3 (original iPhone)
  // If we don’t have gBCR, just use 0,0 rather than error
  if (typeof elem.getBoundingClientRect !== strundefined) {
    box = elem.getBoundingClientRect();
  }
  win = getWindow(doc);
  return {
    top: box.top + win.pageYOffset – docElem.clientTop,
    left: box.left + win.pageXOffset – docElem.clientLeft
  };
},

差距不大,jQuery的更加严谨,总会做很多兼容,jQuery大是有道理的

另一种选择

浏览器支持本地数据库并不是从IndexedDB才开始实现,它是在WebSQL实现之后的一种新方法。类似IndexedDB,WebSQL是一个客户端数据库,但它作为一个关系数据库的实现,使用结构化查询语言(SQL)与数据库通信。WebSQL的历史充满了曲折,但底线是没有主流的浏览器厂商对WebSQL继续支持。

如果WebSQL实际上是一个废弃的技术,为什么还要提它呢?有趣的是,WebSQL在浏览器里得到稳固的支持。Chrome,
Safari, iOS Safari, and
Android 浏览器都支持。另外,并不是这些浏览器的最新版本才提供支持,许多这些最新最好的浏览器之前的版本也可以支持。有趣的是,如果你为WebSQL添加支持来支持IndexedDB,你突然发现,许多浏览器厂商和版本成为支持浏览器内置数据库的某种化身。

因此,如果您的应用程序真正需要一个客户端数据库,你想要达到的最高级别的采用可能,当IndexedDB不可用时,也许您的应用程序可能看起来需要选择使用WebSQL来支持客户端数据架构。虽然文档数据库和关系数据库管理数据有鲜明的差别,但只要你有正确的抽象,就可以使用本地数据库构建一个应用程序。

MVC框架选择

MVC框架流行的有Backbone、angularJS、reactJS、canJS等,我个人比较熟悉Backbone与canJS,近期也在整理canJS的一些笔记

首先提一下Backbone,我认为其最优秀的就是其View一块的实现,Backbone的View规范化了dom事件的使用,避免了事件滥用,避免了事件“失效”

但是Backbone的路由处理一块很弱,事实上一点用也没有,而且就算view一块的继承关系也非常难以处理,extend实现是:

JavaScript

var extend = function (protoProps, staticProps) { var parent = this; var
child; // The constructor function for the new subclass is either
defined by you // (the “constructor” property in your `extend`
definition), or defaulted // by us to simply call the parent’s
constructor. if (protoProps && _.has(protoProps, ‘constructor’)) {
child = protoProps.constructor; } else { child = function () { return
parent.apply(this, arguments); }; } // Add static properties to the
constructor function, if supplied. _.extend(child, parent,
staticProps); // Set the prototype chain to inherit from `parent`,
without calling // `parent`’s constructor function. var Surrogate =
function () { this.constructor = child; }; Surrogate.prototype =
parent.prototype; child.prototype = new Surrogate; // Add prototype
properties (instance properties) to the subclass, // if supplied. if
(protoProps) _.extend(child.prototype, protoProps); // Set a
convenience property in case the parent’s prototype is needed // later.
child.__super__ = parent.prototype; return child; };

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
var extend = function (protoProps, staticProps) {
  var parent = this;
  var child;
 
  // The constructor function for the new subclass is either defined by you
  // (the "constructor" property in your `extend` definition), or defaulted
  // by us to simply call the parent’s constructor.
  if (protoProps && _.has(protoProps, ‘constructor’)) {
    child = protoProps.constructor;
  } else {
    child = function () { return parent.apply(this, arguments); };
  }
 
  // Add static properties to the constructor function, if supplied.
  _.extend(child, parent, staticProps);
 
  // Set the prototype chain to inherit from `parent`, without calling
  // `parent`’s constructor function.
  var Surrogate = function () { this.constructor = child; };
  Surrogate.prototype = parent.prototype;
  child.prototype = new Surrogate;
 
  // Add prototype properties (instance properties) to the subclass,
  // if supplied.
  if (protoProps) _.extend(child.prototype, protoProps);
 
  // Set a convenience property in case the parent’s prototype is needed
  // later.
  child.__super__ = parent.prototype;
 
  return child;
};

JavaScript

child.__super__ = parent.prototype;

1
child.__super__ = parent.prototype;

这是一段极为糟糕的设计,他是将parent原型的指向给到了类的的属性上,这里可以看做静态方法,那么我在实际使用的时候要如何使用呢?

我在内部原型链上或者实例方法一般使用this便能指向本身,但是却不能执行本类的方法,如果要使用指向构造函数我需要这么做:

JavaScript

this.constructor this.constructor.__super__

1
2
this.constructor
this.constructor.__super__

如果我这里想要执行父类的一个方法,还得关注起作用域指向,于是只能这样写

JavaScript

this.constructor.__super__.apply(this, arguments)

1
this.constructor.__super__.apply(this, arguments)

而我总是认为javascript的construct未必非常靠谱,于是整个人都不好了,所以在一轮使用后,基本便放弃Backbone了,但是Backbone优秀的一面也不能抹杀,我们可以借鉴Backbone实现一些更加适合项目的基础架子

Backbone另一个令人诟病的地方是其插件少,其实这里有点苛刻,移动端才兴起不久,webapp的项目又少,这里没有是很正常,别人的插件也未必能用的顺心。

angularJs我本身没有实际使用过,不好评价,根据一些朋友的实际使用情况可以得出一个结论:

JavaScript

规定的非常死,业务代码可保持一致,入门简单深入难,一旦出现问题,不太好改,对技术要求较高

1
规定的非常死,业务代码可保持一致,入门简单深入难,一旦出现问题,不太好改,对技术要求较高

这里各位根据实际情况选择就好,我这里的建议还是自己读懂一个MV*的框架,抽取需要的重写,像angularJS一次升级,之前的项目如何跟着升级,这些问题很头疼也很实际。

上次抱着解决webappSEO难题时候对reactJS有所接触,其源码洋洋洒洒10000行,没有一定功力与时间还是暂时不碰为好。

canJS学习成本与Backbone差不多,我这边准备出系列学习笔记,好不好后面调研再说。

总结一句:不建议直接将业务库框架直接取来使用,更不建议使用过重的业务框架,最好是能明白框架想要解决的问题,与自己项目的实际需求,自己造轮子知根知底。

IndexedDB是否适合我的应用程序?

现在最关键的问题:“IndexedDB是否适合我的应用程序?“像往常一样,答案是肯定的:“视情况而定。“首先当你试图在客户端保存数据时,你会考虑HTML5本地存储。本地存储得到广泛浏览器的支持,有非常易于使用的API。简单有其优势,但其劣势是无法支持复杂的搜索策略,存储大量的数据,并提供事务支持。

IndexedDB是一个数据库。所以,当你想为客户端做出决定,考虑你如何在服务端选择一个持久化介质的数据库。你可能会问自己一些问题来帮助决定客户端数据库是否适合您的应用程序,包括:

  • 你的用户通过浏览器访问您的应用程序,(浏览器)支持IndexedDB API吗 ?
  • 你需要存储大量的数据在客户端?
  • 你需要在一个大型的数据集合中快速定位单个数据点?
  • 你的架构在客户端需要事务支持吗?

如果你对其中的任何问题回答了“是的”,很有可能,IndexedDB是你的应用程序的一个很好的候选。

框架建议

最好给出一个小小的建议,希望对各位有用:

第三方库(基础库):

requireJS+Zepto+阉割版underscore(将其中不太用到的方法去掉,主要使用模板引擎一块)+
Fastclick

MVC库/UI库:

建议自己写,不要太臃肿,可以抄袭,可以借鉴,不要完全拿来就用

这样出来的一套框架比较轻量级,知根知底,不会出现改不动的情况,最后提一句:不经过调研,没有实际场景在框架中玩模式,玩高级理念死得快,不要为技术而技术。

使用IndexedDB

现在,你已经有机会熟悉了一些的整体概念,下一步是开始实现基于IndexedDB的应用程序。第一个步骤需要统一IndexedDB在不同浏览器的实现。您可以很容易地添加各种厂商特性的选项的检查,同时在window对象上把它们设置为官方对象相同的名称。下面的清单展示了window.indexedDB,window.IDBTransaction,window.IDBKeyRange的最终结果是如何都被更新,它们被设置为相应的浏览器的特定实现。

JavaScript

window.indexedDB = window.indexedDB || window.mozIndexedDB ||
window.webkitIndexedDB || window.msIndexedDB; window.IDBTransaction =
window.IDBTransaction || window.webkitIDBTransaction ||
window.msIDBTransaction; window.IDBKeyRange = window.IDBKeyRange ||
window.webkitIDBKeyRange || window.msIDBKeyRange;

1
2
3
4
5
6
7
8
9
10
window.indexedDB = window.indexedDB ||
                   window.mozIndexedDB ||
                   window.webkitIndexedDB ||
                   window.msIndexedDB;
window.IDBTransaction = window.IDBTransaction ||
                   window.webkitIDBTransaction ||
                   window.msIDBTransaction;
window.IDBKeyRange = window.IDBKeyRange ||
                   window.webkitIDBKeyRange ||
                   window.msIDBKeyRange;

现在,每个数据库相关的全局对象持有正确的版本,应用程序可以准备使用IndexedDB开始工作。

网站是如何变慢的?

应用概述

在本教程中,您将学习如何创建一个使用IndexedDB存储数据的模块化JavaScript应用程序。为了了解应用程序是如何工作的,参考图4,它描述了任务应用程序处于空白状态。从这里您可以为列表添加新任务。图5显示了录入了几个任务到系统的画面。图6显示如何删除一个任务,图7显示了正在编辑任务时的应用程序。

图片 20

图4:空白的任务应用程序

图片 21

图5:任务列表

图片 22

图6:删除任务

图片 23

图7:编辑任务
现在你熟悉的应用程序的功能,下一步是开始为网站铺设基础。

尺寸——慢的根源

兵无定势,水无常形,按照之前所说,我们选取了对我们最优的框架,做出来的网站应该很快,但第一轮需求结束后有第二轮,第二轮需求结束后有第三轮,网站版本会从1.1-X.1,业务的增长以及市场份额的角力带来的是一月一发布,一季一轮替,没有不变的道理。

框架最大的敌人是需求,代码最大的敌人是变更,最开始使用的是自己熟悉的技术,突然一天多出了一些莫名其妙的场景:

① webapp模式很不错,为了快速业务发展,将接入Hybrid技术,并且使用一套代码

② 微信入口已经很火了,为了快速业务发展,将接入微信入口,并且使用一套代码

③ UI组件已经旧了,换一批ios8风格的组件吧

④ 全站样式感觉跟不上潮流了,换一套吧

网站变慢的核心原因是尺寸的膨胀,尺寸优化才是前端优化的最重要命题,①、②场景是不可预知场景,面对这种不可预知场景,会写很多桥接的代码,而这类代码往往最后都会证明是不好的!

框架首次处理未知场景所做的代码,往往不是最优的,如Hybrid、如微信入口

1
框架首次处理未知场景所做的代码,往往不是最优的,如Hybrid、如微信入口

剩下两个场景是可预见的改变,但是此类变更会带来另一个令人头疼的问题,新老版本交替。业务20多个业务团队,不可能一个版本便全部改变,便有个逐步推进的过程。

全站样式替换/对未知场景的代码优化,很多时候为了做到透明,会产生冗余代码,为了做兼容,常常有很长一段时间新老代码共存的现象

1
全站样式替换/对未知场景的代码优化,很多时候为了做到透明,会产生冗余代码,为了做兼容,常常有很长一段时间新老代码共存的现象

于是不可预知造成的尺寸膨胀,经过重构优化,而为了做兼容,居然会造成尺寸进一步的增加

所谓优化不一定马上便有效果,开发人员是否扛得住这种压力,是否有全团队推动的能力会变得比本身技术能力更加重要

1
所谓优化不一定马上便有效果,开发人员是否扛得住这种压力,是否有全团队推动的能力会变得比本身技术能力更加重要

事实上的情况复杂的多,以上只是一厢情愿的以“接口统一”、“透明升级”为前提,但是透明的代价是要在重构代码中做兼容,而兼容又本身是需要重构掉的东西,当兼容产生的代码比优化还多的时候,我们可能就会放弃兼容,而提供一套接口完全不统一的东西;更加真实情况是我们根本不会去做这种对比,便直接将老接口废掉,这个时候造成的影响是“天怒人怨”,但是我们爽了,爽了的代价是单个团队的推动安抚。

这里请参考angularJS升级,新浪微博2.0接口与1.1不兼容问题,这里的微信接口提出,难保一年后不会完全推翻……

所以,尺寸变大的主要原因是因为冗余代码的产生,如何消除冗余代码是一个重点,也是一个难点。

铺设基础

这个例子从实现这样一个模块开始,它负责从数据库读取数据,插入新的对象,更新现有对象,删除单个对象和提供在一个object
store删除所有对象的选项。这个例子实现的代码是通用的数据访问代码,您可以在任何object
store上使用。

这个模块是通过一个立即执行函数表达式(IIFE)实现,它使用对象字面量来提供结构。下面的代码是模块的摘要,说明了它的基本结构。

JavaScript

(function (window) { ‘use strict’; var db = { /* implementation here
*/ }; window.app = window.app || {}; window.app.db = db; }(window));

1
2
3
4
5
6
7
8
(function (window) {
    ‘use strict’;
    var db = {
        /* implementation here */
    };
    window.app = window.app || {};
    window.app.db = db;
}(window));

用这样的结构,可以使这个应用程序的所有逻辑封装在一个名为app的单对象上。此外,数据库相关的代码在一个叫做db的app子对象上。

这个模块的代码使用IIFE,通过传递window对象来确保模块的适当范围。使用use
strict确保这个函数的代码函数是按照(javascript严格模式)严格编译规则。db对象作为与数据库交互的所有函数的主要容器。最后,window对象检查app的实例是否存在,如果存在,模块使用当前实例,如果不存在,则创建一个新对象。一旦app对象成功返回或创建,db对象附加到app对象。

本文的其余部分将代码添加到db对象内(在implementation
here会
评论),为应用程序提供特定于数据库的逻辑。因此,如你所见本文后面的部分中定义的函数,想想父db对象移动,但所有其他功能都是db对象的成员。完整的数据库模块列表见清单2。

版本轮替——哪些能删的痛点

数月后,20多个团队悉数切入到最新的框架,另一个令人头疼的问题马上又出来了,虽然大家样式都接入到最新的风格了,但是老的样式哪些能删?哪些不能删又是一个令人头疼的问题。

几个月前维护CSS同事嫌工资低了,换了一个同事维护全站基础css;再过了一段时间,组织架构调整,又换了一个同事维护;再过了一段时间,正在维护css的同事觉得自己级别低了,在公司内部等待晋级确实熬不住,于是也走了。这个基础css俨然变成了一笔烂账,谁也不敢删,谁也不愿意动,动一下错一下。

这个问题表面上看是一个css问题,其实这是一个前端难题,也是过度解耦,拆分机制不正确带来的麻烦。

CSS是前端不可分割的一部分,HTML模板与Javascript可以用requireJS处理,很大程度上解决了javascript变量污染的问题,css一般被一起分离了出来,单独存放。一个main.css包含全站重置的样式,表单、列表、按钮的基础样式,完了就是全站基础的UI组件。

总有业务团队在实际做项目时会不自主的使用main.css中的一些功能,如果只是使用了基础的重置还好,但是一旦真的使用其中通用的表单、列表等便2B了

main.css的初衷当然是将各个业务团队通用的部分提炼出来,事实上也该这样做,但理想很丰满,现实很残酷,不同的人对SEO、对语义化对命名的理解不太一样,换一个人就会换一套东西。第一批项目上线后,过了几个月,开发人员成长非常巨大,对原来的命名结构,完全不削一顾,自己倒腾出一套新的东西,让各个团队换上去,其它团队面对这种要求是及其头疼的,因为各个团队会有自己的CSS团队,这样一搞势必该业务团队的HTML结构与CSS要被翻新一次,这样的意义是什么,便不太明显了。2个星期过去了,新一批“规范化”的结构终于上线了,2个月后所有的业务团队全部接了新的结构,似乎皆大欢喜,但是那个同事被另一个团公司挖过去当前端leader了,于是一大群草泥马正在向业务团队的菊花奔腾过去!这里的建议是:

业务团队不要依赖于框架的任何dom结构与css样式,特别不要将UI组件中的dom结构与样式单独抠出来使用,否则就准备肥皂吧

1
业务团队不要依赖于框架的任何dom结构与css样式,特别不要将UI组件中的dom结构与样式单独抠出来使用,否则就准备肥皂吧

发表评论

电子邮件地址不会被公开。 必填项已用*标注