112018.7

这几天真的是下了苦心,把之前的四个包完完整整的重写了一遍,并将作为自己今后开发的开箱必用包,它们分别是hello-events(事件绑定与触发管理),hello-storage(localStorage等本地化存储简化操作),hello-worker(webworker简便使用),hello-indexeddb(超简单indexeddb使用包),接下来打算把之前写的datamanaer.js重写一下,要用hello-什么做名字还没想好,但是肯定会是最完美的前端数据获取模式。完成这个之后,就是要把hst-virtual-dom再重写一遍,把之前写的toex用上,这样就可以让virtual dom这块完美收官了。

01:12:30 已有0条回复
092018.7

Blob和ArrayBuffer的区别

周末趁没事,就把之前写的一个包重新写了一遍。这个包的作用是为开发者提供更加快捷的indexedDB操作,免除一切烦恼,开箱就用起来。indexedDB是web标准,被大部分现代浏览器完整支持。和localStorage不同的是,indexedDB是真的完整存储js对象的引擎,它甚至支持存储new Date()的值,其他一些基础的js对象类型也可能是支持的。而localStorage是只能存储字符串的,要存储对象,必须通过JSON等进行序列化,而JSON不支持循环嵌套。另外一点就是,localStorage是同步的,indexedDB是异步的。

基于对复杂的indexedDB原生接口进行封装的思路,我发布了hello-indexeddb这个包,可以通过下面这个命令安装

npm install --save hello-indexeddb

完整的文档在github上,可以点击这里阅读。都是key-value数据库,它和localStorage的本质区别在哪里呢?我认为数据库的本质能力是分层检索能力。检索能力对于localStorage简直就是无,它只能通过一个key得到一个value,而且是字符串的。而indexedDB可以通过创建索引进行检索,查询某个object的时候,可以通过主键快速get,也可以通过索引来快速query,这里的索引在代码层面就是一个被记录的object的属性。这看上去好像也没什么,比如我可以通过构造多种变形的key来保存localStorage,然后自己封装一套检索方法来进行查询,甚至我自己构建一套localStorage的索引来快速查询。这当然是可以的,从这点上来讲,indexedDB甚至没有localStorage有优势,因为localStorage是同步的,更直观,而且不会出现事件循环错误,也就不需要事务机制。但是同步有同步的坏处,那就是阻塞页面进程。

读完stackoverflow上的这个讨论后我更加确信localStorage是有局限的,也就是说,它真的真的仅仅适合那些非常小、碎片化的数据存储,而indexedDB才是完整的长久存储数据的解决方案。这也就是说,在一个web应用中,应该合理的选择使用localStorage还是indexedDB。大家之所以那么青睐使用localSotrage,最大的原因莫过于它的接口太过简单了。不过想要让indexedDB变得简单也非常容易,就是使用我上面的包。你甚至可以这么用:

async function() {
let idb = new HelloIndexedDB({ key: 'key' })
await idb.put({ key: 'my_key', value: 'my_value' })
let obj = await idb.get('my_key')
}

就是这么简单,跟localStorage相比,就是异步和同步的区别。在对put这个操作的适合,转换一下localStorage里面的set操作的思维,然后,就非常自然的切换到了indexedDB的怀抱里面。要知道,get回来的,是一个拥有上下文的真实的js对象,而非字符串序列化和反序列化的结果。

就这样,拥抱indexedDB吧~

01:27:00 已有0条回复
072018.7

写代码的时候,经常会有几个概念容易混淆,即update, set, put, patch。这几个单词在我们编程过程中经常会出现,我们自己在给方法取名字的时候,也常常不知道该用哪一个好。据一个例子,当你想要将用户修改好的个人信息保存到数据库时,应该用哪一个单词呢?现在我就来具体解释一下它们的使用场景。

set:将对象塞入到集合中,无论这个对象是否在集合中已经存在。这里有一个隐藏的风险,如果这个对象在集合中已经存在了,那么当你set的对象比原来的对象少了一些属性的时候,这些属性就丢失了。在这种情况下,set相当于replace。而如果这个对象本身不存在于集合中,那么set就相当于add了。

update:对传入的对象进行更新。首先,它要更新的内容虽然是对象,但你不确定它的个数;其次,它在更新时并不像set一样进行直接替换,而是对传入update中参数中规定的属性进行更新,因此,参数中未规定的属性保持不变;最后,它只是更新,不会附带add操作。update是一个比较高度抽象的词,因此,你实在不知道应该选用哪个词作为更新操作的时候,用update就行了。

put:和set非常接近。从词语本身看,set更多倾向于replace,put更多倾向于add。put的前提是在集合中已经存在一个位置(空位),而put操作准确的将参数对象放入这个位置。但是实际中,大部分规则下,put被赋予replace的功能。因此,在编程时,可以说put和set没有区别。

patch:和update非常接近,但仅对单个对象进行update,而update可以对一组对象进行更新。在restful中patch和put一样也被定义为更新操作。实际上,我认为patch是对但对象的update,而put被大部分人误解。restful中,大部分人将put定义为更新操作,即对但对象的update操作。但我认为,put既不是update,也不是add,而是这两者的整合,也就是上面说的set的逻辑(repalce/add)。但是patch非常明确,就是对单个对象的更新,因此,在restful设计中应该考虑用patch,而非put。

 

写方法的时候,我们常常会有两种方式,一种是set(key, value)的形式,另一种是set({ key: value })的形式。显然,第一种只能一次更新一个属性,而第二种可以同时更新多个属性。但是很明显,这里如果我们把set理解为上文阐述的意义,那么只能选择第一种形式,它代表将一个对象的某个属性整体替换为(如果不存在则添加)新内容。而第二种形式更适合patch,即我在知道我要更新哪一个对象时(常常通过url确定),我只传入我想要更新的属性名和值。但是在不知道我要更新哪个对象时,则不应该使用patch,而应该用update,并且要求在传入的对象中,提供明确的主键值。

18:02:00 已有0条回复
062018.7

简单package的简单构建脚本

在前段时间,我把之前写的几个package重新命名为hello开头的包,例如hello-storage, hello-events, hello-worker,这些包非常基础,不依赖任何第三方包,就是用基础的api来实现的,因此,代码非常简单。面对这种随即编写,随即打包发布的package,我采用最小化的方式进行发布。

一个包,在发布的时候,其实最重要的是考虑用户(开发者)使用这个包的使用场景,如果不考虑,直接给源码就行了,干嘛还要进行构建发布呢?所以,对于我而言,主要考虑两点:

  • 模块化
  • 代码兼容性

-

模块化是指用户可能在不同的模块规范下使用你的包,目前而言,有amd, cmd, commonjs, es6 module这几种,另外,还要考虑在浏览器中直接使用<script>标签引用脚本(没有模块化环境)。针对这点,我采用umd的方案,但是代码是自己写的,我的源码是es6 module,因此在导出的时候使用export default,但是在其他模块化规范下,并不需要default这样的接口,因此要直接export整个模块,因此,我的方案就是,对于要直接引用es6模块的用户,建议他import源码文件,而其他模块化规范下,引用dist文件:

// ES6
import HelloEvents from 'hello-events/src/hello-events'

// CommonJS
const HelloEvents = require('hello-events')

// 由于webpack在打包时能正确处理export default的问题,因此如果使用webpack,可以
import HelloEvents from 'hello-events'

对于开发者而言,这种解释应该是非常容易理解的。使用习惯上也不会造成困扰。那么怎么来实现这套方案呢?我在代码中采用umd的方案实现:

!function(root) {

// ES6代码转码之后放在这里

if (typeof define === 'function' && (define.cmd || define.amd)) { // amd | cmd
  define(function(require, exports, module) {
    module.exports = HelloEvents;
  });
}
else if (typeof module !== 'undefined' && module.exports) {
  module.exports = HelloEvents;
}
else {
  root.HelloEvents = HelloEvents;
}

} (this || window);

这得益于我以前写过omd.js。那怎么才能最终输出上面这个结构呢?我使用了gulp来做,并用上了我写的gulp-bufferify包来实现文件内容的修改。这样,当我使用babel把es6的代码转化为es5的代码之后,再对文件内容进行修改,就能得到上面这个结构了。

-

代码兼容性是指要考虑在不同浏览器版本中代码都能跑,主要是指一些es6新特性的降级,例如async函数。因为我写的这些pacakge的功能非常弱,不会涉及generator函数,也不会涉及symbol,因此其他大部分功能都可以用es5语法代替,并且找到对应的babel插件即可。

对于我而言,主要考虑到两个点:1.class语法;2.async/await语法;3. ...语法。这三个语法已经是我日常写作的必须品,因此在我的构建脚本里面,首先需要将这三个语法转化为es5语法。1和3使用babel-preset-env就可以自动解决,非常好用,2的话我使用了bebel-plugin-async-to-promises,它可以将async/await语法转换为promise,而preset-env默认使用bebel-plugin-transform-async-to-generator(将async/await语法转换为generator语法)和bebel-plugin-transform-regenerator(使用一个特殊的变量regeneratorRuntime来支持generator语法,这个变量需要你引入babel-polyfill),这两个插件和bebel-plugin-async-to-promises有冲突,因此要禁用默认选项,在.babelrc里面这样写:

{
  "presets": [
    ["env", { "exclude": ["transform-async-to-generator", "transform-regenerator"] }]
  ],
  "plugins": [
    "async-to-promises"
  ]
}

但是,其实这里对于开发者而言,是需要进行权衡的,比如说,我会在代码中随意使用array.filter, Object.assign等,这些新接口是es6新加入的,对于老版本的浏览器是不支持的。但是这些接口不会被babel转译,因此,我也不会特意在自己的代码中去实现这一块。之所以不自己在代码中实现这块,是因为这种接口很大程度上其他包也会用。对于使用包的开发者而言,他需要自己进行权衡,是不是要引入一个polyfill,如果他自己不想支持低版本的浏览器,就不用引入了。这样,可以保证我自己的包里面的代码是绝对干净,但是在大部分情况下是可以运行的。

但是这里有一个问题,就是为什么不把async/await也留给上层的开发者自己去决定。这是因为这个语法没有办法用polyfill,你不可能通过一个polyfill让一个不支持async语法的浏览器变得支持。这就是权衡,如果我在自己的所有包里面都把这两个语法的转译代码写进去,那么最后,上层开发者的应用里面,就会有重复代码,这也是没有办法的,如果webpack等打包工具更加智能,就可以将这些重复代码提升作用域来实现减少重复的效果。

-

上面讲完了我所关心的两个点之后,下面要出代码了。不过别急。我们再讨论一个问题,就是有没有必要任何包都用webpack?答案显而易见,我现在开始不大喜欢webpack,我越来越觉得webpack应该是一个应用层面进行打包时才用的上的工具,对于一个package而言,不应该进行打包,而是以原始的module文件间引用关系对外使用,只不过需要做上述两个点的处理。

好了,上代码:

// 安装对应的npm包
$ npm i -D babel-core babel-plugin-async-to-promises babel-preset-env gulp gulp-babel gulp-bufferify
// 构建脚本 build.js

var gulp = require('gulp')
var bufferify = require('gulp-bufferify').default
var babel = require('gulp-babel')

var namespace = 'HelloWorker' // 修改为自己的ClassName,一定要跟源码里面的class名对应
var entryfile = 'src/hello-worker.js' // 修改为自己的入口文件

gulp.src(entryfile)
  .pipe(babel())
  .pipe(bufferify(function(content) {

    content = content.replace(/Object\.defineProperty\(exports,[\s\S]+?\);/gm, '')
    content = content.replace(`exports.default = ${namespace};`, '')
    content = `
!function(root) {

${content}

if (typeof define === 'function' && (define.cmd || define.amd)) { // amd | cmd
  define(function(require, exports, module) {
    module.exports = ${namespace};
  });
}
else if (typeof module !== 'undefined' && module.exports) {
  module.exports = ${namespace};
}
else {
  root.${namespace} = ${namespace};
}

} (this || window);
    `
    content = content.trim()
    content += "\n"

    return content
  }))
  .pipe(gulp.dest('dist'))
// 进行构建
node build.js

这段构建脚本非常简单,稍微花点时间就读懂了。根据自己的实际情况进行修改,比如路径问题,比如namespace那个地方。总之对于我自己而言,非常简单的包都会采用这样的模式去做。

19:03:52 已有0条回复
022018.7

HTML5 File API

http://www.cnblogs.com/zichi/p/html5-file-api.html