Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

闲扯状态 API 与 XMLHttpRequest 的设计

  最近我越来越讨厌带状态的 API 设计了,特别是存在很多异步操作的对象上。也许正常使用没什么太大影响,一旦要深究其底层逻辑,带状态的 API 就会出现大堆奇怪的临界情况。如果用严谨的语言去描述一套有状态 API 那一定比描述无状态 API 要费事得多!
  XMLHttpRequest 对象就是个坑!它的设计是有状态的。虽然 readyState 只有 0 到 4 这么 5 个简单的状态,但我想很多人都无法完全说出这所有的状态分别底表示什么吧?更何况还有一堆硬逻辑来描述哪些状态下哪些属性可方法是不可用的,这要是问我我也说不出。要想完全驾驭它就必须把厚厚的一本文档背下来,所以这就是一套糟糕的 API 设计。
  很多库或框架都封装了 XMLHttpRequest,一方面是 IE 兼容没错,但我觉得更主要的原因是它实在太难用了。如果它足够好用的话人们可能会实现一个 polyfill 而不是直接重新封装。
  以前 XMLHttpRequest 没有 onload 事件的时候要在 onreadystatechange 事件中判断 readyState 是不是为 4,简直是难用到爆!其实很多状态是根本就是用不着的。现有的很多封装都是砍掉状态,砍掉大部分细节功能以确保易用性。而且事实也证明了不懂原生 XMLHttpRequest 只会用 jQuery 的封装,使用起来也是无障碍的。
  其实不得不承认 XMLHttpRequest 的 API 在功能方面非常强大。也许有人会觉得很多东西依然不能实现?那是因为浏览器不支持而已。就 API 而言它已经非常强大了,甚至已经强大到浏览器在实现它的时候都无法驾驭了。但「功能强大」有时候并不是优点,就像 PS 显然比美图秀秀强大,但用户量却要呵呵(即使 PS 免费也不会改变这个局势)。又比如 LOL 的玩家为何比 DOTA 多(虽然我两者都不玩 = =|)?因为 DOTA 的难度太高,妹子们不会玩而已。
  现在这个局势就挺好的,XMLHttpRequest 基本已经被开发者们定位为了「底层 API」。要是没有特殊情况大家都会使用自己框架内的封装,很少在业务代码中直接使用它。即使是原生党,将来也会有 Fetch API 可以用。XHR 已经是一个传说,我不指望它将来能变得多好,但求将来新增的 API 不要重蹈覆辙。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^