工作变了

2018 年，不同于之前的被拥抱变化，我第一次主动更换了工作。从待了 4 年的阿里集团数据技术及产品部（后称 DT），跳到了蚂蚁金服体验技术部（后称 AFX）。虽然还是在大的阿里集团体系下面，不过干的事情、团队的风格、个人的心态都发生了天翻地覆的变化。

DT 的 4 年，一直在跟数据产品打交道。从商家数据分析产品生意参谋，到 BI 工具孔明灯（后来合并为 QuickBI），再到智能数仓建模工具 Dataphin，作为一个前端工程师我一直被数据的魅力感染着。虽然做的是前端的工作，但是耳濡目染下也对大数据体系初窥门径，甚至自己从零开始搭建了一套实时监控系统 —— Clue。数据采集、清洗、实时处理、离线处理、落库查询、数据可视化、异常识别与报警，每件事都是一点点摸索、尝试并最终攻克的。

也正是 Clue 的诞生，让我充分感受到自己对数据开发的热情以及能力上的不足。尽管旁人看来，身为一个前端工程师能把这么多后端以及大数据的技术用起来并完成的拼装成一个产品已经很了不起，但我仍觉得自己是管中窥豹，不得要领。这种不上不下的状态让我非常难受，于是我想要做出一些改变。

说起来也有些不可思议，虽然我所在的部门叫做「数据技术及产品部」，但转型做数据的空间并不大、机会也并不多。为什么？因为 DT 本来就是一个专业的数据部门，即使是校招的数据工程师都有很厚的数据研发底子，Hadoop、Spark、HDFS 张口就来。作为一个已经背上 专家 头衔的人，在一个大企业里仅凭自己的偏好就想转向从头开始干另外一个方向并不是易事，也不会有团队养得起这样的「闲人」。也正是因为 DT 太专业，很多底层的技术早已经被封装屏蔽，所有的最佳实践都已经被自动化、沉淀为产品。你需要做的很大程度上就是勾勾选选，写写简单的 SQL。对于我这样一个半路出家希望系统化学习大数据的人来说，还是希望自己脚踏实地一步一个坑把所有问题都解决一遍。

这里不得不提一句，我所在的团队却认真的、诚恳的给了我这个机会，允许我转型，并在若干时间内不考核绩效与产出。在这里除了感激涕零外没有任何方式能表达的我的心情，但基于上述原因，我依然选择了改变。

感恩 DT。

岗位变了

转岗到 AFX，没提升职也没提加薪，只跟新老板提了一个要求，我要做数据。对了，值得一提的是我的新老板就是林峰，那个在数据可视化领域赫赫威风鼎鼎大名的、那个创造了 ECharts 的、那个在百度就要给他升职加薪前毅然决然出去创业最后经验惨淡沦落到蚂蚁金服的男人。

于是我现在是数据技术专家。

专家的 title 不好背，我开始诚惶诚恐的恶补各种大数据知识。从最底层的 HDFS，到整个 Hadoop 生态，再到集团内的 MaxCompute，说明文档来回的看，例子反复的跑，团队已有的数据任务仔细的读。总的来说，还可以跟上团队需求的节奏。

说起来现在大数据领域有点开始像前端圈子一样蓬勃发展的趋势，虽然我也经常调侃团队里的前端说「贵圈真乱」，但我也明显感受到数据圈子里新轮子开始越造越快、越造越多。新名词也是五花八门、百花齐放，什么 HTAP、什么 NewSQL、什么 Data Lakes，对于刚刚正式加入贵圈的我来说还是有点消化不过来。

总的来说，我跟数据岗位依然处于蜜月期，大数据领域还有很多很多很多内容值得我去学习和探索，还有很多概念让我眼前一亮，还有很多技术让我仍不住喊 AHa 原来如此！我想这样的状态，让我满足。

重心变了

不知道从什么时候开始，我被打上了「做前端监控的」的标签。刚刚转行做数据的时候，我极力避免别人依然把我当前端看。然而时间久了我发现，前端监控和数据开发并不矛盾，我为什么不能既熟悉前端监控又能做好数据开发呢？况且在前端监控领域，我也确实积累了很多经验，有很多自己的想法和思考，应该让它们发光发热。

于是我决定继续把前端监控做深。在前几年做 Clue 监控平台的时候，我的研究重点在 JS 异常的捕获和分析上，而新团队的主要业务是一个数据分析产品而非监控工具。基于以上两点原因，我认为前端性能监控与数据分析更适合团队现阶段的需求。

我开始研读 W3C 上各种 Web Performance 相关的规范，并且顺手发了几个 PR 修复一些 specs 里的小问题，最终阴差阳错加入了 W3C Web Performance Working Group。当然不得不承认，目前整个 WG 的核心还是 Google、Mozilla 等浏览器厂商的专家，尽管国内也有浏览器厂商在 WG 里，但是一般不参与讨论。作为一个非厂商代表的我，只能更多的从数据采集、分析的角度提供规范制定时的一些思考和想法。

18 年 12 月，我还应邀参加了 2018 ArchSummit 架构师峰会，作为为数不多的前端议题，给大家分享了做前端性能监控的一些方法论和最佳实践。

生活变了

转岗到 AFX 后，我每天上班单程通勤时间从 5 分钟暴增到一个小时。为了让这段上班路程不再枯燥，也为了纪念这一次重大的转变，咬咬牙买了一辆新车（「新」是相对于原来的车，其实这辆车已经是大龄二手车了），也是我心仪已久的 Dream Car。不记得哪个汽车节目里说过，如果每次锁车时你不会忍不住多看几眼你的车，那么这个车并不值得买。这么评价的话，这个车对我来说还是很值得买的。

2018 年，也做了人生中第一次手术，住院将近两周。住在医院的时候时常告诫自己，身体最重要，可不能乱来了，然而一出院又开始活蹦乱跳声色犬马。总是不长记性，总是需要警醒。

最后，经过 5 年的长跑，我终于决定要结婚了。

写在最后

2018 年没立什么 Flag，然而过的却是风流涌动。2019 年依然不立什么 Flag。

本文是 深入理解 Service Worker 系列文章中的第二篇

本周苹果官方发布了 Safari 11.1 的 TP （技术预览）版，据更新日志显示，iOS 11.3 及 macOS 10.13.4 中的 Safari 将全面支持 Service Worker，这为 PWA 的推广扫除了最后的兼容性问题。

如果 iOS 能够完美的支持 Service Worker，那么目前 App Store 中至少一半以上纯信息展示型的 App 将无需通过 App Store 就能呈现给用户，无疑将引起新一轮的移动 App 开发革命。当然，根据部分开发者的反馈，Safari 技术预览版中 Service Worker 的实现还存在不少问题。

借着这个振奋人心的消息，本文开始聊聊如何使用 Service Worker。

注册一个 Service Worker

Service Worker 虽然是 Web Worker 的一种，但注册和使用方式与 Web Worker 却不尽相同。Web Worker 有一个全局构造函数 Worker，你可以通过 new Worker('worker.js') 的方式新建一个 Web Worker。

而 Service Worker 则需要需要 navigator.serviceWorker.register() 方法进行注册。这里还有个有意思的思考点，为什么同样是 Web Worker，注册方式甚至是挂载的层级都不同（一个是 window，一个是 navigator）呢？

下面的代码片段中，我们在页面里注册了一个 Service Worker，Service Worker 的具体行为在 sw.js 中进行定义。

1
2
3
4
5
6
7
8
9
10
11
12

// index.html
<script>
if (navigator.serviceWorker) {
  navigator.serviceWorker.register('sw.js')
    .then(registration => {
      // 注册成功
    })
    .catch(error => {
      // 注册失败
    });
}
</script>

在深入使用 Service Worker 后你会发现，所有相关的 API 都是 Promise-based 的，因此在调用注册方法后，我们需要使用 Promise 的方式来处理注册的结果。

若注册成功，则 Promise resolve 一个 ServiceWorkerRegistration 对象，通过这个对象你可以获取到当前注册的 Service Worker 的相关状态，或者订阅新的 Service Worker 注册事件，亦或者是注销一个 Service Worker。

1
2
3
4
5
6
7
8
9
10

// ...
.then(registration => {
  if (registration.installing) {
    // 当前存在处于 installing 状态的 Service Worker
  }

  if (registration.active) {
    // 当前存在处于 active 状态的 Service Worker，即控制当前页面的那个 Service Worker
  }
});

若注册失败，在 catch 中你会捕获到具体的错误。比如说 sw.js 中存在语法错误甚至压根不存在，或者没有使用 https 协议等，都会导致 Service Worker 注册失败。

注销一个 Service Worker

很多刚刚接触 Service Worker 的同学都会犯的一个错误就是，不知道如何注销一个 Service Worker。由于 Service Worker 有非常强大的网络拦截能力，如果错误的或者过时的 Service Worker 没有被正确注销，将在特定的场景下导致非常严重的问题。

在注册 Service Worker 时我们在代码中调用 navigator.serviceWorker.register() 方法，那么是不是只要删除这个注册语句，Service Worker 就会被注销掉呢？答案是否定的。

你必须显式的调用 unregister() 方法才能正确的注销 Service Worker，除此之外无论你是删除了 register() 调用还是删除了注册时的那个 sw.js，都不会对已经注册成功的 Service Worker 起到任何作用。

1
2
3
4
5
6
7
8
9
10

// ...
.then(registration => {
  registration.unregister().then(result => {
    if (result) {
      // 注销成功
    } else {
      // 注销失败
    }
  });
});

更新一个 Service Worker

上面我们讲到了如何注册或是注销一个 Service Worker，那如果我们的 Service Worker 需要更新呢？

更新时并没有一个类似于 navigator.serviceWorker.update() 的方法，我们只需要更改 Service Worker 中的内容（修改 sw.js），然后再次调用 register() 方法即可。

1
2
3
4
5
6
7

// 第一次注册
navigator.serviceWorker.register('sw.js');

// 修改 sw.js 中的内容

// 第二次注册，实则为更新过程
navigator.serviceWorker.register('sw.js');

你无需修改 sw.js 的文件名，只要保证其中的内容发生变化，则浏览器会自动启动更新程序。

小结

在本文中我们讲到了如何注册、注销和更新 Service Worker，这既是大家非常容易忽略的基础知识，也引出了下一章我们要讲的内容：Service Worker 的生命周期。

因为在你调用 register() 后，发生的事情远远没有一行代码那么简单。

本文是 深入理解 Service Worker 系列文章中的第一篇

Service Worker 的定义

Service Worker 听起来很像 Web Worker。

根据 Service Worker 的规范定义，它正是 Web Worker 中的一种（严格的说，Service Worker 应该是 Shared Worker 的一种），但更专注于对网络请求的拦截、后台数据更新等，这些能力正是为构建一个 PWA 打好了坚实的基础。

一个简化的 Service Worker 工作示意图

如果你还不清楚什么是 Web Worker，可以把它简单的理解为一个独立于主线程执行的 JavaScript 模块（无论是一个独立的 .js 文件或者 type="module"类型的 <script>标签）。之所以需要独立于主线程运行，是为了解决一些计算密集型的操作阻塞界面渲染和用户交互的问题。由于工作在不同的线程中，Web Worker 和主线程之间通过 postMessage 等方式进行通信。

Service Worker 到底是什么

只看定义可能很难对 Service Worker 有比较感性的认知，那我们直接上代码：

1
2
3
4
5
6
7
8
9
10
11
12

// service-worker.js
self.addEventListener('install', e => {
  console.log('installing service worker');
});

self.addEventListener('activate', e => {
  console.log('activating service worker');
});

self.addEventListener('fetch', e => {
  console.log(`fetching ${e.request.url}`);
});

上面的代码片段定义了一个很简单的 Service Worker，通过在页面上调用 navigator.serviceWorker.register('/service-worker.js') 即可将这个 Service Worker 注册到当前域下。

关于 Service Worker 的注册及使用，会在第二篇《怎么使用 Service Worker》中进行详细介绍。现在，你只需要对 Service Worker 有一个初步的认识即可。

Service Worker 的性质

1. 与 Web Worker 一样，因为运行在独立的线程中，Service Worker 无法直接进行任何 DOM 操作

1
2
3
4

//service-worker.js
self.addEventListener('install', e => {
  alert('注册成功');  // TypeError, alert is not a function
});

2. Service Worker 运行在独立的全局上下文环境（ServiceWorkerGlobalScope）中

你可以通过 self 关键字在 Service Worker 代码的任意位置来指向这个全局环境，有点类似 node.js 中的 global 关键字。

当然，这不意味着你只能在 Service Worker 中使用 self，this 依然可以被使用，只是考虑到各种作用域的变更（如箭头函数、bind 等），self 能够在任何位置、任何环境下永远指向这个全局作用域。

3. Service Worker 仅能运行在 HTTPS 环境下

主要是考虑到网络请求拦截等能力的危险程度，但为了调试方便可以在 HTTP 环境的 localhost 中进行调试。

4. Service Worker 的注册必选遵守「同源策略（Same Origin Policy）」

这也是很多人疑惑为什么注册一个 CDN 上的 Service Worker 会报错的问题所在，比如页面是 https://www.exmaple.com，注册一个 https://cdn.example.com/service-worker.js，就会导致跨域错误。

5. Service Worker 有固定的作用范围，可以在注册时通过 scope 参数指定，若留空则自动根据 Service Worker 的 location 来判断

举个例子，若没有特别设置 scope， https://www.example.com/sw.js 的作用域就是 /，因此这个 Service Worker 可以拦截该域下页面的任意请求；但是 https://www.example.com/folder/sw.js 的作用域只能是 /folder/，若访问的页面是 https://www.example.com/another-folder/index.html，这个 Service Worker 不会拦截到任何的请求。

因此一般来说，Service Worker 应该注册在根目录下，根据应用的需要指定 scope 即可。

6. 基于第 5 点性质，一个域下可以注册若干个 Service Worker，只要他们的 scope 不同即可

7. Service Worker 是事件驱动的

当事件触发时会执行 Service Worker 里注册的事件回调函数，当事件处理完成后会这个 Service Worker 对应的线程可能会被销毁。因此你无法在 Service Worker 中定义全局变量，如果需要持久化一些内容在不同的事件触发时进行传递，可以考虑使用 IndexedDB。

8. Service Worker 一旦注册成功，便不依托于某个具体的页面存在

举个例子，你在 https://www.example.com/index.html 使用 register('service-worker.js') 成功注册了一个 Service Worker。关闭浏览器后重新访问 https://www.example.com/index.html，移除掉 register('service-worker.js') 的调用，之前注册的 Service Worker 依然会正常运行。

9. Service Worker 在同源页面下是共享的

这一点从 「Service Worker 是 Shared Worker 的一种」可以推导出，不再单独解释。

小结

在这篇文章中，我们介绍了什么是 Service Worker、Service Worker 的性质，以及通过一个简短的例子让大家了解到了一个 Service Worker 长什么样子。

由于 Service Worker 是从 Web Worker 和 Shared Worker 演化而来的 API，很多 Web Worker 的性质、用法等还需要读者再仔细研究。

在没有深入理解 Service Worker 之前，我总觉得 PWA 无非是在构建的时候使用类似 webpack OfflinePlugin 之类的插件把所有的静态资源缓存起来做成离线应用即可。但是当深入学习了 ServiceWorker 及 CacheStorage 的设计思想、API 规范甚至是发展历程后，我才真正了解到做一个完整的 PWA 是一件多么复杂的事情。

基于我最近一个月对 ServiceWorker 的学习，结合在几个实际业务中的使用情况，我将通过一个系列文章来为大家深入解读 Service Worker 的概念、原理、设计思想、实战玩法以及如何在 PWA 中发挥关键作用等等。

系列文章将划分为如下三个部分：

理论部分

• 什么是 Service Worker
• 怎么使用 Service Worker
• Service Worker 的生命周期
• 什么是 CacheStorage
• 如何在 Service Worker 中使用 CacheStorage
• Service Worker 是否足够成熟（截止 2018 年 1 月）

实践部分

• 不同离线策略的差异与适用场景
• 如何避免设计出永远不会更新的 Service Worker
• Service Worker 最佳实践

延伸阅读

• Service Worker 的前世今生
• PWA 和 AMP 的异同

那么，让我们一起开始 Service Worker 的探索旅程吧！

Service Worker 是一个相对比较新的技术，规范和浏览器厂商的落地都在不断的变化和升级。我力争在行文过程中遵循「先实践后结论」的方式，保证所有的内容都经过真实环境测试。

如果文章存在任何错误，请点击文章标题下方的「查看源码」直接对本文编辑并提交 PR。

当然如果你观察的周期足够长，你会发现有些大牛的博客在沉寂若干年后又开始焕发第二春。那是因为他们已经成功跻身中层管理，阶段性的目标被调整为团队管理和影响力提升，自然又更新的勤快了起来。

言归正传，2017 年发生了很多有意思的事情。无论是技术上，工作上还是生活上，都值得被记录下来，与大家分享。算是对过去一年的一个交代，也算是对新的一年的一个期许。

TypeScript 与 VSCode

2017 年最兴奋的事情就是上手了 TypeScript。

大概从 17 年 6 月份开始，因为一个新项目的契机我开始全面详细的学习 TypeScript。虽然自诩不是一个抵触新鲜事物的人，但是第一次让我去学习 TypeScript，其实我是比较抗拒的。

第一，我始终觉得「静态类型 + OOP」 的设计完美的体现了冗余的仪式感之「美」。明明一行代码就能解决的问题，非要先定义一个接口，再实现一下，最后再实例化一下才能使用。

其次，微软在开源届的名声一直不算太好，各种 .NET 的生态衰亡、SilverLight 等技术的昙花一现以及 IE 本身对前端工程师的一万点伤害，让我十分怀疑 TypeScript 是否是一个值得学习的技术。

最后，在学习 TypeScript 之前我已经非常熟练的使用 ES 6 甚至是 ES 7 中的诸多特性，感觉 TypeScript 除了静态类型检查并没有带来太多的红利，学习的投入产出比不高。

但是最终让我心甘情愿爱上 TypeScript 的原因也很简单：TypeScript + VSCode 的开发模式非常适合团队协作模型下的大型项目开发。

正是因为新项目是一个非常大型的 React + Redux 单页应用，有大量的组件和模块需要被各个场景复用，TypeScript 强大的类型检查功能帮助我们基本上很少浪费时间在公共组件或者模块的调用方式讨论上，要用什么公共组件，直接鼠标悬浮在对应的地方就能有完整的提示，参数传的不对、传少了、返回值用法不对等等问题都能很直接的在编辑器中体现出来（VSCode 功不可没）。这些特性在团队协作的大型项目开发工作中显得尤为重要。

当然，也不是说 TypeScript 不能用在小型单人项目中。我也正在计划把自己 2、3 年前个人开发的很多技术项目逐渐往 TypeScript 上迁移。因为强大的静态检查类型可以帮助我们检查很多低级的运行时错误，比如变量名拼错。

还要多提一句的就是 VSCode。

在 VSCode 之前我一直是 Sublime 的死忠，期间 3 次尝试切换到 VSCode 都以失败告终。但使用 TypeScript 开发后，配合 VSCode 做各种代码间（甚至是 node_modules中的文件）跳转、类型定义查看、错误提示等功能，简直流畅至极。

同时由于 VSCode 对开发者暴露的是 TypeScript 的 API，使得你想编写一个插件简直易如反掌（对比下当年想写一个 Sublime 插件苦兮兮的学了很久 Python）。

大数据体系

都说大数据像 teenage sex，但是作为在阿里数据中台的直接参与一线数据产品开发的前端工程师，2017 年我自认为还是摸到了一些大数据入门级知识，如果类比 teenage sex 的话不知是否达到二垒。

我是怎么和大数据结缘的呢？故事还要从阿里内部的 Clue 前端监控平台说起（互联网无法直接访问😢）。大约在 2015 年上半年的时候，我注意到我们的很多前端故障都是可以在用户向客服发起投诉之前被捕捉到的（比如点击某个按钮时有 JS 报错导致弹框没有打开等），但是我们对自己写的代码在用户浏览器中运行的情况如何是完全没有方法感知的。

于是我开始规划做一个异常监控平台，名字就叫前端稳定性平台（Frontend Stability Platform，FSP），一个非常符合程序员风格的名字。

要做一个监控平台，首先要解决数据从哪里来的问题。对于前端监控来说，很显然需要在客户端部署采集代码，监听全局 JS 异常，然后上报的日志服务器。在日志服务器上，数据以文件的形式按照约定的分隔符储存。然后需要类似于 logstash（阿里内部叫 TT）的工具定期去日志服务器上拉取日志文件，再传递给实时或离线数据处理服务。经过一系列的过滤、汇总后，最终生成的数据根据查询的需要储存在不同类型的数据库中，供给监控平台的 Web 服务进行查询。

这个监控平台的工作原理我在团队的知乎专栏中有一篇文章进行了更详细的描述，这里就不再赘述。

当然真正的大数据可没有上文三言两语讲的那么简单，除了技术上如何处理，目前企业大数据面临更大的问题是如何规范大数据建设、数据如何发挥价值（从业务数据化到数据业务化）等等。但很高兴我起码算入了门，能把流程走通，还能最终产品化落地（最终命名为 「Clue 前端监控平台」，寓意为业务发现异常的线索）。

说到大数据不得不提的就是机器学习和人工智能。我也很自不量力的参加了 Andrew Ng 在 Coursera 上非常出名的机器学习课程，并成功卡在了理解逻辑回归损失函数（Loss Function）的那一大堆公式里（FYI，逻辑回归仅仅是第二章的内容）。

其它技术

2017 年在技术上还有很多琐碎的事情，比如年中闹的满城风雨的 React License 事件，虽然最终以 React 使用 MIT 协议暂告一段落，但是也间接捧红了 preact 等不少类 React 但协议无害的替代产品。据我所知百度已经全线禁用 React，即使协议已经不再是头等主要的问题。

此外 2017 年我还研究了一段时间的 ServiceWorker，以及现在越来越热的 PWA 概念。感觉这是比 ReactNative、Cordova、Weex 等方案更激进但也能更进一步降低前端工程师写移动 App 门槛的方案。如果标准制定的够完善，各大浏览器厂商跟进足够给力，相信会引起新一轮技术革命的高潮。

另外值得一提的是 Chrome Headless 的发布，终于把很多自动化场景从 PhantomJS 或 Selenium 的噩梦中解救了出来。在 Chrome Headless 发布不久，我们团队就开发了一款基于该技术（及 pupeteer）的自动化截图技术产品，无论从性能还是使用体验上来说，都称得上是质的飞跃。

拥抱变化与可持续发展

很多人说到阿里巴巴脑海里第一个反映出来的词就是「拥抱变化」。没错，今年我也被「拥抱变化」了。

坦白说当变化真正发生的时候，我不可避免的还是有一些心理上的起伏。这让我想到了生活大爆炸里面 Sheldon 对内稳态（hemeostasis）的痴迷，谁不希望做自己擅长的、早已驾轻就熟的工作呢？谁不希望面对的同事是合作多年、默契深厚的好伙伴呢？谁不希望负责的项目运行稳定，不会有任何大麻烦呢？

内稳态固然让人痴迷，但是阿里内部有句土话我也很认同：当你觉得困难的时候，就是你在成长的时候。如何定义公司里的老油条？就是那种工作三年全靠入职前三个月经验的人。

我不希望成为这样的人。

在变化之外，2017 年我悟到最重要的一个道理就是要坚持可持续发展。

以前总觉得自己是个热血青年，熬夜写代码完全不在话下，有时候睡着睡着脑海里突然冒出来一个想法，一个鲤鱼打挺就坐起来开始编码，第二天一杯浓咖啡就能再战一整天。

而现在，偶尔业务上线或赶关键时间点熬到 2、3 点，第二天整个人都会精神不振，多少杯咖啡都没有救。

身体是革命的本钱，毛主席诚不我欺也！

写在最后

今年侥幸晋升到了 P7，背上了「专家」的 title，心里依然很惶恐。

对技术，深度和广度都需要继续拓展；
对个人，调整心态，健康工作，坚持可持续发展成了第一目标；
对 2018，不立任何 flag，佛系生活，免的年终打脸。

然而在 fetch API 出现后，事情就没那么简单了。在我上一篇文章《fetch 没有你想象的那么美》中，我提到了对 fetch 进行 Monkey Patch 时遇到的奇怪报错：

Uncaught TypeError: Already read

同时解释了这是 fetch 使用 Stream API 导致的限制，那这是不是意味着我们无法 hack 原生的 fetch 从而实现对 fetch 结果的统一拦截过滤了呢？答案是否定的。

在仔细阅读完 fetch 相关的文档后，我在 Response 对象的文档页面找到了一个有意思的属性和一个更有意思的方法。

Reponse.bodyUsed

这个属性用于标示这个 Response 对象是否已经被读取过，比如下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

fetch('/api/user.json')
.then(response => {
  console.log(response.bodyUsed); // false
  return response.json().then(json => {
    console.log(response.bodyUsed); // true

    // 如果这里再次尝试对 response 的 Stream 数据进行读取，则会报错
    // response.text();   // Uncaught TypeError: Already read
    return json;
  });
})
.then(json => {
  // 拿到服务端响应的 JSON 对象
});

就很好的解释了 bodyUsed 属性的作用和使用方法。但是从实用角度来说，这个布尔值并没有太大的作用，真正帮我们解决拦截并统一响应 fetch 请求的功能在下面。

Reponse.prototype.clone()

这个 API 顾名思义就是对 response 对象的一个复制，根据 文档 描述，复制出来的 response 对象和原来的对象数据和行为完全一致，只是保存在不同的变量中而已。

那么 clone 方法如何解决 Already Read 报错的问题呢，让我们稍微修改一下上面的代码：

1
2
3
4
5
6
7
8
9
10
11

fetch('/api/user.json')
.then(response => {
  console.log(response.bodyUsed); // false
  return response.clone().json().then(json => {
    console.log(response.bodyUsed); // false

    // 如果这里再次尝试对 response 的 Stream 数据进行读取，没有问题
    // response.text().then(text => console.log(text));
    return json;
  });
});

注意第 4 行我们在 response.json() 调用前添加了 response.clone().json()，这样就完成了对 response 对象的复制。后续的 Stream API 读取发生在一个全新的 response 对象上，所以原来的 response 对象 bodyUsed 属性为 false，也可以对其调用不同的读取方法，如 .text() 或 .blob()。

唯一需要注意的是，clone 方法的调用一定要发生在对 response 调用任何读取之前，比如下面的代码依然会报错：

1
2
3
4
5
6
7
8
9

fetch('/api/user.json')
.then(response => {
  console.log(response.bodyUsed); // false
  return response.json().then(json => {
    // 如果这里先尝试 clone，再对 response 的 Stream 数据进行读取，依然会报错
    // response.clone().text().then(text => console.log(text));
    return json;
  });
});

也正是如此，fetch 的出现在前端圈子里一石激起了千层浪，大家欢呼雀跃弹冠相庆恨不得马上把项目中的 $.ajax 全部干掉。然而，在新鲜感过后， fetch 真的有你想象的那么美好吗？

如果你还不了解 fetch，可以参考我的同事 @camsong 在 2015 年写的文章 《传统 Ajax 已死，Fetch 永生》

在开始「批斗」fetch之前，大家需要明确 fetch 的定位：fetch 是一个 low-level 的 API，它注定不会像你习惯的 $.ajax 或是 axios 等库帮你封装各种各样的功能或实现。也正是因为这个定位，在学习或使用 fetch API 时，你会遇到不少的挫折。

（对于没有耐心看完全文的同学，请先记住本文的主旨不在于批评 fetch，事实上 fetch 的出现绝对是前端领域的进步体现。在了解主旨的前提下，关注加黑部分即可。）

发请求，比你想象的要复杂

很多人看到 fetch 的第一眼肯定会被它简洁的 API 吸引：

1

fetch('http://abc.com/tiger.png');

原来需要 new XMLHttpRequest 等小十行代码才能实现的功能如今一行代码就能搞定，能不让人动心吗！

但是当你真正在项目中使用时，少不了需要向服务端发送数据的过程，那么使用 fetch 发送一个对象到服务端需要几行代码呢？（出于兼容性考虑，大部分的项目在发送 POST 请求时都会使用 application/x-www-form-urlencoded 这种 Content-Type）

先来看看使用 jQuery 如何实现：

1

$.post('/api/add', {name: 'test'});

然后再看看 fetch 如何处理：

1
2
3
4
5
6
7
8
9

fetch('/api/add', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
  },
  body: Object.keys({name: 'test'}).map((key) => {
    return encodeURIComponent(key) + '=' + encodeURIComponent(params[key]);
  }).join('&')
});

等等，body 字段那一长串代码在干什么？因为 fetch 是一个 low-level 的 API，所以你需要自己 encode HTTP 请求的 payload，还要自己指定 HTTP Header 中的 Content-Type 字段。

这样就结束了吗？如果你在自己的项目中这样发送 POST 请求，很可能会得到一个 401 Unauthorized 的结果（视你的服务端如何处理无权限的情况而定）。如果你在仔细看一遍文档，会发现原来 fetch 在发送请求时默认不会带上 Cookie！

好，我们让 fetch 带上 Cookie：

1
2
3
4
5

fetch('/api/add', {
  method: 'POST',
  credentials: 'include',
  ...
});

这样，一个最基础的 POST 请求才算能够发出去。

同理，如果你需要 POST 一个 JSON 到服务端，你需要这样做：

1
2
3
4
5
6
7
8

fetch('/api/add', {
  method: 'POST',
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  body: JSON.stringify({name: 'test'})
});

相比于 $.ajax 的封装，是不是复杂的不是一点半点呢？

错误处理，比你想象的复杂

按理说，fetch 是基于 Promise 的 API，每个 fetch 请求会返回一个 Promise 对象，而 Promise 的异常处理且不论是否方便，起码大家是比较熟悉的了。然而 fetch 的异常处理，还是有不少门道。

假如我们用 fetch 请求一个不存在的资源：

1
2
3
4
5
6
7

fetch('xx.png')
.then(() => {
  console.log('ok');
})
.catch(() => {
  console.log('error');
});

按照我们的惯例 console 应该要打印出 「error」才对，可事实又如何呢？有图有真相：

为什么会打印出 「ok」呢？

按照 MDN 的说法，fetch 只有在遇到网络错误的时候才会 reject 这个 promise，比如用户断网或请求地址的域名无法解析等。只要服务器能够返回 HTTP 响应（甚至只是 CORS preflight 的 OPTIONS 响应），promise 一定是 resolved 的状态。

所以要怎么判断一个 fetch 请求是不是成功呢？你得用 response.ok 这个字段：

1
2
3
4
5
6
7
8
9
10
11

fetch('xx.png')
.then((response) => {
  if (response.ok) {
    console.log('ok');
  } else {
    console.log('error');
  }
})
.catch(() => {
  console.log('error');
});

再执行一次，终于看到了正确的日志：

Stream API，比你想象的复杂

当你的服务端返回的数据是 JSON 格式时，你肯定希望 fetch 返回给你的是一个普通 JavaScript 对象，然而你拿到的是一个 Response 对象，而真正的请求结果 —— 即 response.body —— 则是一个 ReadableStream。

1
2
3
4
5
6
7
8

fetch('/api/user.json?id=2')   // 服务端返回 {"name": "test", "age": 1} 字符串
.then((response) => {
  // 这里拿到的 response 并不是一个 {name: 'test', age: 1} 对象
  return response.json();  // 将 response.body 通过 JSON.parse 转换为 JS 对象
})
.then(data => {
  console.log(data); // {name: 'test', age: 1}
});

你可能觉得，这些写在规范里的技术细节使用 fetch 的人无需关心，然而在实际使用过程中你会遇到各种各样的问题迫使你不得不了解这些细节。

首先需要承认，fetch 将 response.body 设计成 ReadableStream 其实是非常有前瞻性的，这种设计让你在请求大体积文件时变得非常有用。然而，在我们的日常使用中，还是短小的 JSON 片段更加常见。而为了兼容不常见的设计，我们不得不多一次 response.json() 的调用。

不仅是调用变得麻烦，如果你的服务端采用了严格的 REST 风格，对于某些特殊情况并没有返回 JSON 字符串，而是用了 HTTP 状态码（如：204 No Content），那么在调用 response.json() 时则会抛出异常。

此外，Response 还限制了响应内容的重复读取和转换，例如如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var prevFetch = window.fetch;
window.fetch = function() {
  prevFetch.apply(this, arguments)
  .then(response => {
    return new Promise((resolve, reject) => {
      response.json().then(data => {
        if (data.hasError === true) {
          tracker.log('API Error');
        }
        resolve(response);
      });
    });
  });
}

fetch('/api/user.json?id=1')
.then(response => {
  return response.json();  // 先将结果转换为 JSON 对象
})
.then(data => {
  console.log(data);
});

是对 fetch 做了一个简单的 AOP，试图拦截所有的请求结果，并当返回的 JSON 对象中 hasError 字段如果为 true 的话，打点记录出错的接口。

然而这样的代码会导致如下错误：

Uncaught TypeError: Already read

调试一番后，你会发现是因为我们在切面中已经调用了 response.json()，这个时候重复调用该方法时就会报错。（实际上，再次调用其它任何转换方法，如 .text() 也会报错）

因此，想要在 fetch 上实现 AOP 仍需另辟蹊径。

其它问题

1. fetch 不支持同步请求

大家都知道同步请求阻塞页面交互，但事实上仍有不少项目在使用同步请求，可能是历史架构等等原因。如果你切换了 fetch 则无法实现这一点。

2. fetch 不支持取消一个请求

使用 XMLHttpRequest 你可以用 xhr.abort() 方法取消一个请求（虽然这个方法也不是那么靠谱，同时是否真的「取消」还依赖于服务端的实现），但是使用 fetch 就无能为力了，至少目前是这样的。

3. fetch 无法查看请求的进度

使用 XMLHttpRequest 你可以通过 xhr.onprogress 回调来动态更新请求的进度，而这一点目前 fetch 还没有原生支持。

小结

还是要再次明确，fetch API 的出现绝对是推动了前端在请求发送功能方面的进步。

然而，也需要意识到，fetch 是一个相当底层的 API，在实际项目使用中，需要做各种各样的封装和异常处理，而并非开箱即用，更做不到直接替换 $.ajax 或其他请求库。

参考资料

1. fetch spec https://fetch.spec.whatwg.org/#body
2. fetch 实现 https://github.com/github/fetch
3. 什么是 Already Read 报错 http://stackoverflow.com/questions/34786358/what-does-this-error-mean-uncaught-typeerror-already-read
4. 使用 fetch 处理 HTTP 请求失败 https://www.tjvantoll.com/2015/09/13/fetch-and-errors/
5. https://jakearchibald.com/2015/thats-so-fetch/

当没有正确设置 Karma + Mocha 超时时间时，会报出如下错误：

Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure “done()” is called; if returning a Promise, ensure it resolves.

此时即使在测试代码里显式添加了超时配置也没有用：

1
2
3
4
5

describe('Suite', function() {
  it('Case', function() {
    this.timeout(60000); // 无用
  });
});

这里还需要注意，一些新手经常犯的错误为这里使用了 ES2015 的箭头函数，this 这个 context 发生了改变，导致超时配置不生效。

最后经过一番 Google，发现当 Mocha 和 Karma 一起使用时，要在 karma.conf.js 里对 Mocha 进行配置，配置如下：

1
2
3
4
5
6
7
8
9
10

// karma.conf.js
module.exports = function(config) {
  config.set({
    client: {
      mocha: {
        timeout : 6000 
      }
    }
  });
};

其它需要传递给 Mocha 的参数也可以在这里配置。此处配置的超时时间为全局级别，因此设置时要考虑最长的 Case 需要的时间。

然而从 1.x 版本起，ReactRouter 的洪荒之力就开始慢慢爆发，目前最稳定的版本已经是 2.8.1，而下一个正式版本将是 —— 没错，正如你在标题里看到的那样 —— 4.0.0。先收拾一下你崩溃的心情，让我们来看看这一切到底是怎么回事。

ReactRouter 3 去哪儿了

从 2.x 直接跨入 4.x，ReactRouter 的 maintainer 数学还不至于那么差，那这一切都是为什么呢？事实上 3.x 版本相比于 2.x 并没有引入任何新的特性，只是将 2.x 版本中部分废弃 API 的 warning 移除掉而已。按照规划，没有历史包袱的新项目想要使用稳定版的 ReactRouter 时，应该使用 ReactRouter 3.x。

目前 3.x 版本也还处于 beta 阶段，不过会先于 4.x 版本正式发布。如果你已经在使用 2.x 的版本，那么升级 3.x 将不会有任何额外的代码变动。

为什么又要大改 API

ReactRouter 的 API 是出了名的善变，这一点我已经在之前的博文中吐槽过一次了。没想到连 React 都稳定的在 15.x 版本中维护了这么久，ReactRouter 还是想要搞点大新闻。

根据 ReactRouter 核心开发者 ryanflorence 的说法，ReactRouter 4.x 之所以要大刀阔斧的修改 API，主要是为了『声明式的可组合性（Declarative Composability）』。怎么理解声明式的可组合性呢？实际上当你在写 React 组件时，就不知不觉的利用了这一特性。

1
2
3
4
5
6
7
8
9
10
11

function ComponentA() {
  return <div>A</div>;
}

function ComponentB() {
  return <div>B</div>;
}

function Page() {
  return <div><ComponentA /><ComponentB /></div>;
}

正如上面的代码片段，在 Page 组件中你可以方便的将任意组件在 render 方法中渲染出来。但是这种特性遇到 ReactRouter 时，你只能把匹配当前路由的组件用this.props.children（最早的时候是 this.props.routerHandler，有多少人还有印象）渲染 。

此外，ReactRouter 虽然宣称是声明式的路由库，但仍然提供了不少非声明式的 API，其中路由组件的生命周期方法就是最典型的例子。其实我们不难想到，明明用来渲染的 React 组件本身已经有了一套完备的生命周期方法（componentWillMount、componentWillUnmount 等），为什么还需要 ReactRouter 提供的什么 onEnter 和 onLeave 呢？

当然，这一切都是 ryanflorence 个人的说法，不知道又有多少人真的会为了追求纯正的 declarative 花时间去重构代码兼容 ReactRouter 4 呢？

ReactRouter 4 有什么变化

虽然目前还是 alpha 版本，但是 ReactRouter 4 的 API 已经有了雏形，其官方文档也有不少带 demo 的例子，下面简单总结一下 ReactRouter 4 的变化。

更少的 API

先来看看目前 ReactRouter 2 的 API 列表：

再看看 4.x 计划中的 API：

直观看起来 API 确实少了不少，但这也意味着使用了被废弃的 API 将会有更大的重构工作量。不，实际上即使用了没有被废弃的 API，也会有很大的重构工作量。但是对于新手来说，学习成本相对会比较低。

<Router>变身为容器

在目前的 API 中，<Router> 组件的 children 只能是 ReactRouter 提供的各种组件，如 <Route>、<IndexRoute>、<Redirect>等。而在 ReactRouter 4 中，你可以将各种组件及标签放进 <Router> 组件中，他的角色也更像是 Redux 中的 <Provider>。

不同的是 <Provider> 是用来保持与 store 的更新，而 <Router> 是用来保持与 location 的同步。

以下为新版 ReactRouter 可能的用法：

1
2
3
4
5
6
7
8
9
10
11
12
13

<Router>
  <div>
    <h2>Accounts</h2>
    <ul>
      <li><Link to="/netflix">Netflix</Link></li>
      <li><Link to="/zillow-group">Zillow Group</Link></li>
      <li><Link to="/yahoo">Yahoo</Link></li>
      <li><Link to="/modus-create">Modus Create</Link></li>
    </ul>

    <Match pattern="/:id" component={Child} />
  </div>
</Router>

不过这样的变动将会导致一个很严重的问题：由于路由定义里不再是纯粹的路由相关的组件，你无法在一个文件中（通常是用来定义路由的 routes.js）看到整个 App 的路由设计及分布。

目前 ReactRouter 提供了一个工具库来解决将完整的路由定义转换为 <Match> 组件的问题，但是粗略的看了一下用法感觉还是比较别扭，期待正式发布时能有更好的解决方案。

再见 <Route>，你好<Match>

ReactRouter 中被使用最多的 <Route> 组件这次没有幸免，取而代之的是 <Match> 组件。那么 <Match> 究竟有什么不同呢？

1. pattern 取代 path

很大程度上这只是为了配合 Match 这个名称的转换而已，实际功能与 path 无异。

1

<Match pattern="/users/:id" component={User}/>

2. component 还是 component，components 没了

判断路由命中时该渲染哪个组件的 props 还是叫 component，但是为一个路由同时提供多个命名组件的 props components 没有了。下文会详细介绍在 ReactRouter 中如何解决一个路由下渲染多个组件的问题。

3. 使用 render 渲染行内路由组件

能够更自由的控制当前命中组件的渲染，以及可以方便的添加进出的动画。

1
2
3
4
5
6
7
8
9
10
11
12
13

// convenient inline rendering
<Match pattern="/home" render={() => <div>Home</div>}/>

// wrapping/composing
const MatchWithFade = ({ component:Component, ...rest }) => (
  <Match {...rest} render={(matchProps) => (
    <FadeIn>
      <Component {...matchProps}/>
    </FadeIn>
  )}/>
)

<MatchWithFade pattern="/cool" component={Something}/>

<Miss> 取代曾经的 <NotFoundRoute>

早在 0.x 时代，ReactRouter 提供了 <NotFountRoute> 来解决渲染 404 页面的问题。不过这一组件在 1.x 时就被移除了，你不得不多写若干行代码来解决这个问题。

1
2
3
4
5
6

// 如果想要展示一个 404 页面（当前 URL 不变）
<Route path='*' component={My404Component} />

// 如果想要展示一个 404 页面（当前 URL 重定向到 /404 ）
<Route path='/404' component={My404Component} />
<Redirect from='*' to='/404' />

在 ReactRouter 4 中，你可以省点儿事直接用 <Miss> 组件。

1
2
3
4
5
6
7
8
9
10
11

const App = () => (
  <Router>
    <Match pattern="/foo"/>
    <Match pattern="/bar"/>
    <Miss component={NoMatch}/>
  </Router>
)

const NoMatch = ({ location }) => (
  <div>Nothing matched {location.pathname}.</div>
)

ReactRouter 4 的大杀器：一个路由，多次匹配

在上文中我们提到过，目前 ReactRouter 匹配到某个路由时，将直接渲染通过 component 定义的组件，并把命中的子路由对应的组件作为 this.props.children 传入。

在前端 App 日益复杂的今天，一条路由的改变不仅仅简单的是页面的切换，甚至可能精细到页面上某些组件的切换。

让我们直接看下面的代码：

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

// 每条路由有两个组件，一个用于渲染 sidebar，一个用于渲染主页面
const routes = [
  { pattern: '/',
    exactly: true,
    sidebar: () => <div>Home!</div>,
    main: () => <h2>Main</h2>
  },
  { pattern: '/foo',
    sidebar: () => <div>foo!</div>,
    main: () => <h2>Foo</h2>
  },
  { pattern: '/bar',
    sidebar: () => <div>Bar!</div>,
    main: () => <h2>Bar</h2>
  }
]

<Router history={history}>
  <div className="page">
    <div className="sidebar">
      <ul>
        <li><Link to="/">Home</Link></li>
        <li><Link to="/foo">Foo</Link></li>
        <li><Link to="/bar">Bar</Link></li>
      </ul>

      /* 对当前路由进行匹配，并渲染侧边栏 */
      {routes.map((route, index) => (
        <Match
          key={index}
          pattern={route.pattern}
          component={route.sidebar}
          exactly={route.exactly}
        />
      ))}
    </div>

    <div className="main">
      /* 对当前路由进行匹配，并渲染主界面 */
      {routes.map((route, index) => (
        <Match
          key={index}
          pattern={route.pattern}
          component={route.main}
          exactly={route.exactly}
        />
      ))}
    </div>
  </div>
</Router>

通过上面的代码片段我们可以看出，<Match> 的设计理念完全不同于 <Route>。使用 <Match> 可以让我们在当前路由中尽情的匹配并渲染需要的组件，无论是需要渲染 Sidebar、BreadCrumb 还是主界面。

若使用现有的 ReactRouter API，只能通过当前路由匹配主界面对应的组件，至于 Sidebar 和 BreadCrumb，只能传入当前的 pathname 手动进行匹配。由此可见 <Match> 将会为此类需求带来极大的便利。

其他疑惑

当然，还有几个大家普遍关心的问题官方文档中也有所提及：

1. ReactRouter 的 API 是否还会有大的变化？

答：只要 React 的 API 不变，这一版的 API 也不会变。

2. 是否有对 Redux 的支持？

答：将提供一个受控的 <ControlledRouter>，支持传入一个 location。（作者注：这下真的不需要 react-router-redux 了，撒花！）

3. 新版是否对滚动位置管理添加支持？

答：将会对 window 和独立组件的滚动位置提供管理功能。（作者注：目前在不添加额外配置的情况下，路由切换时并不会恢复滚动位置）

ReactRouter 4 小结

了解了这么多 ReactRouter 4 的内容，你是否喜欢新版的 API 设计呢？

其实从 ReactRouter 4 的这些变动不难看出，ReactRouter 正在努力的朝纯声明式的 API 方向迈进，一方面减少不必要的命令式 API，一方面也提供更语义化的路由匹配方案。

此外新的 ReactRouter 也提供了非常强大的动态路由能力，甚至对嵌套路由也有所支持，这也是一个复杂的前端应用所必须的功能。

参考资料

1. ReactRouter 4 文档
2. ReactRouter 4 Github repo
3. ReactRouter

说这个项目复杂，不仅是因为需求设计复杂，更是因为在这个项目里我们使用了很多新技术 —— Angular2（是的，beta 版），Webpack2（是的，beta 版），RxJS（这两个 RxJS1、RxJS2 傻傻分不清楚）还有 TypeScript。

关于为什么一个大型线上项目会选择这么冒进的技术选型这里不多做评价，只能说最终团队还是成功将整个产品发布到了线上，我也对 Angular2 这个全新的 Angular 有了更全面的认识。

这篇文章不想对比 React 和 Angular2（不要急，这些东西肯定会出现在项目总结里），而是想站在熟悉 React + Redux 开发模式的前端工程师角度说一说 Angular2，尤其是那些我不太理解的地方。

剧透：这篇文章无意引起骂战，因此如果你看到我哪里写的不对，请直接在评论区里纠正。

看不懂的依赖注入

我知道这其实不仅仅针对 Angular2，早在 Angular1 中就存在依赖注入的概念，甚至这还是 Angular 引以为傲的特性。每当谈到依赖注入的时候，我就看到一帮 OOP（以 Java 为首）爱好者眼里闪烁着奇异的光芒。

然而依赖注入的问题一直困扰着我，倒不是说不理解依赖注入的使用方法或是原理，而是不理解为什么我的代码里需要依赖注入？

当我把这个问题抛给项目组中强推 Angular 的同学时，他也一时语塞。

在 Angular2 中，一个常见的依赖注入是注入一个 Http 对象，用于发送请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import {Component, OnInit} from 'angular2/core';
import {Http} from 'angular2/http';

@Component({
  selector: 'test',
  providers: [Http]
})
class Test implements OnInit {
  constructor(private http: Http) {
  }

  ngOnInit() {
    this.http.get('/api/user.json').map(res => res.json()).subscribe(result => {
      // 这里拿到请求的结果
    });
  }
}

上述代码是在 Angular 中使用内置 Http 模块发送请求的一段示例代码。具体依赖注入发生在 constructor 函数中。按照 Angular 宣传的那样，你只用简单的在 constructor 中声明这些参数，Angular 将自动为你处理依赖注入的问题。

注意到我们要使用 Http 来发请求，首先需要从 angular2/http 中将 Http import 进来，然后需要在组件的配置中添加对应的 providers，最后还需要在 constructor 中声明一个参数。

这个时候我其实是有点懵逼的，因为在一般应用里，发请求大概是这样的。

1
2
3
4
5
6
7

var request = require('superagent');

function getUser() {
  return request.get('/api/user.json').end((err, res) => {
    // 这里是拿到请求的结果
  });
}

为了公平起见，我还是假装依赖了一个第三方的库来实现 Ajax 请求。在这份代码里没有什么高大上的依赖注入，更没有什么 constructor，只有简单的引入并使用。

所以我不太明白，Angular 中的依赖注入究竟在多大程度上发挥着作用？

语法糖、语法糖和语法糖

很多人在第一眼看到 React 的时候，都在叫嚣 JSX 是「在 JS 里嵌入 HTML」，是邪门歪道，吃枣药丸。我只想说，相比于 Angular2 里的这些语法糖，JSX 简直就是 JavaScript 里的纯情小处男。

以下引用部分 Angular2 文档中关于模板语法的部分：

Expanding *ngFor

The ngFor undergoes a similar transformation. We begin with an ngFor example:

&lt;hero-detail *ngFor="#hero of heroes; trackBy:trackByHeroes" [hero]="hero"></hero-detail>

Here’s the same example after transporting the ngFor to the template directive:

&lt;hero-detail template="ngFor #hero of heroes; trackBy:trackByHeroes" [hero]="hero"></hero-detail>

And here it is expanded further into a <template> tag wrapping the original <hero-detail> element:

&lt;template ngFor #hero [ngForOf]="heroes" [ngForTrackBy]="trackByHeroes"> <hero-detail [hero]="hero"></hero-detail>&lt;/template>

读完之后你会发现，*ngFor 这个指令，原来是个语法糖。好嘛，其实语法糖在很多框架设计里都有啊。但是当你展开这个语法糖之后，你会发现这个语法糖其实还是另一个语法的语法糖。这也就是说，*ngFor 是语法糖的语法糖。

这种例子在 Angular2 中还有不少，任何一个正常的 JavaScript 开发者如果不想把自己逼疯的话，都会喜欢一个原始的 for 循环，或者一个 [].map 吧……

看到某篇文章争论说 Angular2 的模板用的是 「Valid HTML」，我只想说管你 Valid 不 Valid，臣妾看不懂啊。

模板里面到底发生了什么

其实刚开始写 Angular 应用的时候，心里还是对双向绑定挺期待的。因为在 React + Redux 架构里面，表单处理永远都是一个痛点（这里安利一下自己写的 redux-form-utils 良心工具，线上产品背书）。但是等我真的在写 Component 中的 template 时，就开始慢慢崩溃了。

首先最崩溃的是，我没办法在模板中断点调试（还是我没有找到正确的方法），这导致在一些模板中存在复杂逻辑的场景我只能默默的在心里推倒运行的过程。

然后是在模板里面，你还是可以写大量的逻辑，比如这样

1
2
3
4
5
6
7
8
9

@Component({
  template: `
    <ul #listEl [class.rendered]="listEl.rendered">
      <li *ngFor="#item of list; if(last) {listEl.rendered = true;}" (click)="list.push(Math.random()); $event.stopPropagation(); $event.preventDefault(); // Do other fancy stuff">
        {{ item.text }}
      </li>
    </ul>
  `,
})

这些在模板中的代码都是完全合法的 Angular2 语法。有人可能觉得，允许你这么写不代表你一定要这么写。事实上，我已开始很多组件都是这么写的，因为很快，因为网上很多 demo 也这么写，因为不知道该怎么更好的组织代码。

这样下去，一个 Angular 组件中，你不仅要阅读组件本身的各种对数据的处理，还要看模板中的各种逻辑。尤其是一些比较复杂的组件，模板和组件本身放在不同的文件中时，这种来回上下文的切换真是酸爽。

组件通信操碎了心

在 Angular 中，父组件想要传递一些信息给子组件，还是比较简单的，直接使用属性绑定即可。在子组件中稍微麻烦一点，多声明一个 @Input。

这里还想吐槽两句，一个组件想要引用另一个组件，要先 import 进来，然后还要加到当前组件 Component 配置的 directives 属性中。开发过程中好多次莫名其妙的报错都是因为忘了这一步……

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// Parent.js
@Component({
  selector: 'parent',
  template: `
    <h1>Parent</h1>
    <child [data]="data"></child>
  `
})
class Parent {
  data = 'react';
}

// Child.js
@Component({
  selector: 'child',
  template: `
    <h4>Child</h4>
    <p>Data from parent: {{ data }}
  `
})
class Child {
  @Input() data;
}

这个时候问题来了，当子组件发生某些变化父组件想要知道的时候，你有这么几种选择。

1. 在子组件中定一个 @Output 属性，然后父组件用 (event)=”handler()” 的语法来监听这个事件
2. 将父组件的一个 event handler 当做属性传给子组件，子组件通过调用这个方法来通知父组件（在 Redux 里，这很常见）
3. 设计一个 Service 然后分别注入到父组件和子组件之中进行通信

在我开发这个项目的时候，Angular2 的官方文档中还没有任何教程说明组件之间沟通该如何进行（现在有了），所以我果断选择了最 Redux 的那种。

结果发现，后来更新的官方文档里明确说明了不提倡使用这样的方式。

我只能说很心累……

其它

奇葩的路由设定，用 /... 定义一个非最终页面路由，以及没有一个全局的路由结构，让 Angular2 里面的路由变得非常难推导。如果你不一层一层跟踪下去，根本就无法了解整个 Angular2 应用的路由结构。

莫名其妙的报错，而且很多错误都 Google 不到答案，只能 Google 到一群绝望的开发者提出绝望的问题。看看 Github 上 Angular Repo 里那些绝望的 issue，你就知道后悔当初自己为什么要选 Angular2 作为线上项目的架构了。我自己 Watch 了很多遇到的问题，然而收到最多的更新都是「+1」。

复杂的生命周期，官方文档看了一遍又一遍，网上的例子搜了很多，又不能确定是不是最新的 API。至今没有全部弄明白 Angular2 所有的生命周期都是干嘛用的，只用过几个简单的 OnInt、AfterViewInit 和 OnChanges。

小结

写着写着快要变成吐槽 Angular2 了，其实 Angular2 有很多设计的非常不错的地方值得其它框架学习。比如内置的 ViewEncapsulation 解决了 CSS 冲突的问题，完善的 NgForm 系列表单指令能够高效的解决表单校验和提交（前提是那些语法你都学会），底层设计与 DOM 无关以便运行在 WebWorker、服务器等不同环境等等。

不管怎么样，从项目开始的 Angular2 Alpha，用到现在的 Angular2 Beta 15，学习到了很多新知识，但学到更多的还是自己原来还有这么多不知道。

后面还是会投入更多的精力在 Redux 生态建设上，毕竟团队内 React + Redux 已经全面开花结果，有必要寻找到 Redux 最优的开发实践。

结果项目上线后不久接到反馈说我开发的某个功能突然用不了了，我自己一试果然不行。但是自己明明已经做过功能测试，甚至用户也试用过，怎么会突然用不了呢？

因为是一个单页应用，我开始怀疑是别人把我的代码搞坏了。

于是我尝试 checkout 到一个比较早的 commit，发现一切功能正常，所以肯定是这个 commit 一直到 HEAD 之间的某个（或某几个）commit 把功能搞坏了。

这个时候我想起了强大的 git bisect 功能。

不知道为什么，git 的官方文档总是写的让人感觉晦涩难懂，包括 bisect 的文档。于是经过一番 Google，我摸索到了核心的使用流程：

首先，尽可能找到第一个出现问题的 commit，记录其 hash 值；然后，尽可能找到最后一个正常的 commit，记录其 hash 值。

然后我们就开始了探案过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 开始 bisect
$ git bisect start

# 录入正确的 commit
$ git bisect good xxxxxx

# 录入出错的 commit
$ git bisect bad xxxxxx

# 然后 git 开始在出错的 commit 与正确的 commit 之间开始二分查找，这个过程中你需要不断的验证你的应用是否正常
$ git bisect bad
$ git bisect good
$ git bisect good
...

# 直到定位到出错的 commit，退出 bisect
$ git bisect reset

简直是查 bug 小能手！

很久很久以前我还在当个人站长的时候，就一直琢磨着给网站买个 ssl 证书，这样用户访问的时候浏览器上的小绿锁能给人一种非常安全的印象。然而导致我最终没有上 https 的原因有：

1. 证书好贵
2. https 会影响 SEO（据说）
3. 懒（这才是真正的原因）

直到前段时间发现了 Lets Encrypt 项目，一个倡导互联网上所有网站都该使用 https 的组织，提供免费的 ssl 证书服务。

上图是 GoDaddy 的 ssl 证书报价，换句话说，Lets Encrypt 免费送你价值 62.99 刀的证书。

当然，这里提到价格并不是为了让大家薅羊毛，而是为了体现 Lets Encrypt 组织的高尚目标。希望看到本文的同学，能够享受免费 ssl 证书带来了安全和稳定，而不是产生牟利等不当想法。

使用的方法也很简单，以 nginx 为例，直接使用 Github 上 xdtianyu 同学提供的脚本即可。

操作步骤

切换到你希望保存证书及私钥的目录，我选择当前用户的 home，即 ~。

下文中所有 /path/to/ 请替换成你服务器上的实际路径；your_domain 同理替换成你自己的域名

下载脚本及配置文件

1
2
3
4

cd ~
wget https://raw.githubusercontent.com/xdtianyu/scripts/master/lets-encrypt/letsencrypt.conf
wget https://raw.githubusercontent.com/xdtianyu/scripts/master/lets-encrypt/letsencrypt.sh
chmod +x letsencrypt.sh

编辑配置文件，将第2、3、4行中的 Example.com 替换成你自己的域名

1

vim letsencrypt.conf

执行 letsencrypt 脚本，获取证书及私钥

1

./letsencrypt.sh ./letsencrypt.conf

添加 nginx alias

1
2
3
4
5
6
7
8
9

server {
  ...

  location /.well-known/ {
    alias /path/to/.well-known/;
  }

  ...
}

修改 nginx 配置，加载私钥和证书

1
2
3
4
5
6
7

server {
   listen 443 ssl;
   ssl_certificate /path/to/your_domain.chained.crt;
   ssl_certificate_key /path/to/your_domain.com.key;

   ...
}

全部操作完成后，重启 nginx 即可。

1
2
3

service nginx restart
#或 
/etc/init.d/nginx -s reload

额外配置

首先，Lets Encrypt 的证书需要每月更新，因此你需要一个 cron 命令定时运行上述脚本

1

0 0 1 * * ~/letsencrypt.sh ~/letsencrypt.conf >> /var/log/lets-encrypt.log 2>&1

其次，如果你希望重定向所有的非 https 到 https 访问，可以在 nginx 配置中添加如下 server block

1
2
3
4
5

server {
    listen 80;
    server_name your_domain.com;
    return https://your_domain.com$request_uri;
}

总的来说，Lets Encrypt 所倡导免费及普遍的 ssl 证书有利于整个互联网环境的安全化。对于某些靠流量劫持广告的 ISP 来说，苦日子要来了。

本文不是一篇介绍 Redux 的入门文章（如果大家有兴趣的话，后面可以写写），因此阅读本文至少需要以下几点基础：

1. React（熟悉）
2. Flux（了解）
3. Redux（了解）
4. ES 6（了解）

既然不是基础，那么本文着重要讲的是什么呢？其实是我在实际业务中使用 Redux 遇到的一些问题及我自己的思考。促使我写这篇文章的另一个原因是，知乎上有一位朋友私信咨询了我一些 Redux 相关的问题，让我了解到原来我遇到的问题大家也会有疑惑，因此总结成文，方便后人参考。

本文将会用类似 cookbook 的形式，通过一问一答来尝试解释 Redux 在实际应用中的问题。

问题一：一个 action 被 reducer1 处理完之后，希望 reducer2 也对这个 action 做出响应，该怎么处理？

这个问题其实要从两个方向考虑：即 reducer1 和 reducer2 对某个 action 的响应是否有先后顺序的限制。

若没有，则在 reducer1 和 reducer2 的 swtich..case.. 中针对同一个 ACTION_TYPE 做出处理即可。至于 ACTION_TYPE，则可以在触发这个 action 的 actionCreator.js 里 export 出来。如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// actionCreator.js
export const SOME_TYPE = 'SOME_ACTION_TYPE';
export function doSomeAction() {
  return {
    type: SOME_TYPE,
    payload: 123
  };
}

// reducer1.js
import { SOME_TYPE } from './actionCreator';

export default function reducer(state, action) {
  switch(action.type) {
    case SOME_TYPE: {
      // 这这个 action 做出响应
    }
  ...
}

// reducer2.js 同 reducer1.js

若有先后顺序限制，则比较复杂。我们站在整个应用的角度考虑，其实我们的需求是当触发一个 action 时，希望 reducer1 先响应这个 action 更新 state，然后 reducer2 再响应这个 action，也许还需要基于 reducer1 中最新的 store 来更新自己的 state。

这个时候，可以用我自己写的一个 Redux 中间件 —— redux-combine-action。使用这种中间件后在 actionCreator 中的逻辑大概是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// actionCreator.js
export function doSomeAction() {
  return [
    (getState, dispatch) => {
      dispatch({
        type: ACTION_TYPE_1,
        payload: 123
      });
    },
    (getState, dispatch) => {
      const state = getState();
      dispatch({
        type: ACTION_TYPE_2,
        payload: state.some.useful.data.from.state
      });
    }
  ];
}

可以看到我们在 actionCreator 中返回了一个函数数组，每个函数都获得了 getState 和 dispatch 方法。在上述代码中，首先会 dispatch 一个 ACTION_TYPE_1 的 action，假设会被 reducer1 处理，然后会 dispatch 一个 ACTION_TYPE_2 类型的 action，则会被 reducer2 处理。

对于 reducer 来说，并不关系你的业务逻辑是先处理哪一个后处理哪一个，它们只是单纯的响应每一个 action 而已。

至于其中的原理，可以自行查看源代码。（写到这的时候，自觉滚去把这个库的测试补上了）需要说明的是，这个中间件的核心思想基本是参考自 redux-combine-actions 库。

问题二：Redux 中如何实现一个公共业务组件？

一个所谓的「公共业务组件」，应该包含了 UI 和数据两部分。比如淘宝上的收货地址选择控件，应该就包含了三个 select 选择器和对应的省市区数据。这样一个地址选择控件的逻辑在各个模块中都是一致的，但是怎么设计才能实现复用呢？

一个关于 Flux/Redux 的基础概念：任何一个 actionCreator 触发的 action 都会通知到所有的 store/reducer。

考虑一种极端情况，页面上同时有两个模块都使用了这个公共的地址选择组件。当在这个组件里选择了一个省份时，会 dispatch 一个 SELECT_PROVINCE 的 action，那么两个模块怎么知道用户到底是选择了哪个模块里公共组件的省份呢？

再考虑另外一个问题，当用户选择了一个省份后，某一个业务模块希望能够再做一些别的数据处理（比如根据当前选择的省份加载对应的热销宝贝）该怎么操作呢？总不能在 reducer 中 dispatch 一个 action 吧？（注意，这是 anti-pattern，不要在 reducer 中 dispatch action！！）

其实这两个问题的解决思路是类似的，就是在公共组件中，数据传递的过程中加上更多的限制，我能想到的有这么两种解决方案：

• 公共组件自己维护状态，业务模块通过给公共组件传入回调来获得公共组件的数据变动，再 dispatch 响应的 action 更新自己的 state。这样设计的问题在于，违背了 Redux 倡导的无状态原则，公共组件内部存在了 state 和 setState 操作。
• 通过 props 传入指定的 actionType 或 actionCreator（传入 actionCreator 是我同事奇阳的想法）来让公共组件 dispatch 不同的 action，以此达到区分的效果。

一个简单的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// 公共模块自己定义的 actionCreator
import { provinceActionCreator } from './actionCreator';

// 一个公共的地址选择组件
const AddressPicker = React.createClass({
  handleChangeProvince(e) {
    // 优先使用 props 中传入的 actionCreator
    const provinceActionCreator = this.props.provinceActionCreator || provinceActionCreator;
    // dispatch 一个选择省份的 action
    this.props.dispatch(provinceActionCreator(e.target.value));
  },

  render() {
    return (
      <select onChange={this.handleChangeProvince}>
        <option>北京</option>
        <option>浙江</option>
      </select>
    );
  }
});

问题三：Redux 中跟路由有关的状态应该怎么维护？

现在用 React 做路由的话大家基本都会选择 react-router（这个库我已经吐槽过无数次了，经常改 API），而用 Redux 的话自然也是选择基于 react-router 封装的 redux-router。

在讲详细的问题之前，先要阐明一个观点，即「路由也是应用状态的一部分」，应该也的确有一个单独的 store 在维护它。

既然有一个单独的 store，那么其中的状态就能轻松的获取和设置了，具体的操作方法可以参考 redux-router 中的 API。

如果抛开 redux-router 不谈，react-router 中针对路由切换时的数据传递提供了一种全新的思路，即在切换路由时，将「state」存入 session-storage 中，借用这个功能你就可以轻松的实现「回退」操作了。

详细说明见 history 模块的文档。

小结

总的来说，使用 Redux 开发业务功能还是很爽的，尤其是对于数据流动复杂的应用，单一的数据流动、类 Immutable 的数据变动方式以及酷炫的 devtool 这些特性简直堪称神器。

本文系对 深入理解 React 的 batchUpdate 机制 的更新，根据 React v0.14 版源码添加并修改了部分内容。同时增加了一张看起来并不容易理解的示意图。

之前在我的博客里有篇文章写了「为什么 React 这么快」，其中说到一点很重要的特性就是 batchUpdate。今天就简单的分析一下 batchUpdate 究竟是怎么实现的？

首先明确一个基础概念，在调用 this.setState 之后，React 会自动重新调用 render 方法。但是如果我们多次调用 setState 方法呢？考虑下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var Example = React.createClass({
  getInitialState: function() {
    return {
      clicked: 0
    };
  },

  handleClick: function() {
    this.setState({clicked: this.state.clicked + 1});
    this.setState({clicked: this.state.clicked + 1});
  },

  render: function() {
    return <button onClick={this.handleClick}>{this.state.clicked}</button>;
  }
});

考虑这两个问题，当点击 button 时：1、 render 方法被调用了几次？2、 handleClick 中第 2 次 setState 时 this.state.clicked 值是多少？

如果你还没有把握，可以先打开这个 DEMO 查看结果。

知道结果后，你能解释为什么 render 方法只被调用了 1 次，且第二次 setState 时 this.state.clicked 依然是 0 么？

这一切，都要归功于 React 的 batchUpdate 设计，但是 batchUpdate 究竟是怎么实现的呢？让我们深入到 React 的源码中一探究竟。

以下内容由于本人能力及精力均有限，尚未深究，仅供参考。如有错误，尽请斧正！源码分析基于 React v0.14 版。

一个简单的 setState 方法，其简化的调用栈如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

this.setState                                           // ReactComponent.js
...
this.updater.enqueueSetState                            // ReactUpdateQueue.js
...
获取当前组件的 pendingStateQueue，并将新的 state push 进去 // ReactUpdateQueue.js
...
enqueueUpdate                                           // ReactUpdates.js
...
if(当前不在一次 batchUpdate 的过程中)                      // ReactUpates.js
  执行 batchingStreategy.batchUpdates 方法
else
  将当前 component 存入 dirtyComponents 数组中
...
if (setState 方法存在 callback)                          // ReactComponent.js
  调用 this.updater.enqueueCallback 将 callback 存入队列中
...

一次 setState 的过程大概就是这样，那么问题来了，setState 只是把变化存入一个临时队列中，那么新的 state 究竟是如何生效的呢？

让我们从 DOM 事件触发开发对整个链路进行一下梳理：

当一次 DOM 事件触发后，ReactEventListener.dispatchEvent 方法会被调用。而这个方法并不是急着去调用我们在 JSX 中指定的各种回调，而是调用了

1

ReactUpdates.batchedUpdates

该方法会执行一个 transaction，而要执行的内容被定义在 handleTopLevelImpl 中。再看 handleTopLevelImpl，其核心内容就是找到事件对应的所有节点并依次对这些节点 trigger 事件。

在进一步介绍之前，我们需要先了解一下 Transaction（事务）。

React 为 Transaction 封装了一个简单的 Mixin，并在源码中生动的介绍了一个 Transaction 是怎么工作的。

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

// 详见 Transaction.js

/**
 *                       wrappers (injected at creation time)
 *                                      +        +
 *                                      |        |
 *                    +-------------------------------------+
 *                    |                 v        |              |
 *                    |      +---------------+   |              |
 *                    |   +--|    wrapper1   -----+         |
 *                    |   |  +---------------+   v    |         |
 *                    |   |          +-------------+  |         |
 *                    |   |     +----|   wrapper2  -------+   |
 *                    |   |     |    +-------------+  |     |   |
 *                    |   |     |                     |     |   |
 *                    |   v     v                     v     v   | wrapper
 *                    | +---+ +---+   +---------+   +---+ +---+ | invariants
 * perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
 * +----------------->----->|anyMethod------------->
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | +---+ +---+   +---------+   +---+ +---+ |
 *                    |  initialize                    close    |
 *                    +-----------------------------------------+
 **/

实际上，Transacation 就是给需要执行的函数封装了两个 wrapper，每个 wrapper 都有 initialize 和 close 方法。当一个 transaction 需要执行（perform）的时候，会先调用对应的 initialize 方法。同样的，当一个 transaction 执行完成后，会调用对应的 close 方法。

回到刚才的问题，存入临时队列的 state 究竟是怎么被改变成真正的状态的呢？秘密就在 ReactUpdates.batchedUpdates 调用中（还记得它吗？DOM 事件的回调中被调用的方法）。这个方法实际上就是执行了一个 transaction，具体实现定义在 ReactDefaultBatchingStrategy.js 中。

这个 transaction 具体的代码就不贴了，简单的说，它定义了一个事务，当这个事务结束时，需要调用 ReactUpdates.flushBatchedUpdates 方法。

好，说到这里可能大家已经被各种名称搞昏了头，下面给大家看一个简单的流程图。

上面的流程图中只保留了部分核心的过程，看到这里大家应该明白了，所有的 batchUpdate 功能都是通过执行各种 transaction 实现的。this.setState 调用后，新的 state 并没有马上生效，而是通过 ReactUpdates.batchedUpdate 方法存入临时队列中。当一个 transaction 完成后，才通过 ReactUpdates.flushBatchedUpdates 方法将所有的临时 state merge 并计算出最新的 props 及 state。

纵观 React 源码，使用 Transaction 之处非常之多，React 源码注释中也列举了很多可以使用 Transaction 的地方，比如

• 在一次 DOM reconciliation（调和，即 state 改变导致 Virtual DOM 改变，计算真实 DOM 该如何改变的过程）的前后，保证 input 中选中的文字范围（range）不发生变化
• 当 DOM 节点发生重新排列时禁用事件，以确保不会触发多余的 blur/focus 事件。同时可以确保 DOM 重拍完成后事件系统恢复启用状态。
• 当 worker thread 的 DOM reconciliation 计算完成后，由 main thread 来更新整个 UI
• 在渲染完新的内容后调用所有 componentDidUpdate 的回调
• 等等

值得一提的是，React 还将 batchUpdate 方法暴露了出来：

1

var batchedUpdates = require('react-dom').unstable_batchedUpdates;

当你需要在一些非 DOM 事件回调的函数中多次调用 setState 等方法时，可以将你的逻辑封装后调用 batchedUpdates 执行，以此保证 render 方法不会被多次调用。

基本上本文就是对 React 官方 v0.14 博文 的翻译加上一小部分个人理解。

正文开始之前先讲个笑话，随着 React 的风靡许多基于 React 的衍生库也火得一塌糊涂，比如 React Router。如果没记错的话 React Router 的作者说过版本号永远和 React 保持一致，从 v0.10 开始确实如此。然后 v0.11，v0.12，v0.13，眼看着时间已经过去了一年多……怎么着也该出 v1.0 了吧，结果 React 发布了 v0.14，而且还规划了 v0.15，让 React Router 的若干个 v1.0-beta 版本哭瞎在厕所。

好了，回到 React v0.14 上。

React 「一分为二」

原本的 react package 被拆分为 react 及 react-dom 两个 package。其中 react package 中包含 React.createElement、 .createClass、 .Component， .PropTypes， .Children 这些 API，而 react-dom package 中包含 ReactDOM.render、 .unmountComponentAtNode、 .findDOMNode。

原本在服务端渲染用的两个 API .renderToString 和 .renderToStaticMarkup 被放在了 react-dom/server 中。

改变之后的结构，一个基本的 React 组件变成了这样：

1
2
3
4
5
6
7
8
9
10

var React = require('react');
var ReactDOM = require('react-dom');

var MyComponent = React.createClass({
  render: function() {
    return <div>Hello World</div>;
  }
});

ReactDOM.render(<MyComponent />, node);

此外，原本 React.addons 下面的工具全部变成了独立的 package：

• react-addons-clone-with-props
• react-addons-create-fragment
• react-addons-css-transition-group
• react-addons-linked-state-mixin
• react-addons-perf
• react-addons-pure-render-mixin
• react-addons-shallow-compare
• react-addons-test-utils
• react-addons-transition-group
• react-addons-update
• ReactDOM.unstable_batchedUpdates （在 react-dom 中）

当然，原本的 API 在 v0.14 版中仍然可以使用，只不过会有 warning，最终会在 v0.15 版的时候完全移除。

refs 变成了真正的 DOM 节点

当我们需要获取 React 组件上某个 DOM 节点时，React 提供了 refs 方法方便我们快速引用。为了方便我们使用，React 还「贴心」地对 refs 做了一层封装，使用 this.refs.xxx.getDOMNode() 或 React.findDOMNode(this.refs.xxx) 可以获取到真正的 DOM 节点。

结果发现大家真正需要的就是 DOM 节点本身，封装了半天完全是浪费感情。

于是在 v0.14 版中 refs 指向的就是 DOM 节点，同时也会保留 .getDOMNode() 方法（带 warning），最终在 v0.15 版中去除该方法。

1
2
3
4
5
6
7
8
9
10
11
12
13

var Zoo = React.createClass({
  render: function() {
    return <div>Giraffe name: <input ref="giraffe" /></div>;
  },
  showName: function() {
    // 之前：
    // var input = this.refs.giraffe.getDOMNode();
    //
    // v0.14 版：
    var input = this.refs.giraffe;
    alert(input.value);
  }
});

需要注意的是，如果你给自定义的 React 组件（除了 DOM 自带的标签，如 div、p 等）添加 refs，表现和行为与之前一致。

无状态的函数式组件

其实在实际业务系统中使用 React 时，我们会写很多只有 render 方法的 React 组件。为了减少冗余的代码量，React v0.14 中引入了 无状态的函数式组件（Stateless functional components） 的概念。先看看长啥样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 一个 ES6 箭头函数定义的无状态函数式组件
var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

// 或者更加简化的版本
var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);

// 最终使用方式: <Aquarium species="rainbowfish" />

可以看到，没有 React.createClass，也没有显式的 render，写起来更加轻松了。

当然，新语法也有需要注意的地方：

1. 没有任何生命周期方法，如 componentDidMount 等
2. 不能添加 refs
3. 可以通过给函数添加属性定义 propTypes 和 defaultProps

react-tools 及 JSXTransformer.js 已弃用

拥抱 Babel 吧同学们！

编译器优化

在 Babel 5.8.23 及更新的版本中，新增了两项专门针对 React 的优化配置，仅推荐在生产环境中开启，因为优化后会导致代码的报错更加扑朔迷离（本来报错就已经很难定位了……）。

• optimisation.react.inlineElements 将 JSX 元素转换为对象而非使用 React.createElement
• optimisation.react.constantElements 针对拥有完全静态子树的组件，将其创建过程提升到顶层（Top level），从而减少对 React.createElement 方法的调用

其它变化

• React.initializeTouchEvents 已弃用
• 由于 refs 的相关变化（见上文），TestUtils.findAllInRenderedTree 及相关的方法不再接受 DOM 组件作为参数，只能传入自定义的 React 组件
• props 一旦创建永远不可修改，因此 .setProps 及 .replaceProps 已废弃
• children 不可以传对象类型，推荐传入数组，或使用 React.createFragment 方法（其实就是转换为了数组）
• React.addons.classSet 已经移除，使用 classnames package 替代

将要发生的改变

在 v0.15 版中，下列内容将会发生改变：

• this.getDOMNode() 方法将会废弃，推荐使用 React.findDOMNode()
• setProps 及 replaceProps 将会废弃
• React.addons.cloneWithProps 已废弃，推荐使用 React.cloneElements，新方法不会自动 merge className 及 style
• React.addons.CSSTransitionGroup 将不再监听 transition 事件，因此使用者需要显式指定动画的 timeout，如：transitionEnterTimeout={500}。
• ES6 组件类必须 extends React.Component（如果使用 React.createClass 语法则不受影响）
• 在多次 render 中重用并改变 style 对象已经被弃用（这一点不是太明白，中心思想貌似是不要 mutate object？）

其实例子里的代码已经很老了，React Router 的 API 也发生了很多变化。因此今天抽出一晚上的时间，再以最新的 React Router 稳定版（截止 2015年08月18日21:23:40 为 v0.13.3 版，与 React 版本号一致）为基础讲讲如何使用 React Router。

阅读本文需要你有一定的 ReactJS 基础，如果你正在寻找 ReactJS 中文入门教程，推荐我参与翻译的 React - 引领未来的用户界面开发框架 一书。

快速上手

一个最基本的页面，菜单有「图书」和「电影」两个菜单项，点击「图书」显示图书列表（链接变为/books），点击「电影」显示电影列表（链接变为/movies）。

Demo

说实话，这个例子并不简单。下面逐步分析一下用到的代码和它们分别是干什么的。

1
2
3
4
5

var Router = ReactRouter; // 由于是html直接引用的库，所以 ReactRouter 是以全局变量的形式挂在 window 上
var Route = ReactRouter.Route; 
var RouteHandler = ReactRouter.RouteHandler;
var Link = ReactRouter.Link;
var StateMixin = ReactRouter.State;

由于 Demo 需要直接从网页上引用 React 和 React Router，因此它们都被挂在了 window 对象上（现在但凡有点追求的前端都上 webpack 了，但是例子的话大家就将就着看吧）。这几行就是获取 ReactRouter 提供的几个组件和 mixin。

接下来声明了 4 个组件，都是最基本的只有 render 方法的 React 组件，分别是：Movies 电影列表、Movie 电影详情、Books 图书列表、Book 图书详情。

关于组件唯一需要说明的是用到了 ReactRouter 提供的 State 这个 mixin，主要功能就是让组件能够通过 this.getParams() 或 this.getQuery() 等方法获取到当前路由的各种值或参数。

然后是应用的入口，也是我们渲染菜单的地方：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 应用入口
var App = React.createClass({
  render: function() {
    return (
      <div className="app">
        <nav>
          <Link to="movies">电影</Link>
          <Link to="books">图书</Link>
        </nav>
        <section>
          <RouteHandler />
        </section>
      </div>
    );
  }
});

这里用到了两个 ReactRouter 提供的组件：Link 和 RouteHandler。

Link 组件可以认为是 ReactRouter 提供的对 <a> 标签进行封装的组件，你可以查看 Link 组件渲染到 DOM 上其实就是 a 标签。它接受的 props 有 to、params 和 query。to 可以是一个路由的名称（下文会讲到），也可以是一个完整的 http 地址（类似 href 属性）；params 和 query 都是这个链接带的参数，下文细讲。

此外，Link 组件还有一个小特点，就是如果这个 Link 组件指向的路由被激活的话，组件会自动添加一个值为 active 的 className，方便你对当前激活的菜单项设置不同的样式（注意 demo 中红色的菜单项）。

而 RouteHandler 组件是 ReactRouter 的核心组件之一，它代表着当前路由匹配到的 React 组件。假设当前的路由为 /books，那么 App 这个组件里的 RouteHandler 其实就是 Books 组件。

那么这个关系是怎么得来的呢？就要看下面定义的页面路由了。

1
2
3
4
5
6
7
8
9

// 定义页面上的路由
var routes = (
  <Route handler={App}>
    <Route name="movies" handler={Movies} />
    <Route name="movie" path="/movie/:id" handler={Movie} />
    <Route name="books" handler={Books} />
    <Route name="book" path="/book/:id" handler={Book} />
  </Route>
);

这里又出现了另外一个 ReactRouter 提供的组件 Route，这个组件就是定义整个页面路由的基础，可以嵌套。

Route 接受的 props 包括 name、path、handler 等等。其中 name 就是上文提到的路由名称，可以通过 <Link to="路由的名称"> 来生成一个跳转到该路由的链接。path 指明的是当前路由对应的 url，如果不指定，那么默认就是 name 对应的值；如果 name 也不指定，那默认是 /，即根目录。另外 path 还支持指定 params（上文有提到），就是上面的例子中 : 及后面跟着的名称。

params 和 query 的区别在于，params 定义的是「路由」中的参数，比如 /movies/:id ，params 为 id；而 query 是 「URL」中的参数，是跟在 URL 中「?」后面的。定义路由时一般不考虑也不能限制 query 会是什么。

比如 <Route name="movies" handler={Movie} /> 就指明了一条指向 /movies 的路由，当该路由激活时，调用 Movies 这个组件进行渲染。

接下来就是最后一步，根据上面定义的路由判断出当前该渲染哪个组件，并将其渲染到 DOM 中。

1
2
3
4

// 将匹配的路由渲染到 DOM 中
Router.run(routes, Router.HashLocation, function(Root){
  React.render(<Root />, document.body);
});

Router 即 ReactRouter，run 方法接受 2 - 3个参数，其中第一个参数必填，即我们指定的路由规则。第二个参数选填，即路由的实现方式，Router.HashLocation 指明了当前页面使用 hash 变化来实现路由，反映在浏览器的地址栏中就是类似 xxx.com/#/movies 这样的地址。使用这种 Location 的好处是兼容 IE 8，如果你的应用不需要兼容 IE 8，可以使用更高级的 Router.HistoryLocation。

最后一个参数是一个回调函数，函数的第一个参数是 ReactRouter 判断出的当前路由中需要渲染的根节点组件，在这里就是 <App /> 这个组件（虽然名字叫做 Root，但在本例中 Root 指的就是 App）。

最后的最后，就是熟悉的 React API，将 Root 渲染到 DOM 中，看到的结果如下：

尝试点击一下各种链接看看效果吧！

Demo

进阶使用

上面贴了这么多代码分析了这么一大段，只实现了一个非常基础的 ReactRouter 路由例子。你在把玩这个例子的时候应该会发现，页面默认打开的时候（即路由为 / 的时候），除了菜单什么也没有显示，显得比较单调。

这个时候你有两种选择：使用 DefaultRoute 或 Redirect。

如果我们希望页面默认进来的时候除了菜单之外再显示一个类似首页的组件，那么可以用 ReactRouter 提供的 DefaultRoute。

Demo

1
2
3
4
5
6
7
8
9
10

// 定义页面上的路由
var routes = (
  <Route handler={App}>
    <Route name="movies" handler={Movies} />
    <Route name="movie" path="/movie/:id" handler={Movie} />
    <Route name="books" handler={Books} />
    <Route name="book" path="/book/:id" handler={Book} />
    <DefaultRoute handler={Index} />
  </Route>
);

注意 routes 中定义的路由，多了一个 DefaultRoute，它的 handler 是 Index 组件，即我们希望用户在默认打开页面时看到的组件内容。

如果你不想这么麻烦，想用户进来默认就看到电影列表，则可以使用 Redirect 组件。

Demo

1
2
3
4
5
6
7
8
9
10

// 定义页面上的路由
var routes = (
  <Route handler={App}>
    <Route name="movies" handler={Movies} />
    <Route name="movie" path="/movie/:id" handler={Movie} />
    <Route name="books" handler={Books} />
    <Route name="book" path="/book/:id" handler={Book} />
    <Redirect to="movies" />
  </Route>
);

可以看到，当我们直接访问这个 URL 的时候，自动被重定向到了 /movies。Redirect 同时接受 from 这个 props，可以指定当什么规则下才进行重定向。

再优化

配合 DefaultRoute 和 Redirect，我们的路由已经基本成型了，但是目前还遇到一个问题：在显示电影详情或图书详情时，对应的菜单项没有高亮。

这是为什么呢？上文说到了 Link 组件会在指向的路由被激活时自动添加值为 「active」 的 className。而我们的两个 Link 分别指向的是 /movies 和 /books。而详情页的 URL 是 /movie/1 或 /book/1 这种形式，显然不满足 Link 被激活的条件。

这个时候又有两个方案可以选择了……「嵌套路由」或是「动态判断」。

嵌套路由

让我们对路由进行一些改造：

1
2
3
4
5
6
7
8
9
10
11

// 定义页面上的路由
var routes = (
  <Route handler={App}>
    <Route name="movies" handler={Movies}>
      <Route name="movie" path=":id" handler={Movie} />
    </Route>
    <Route name="books" handler={Books}>
      <Route name="book" path=":id" handler={Book} />
    </Route>
  </Route>
);

同时改造一下图书列表和电影列表组件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

/**
 * 图书列表组件
 */
var Books = React.createClass({
  render: function() {
    return (
      <div>
        <ul>
          <li key={1}><Link to="book" params={{id: 1}}>活着</Link></li>
          <li key={2}><Link to="book" params={{id: 2}}>挪威的森林</Link></li>
          <li key={3}><Link to="book" params={{id: 3}}>从你的全世界走过</Link></li>
        </ul>
        <RouteHandler />
      </div>
    );
  }
});

注意到首先我们的路由变成了嵌套模式，原本电影列表和电影详情的路由是平级的，一个指向 /movies，一个指向 /movie/:id。改造之后，路由形成了嵌套关系，电影列表的路由依然是 /movies，而电影详情变成了 /movies/:id。

Demo

经过改造之后显示详情的时候菜单可以正确的高亮了，然而列表内容也被显示了出来，很多时候我们并不需要列表和详情同时出现，这个时候就需要另一种路由处理方式：动态判断。

其实我们的路由从最开始就存在嵌套模式，记得最外层 handler 是 App 的 Route 吗？里面所有的路由都是被嵌套的。

动态判断

让我们再次对路由进行改造：

1
2
3
4
5
6
7

// 定义页面上的路由
var routes = (
  <Route handler={App}>
    <Route name="movies" path="/movies/:id?" handler={Movies} />
    <Route name="books" path="/books/:id?" handler={Books} />
  </Route>
);

取消了嵌套在列表路由下的详情页路由，同时改造了列表页路由的 path，从原来的 /movies 改为 /movies/:id?。这样的 path 代表着这条路由匹配所有 /movies/ 开头的 URL，同时可能存在一个 id 参数，也可能不存在。

看起来路由变简单了不少，不过对应的代价是组件中的代码需要大改。

主要的变动包括：

列表组件中渲染增加逻辑动态判断

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/**
 * 图书列表组件
 */
var Books = React.createClass({
  mixins: [StateMixin],
  
  render: function() {
    
    var id = this.getParams().id;
    return id ? <Book id={id} /> : (
      <div>
        <ul>
          <li key={1}><Link to="books" params={{id: 1}}>活着</Link></li>
          <li key={2}><Link to="books" params={{id: 2}}>挪威的森林</Link></li>
          <li key={3}><Link to="books" params={{id: 3}}>从你的全世界走过</Link></li>
        </ul>
        <RouteHandler />
      </div>
    );
  }
});

详情页组件不再从路由中获取数据，而是根据父组件提供的 props 进行渲染：

1
2
3
4
5
6
7
8
9
10
11
12

/**
 * 单本图书组件
 */
var Book = React.createClass({
  render: function() {
    return (
      <article>
       <h1>这里是图书 id 为 {this.props.id} 的详情介绍</h1>
      </article>
    );
  }
});

Demo

静态方法

ReactRouter 还提供了 willTransitionTo 和 willTransitionFrom 两个静态方法，用于某个组件将要被激活和某个组件将要被取消激活时进行拦截或进行相关操作。

由于这两个 API 很可能在 1.0 正式版中被砍掉，这里就不多做介绍了。

ReactRouter 小结

花了一个晚上的时间把自己一年前挖下的坑松了松土，看到这里你以为自己已经学会 ReactRouter 怎么用了吗？呵呵，偷偷告诉你，ReactRouter 1.0 的 API 变化挺大的（目前已有 1.0 beta3 版）。这个库非常激进，维护的非常频繁，带来的后果就是 API 变动也很频繁。

不管怎么样，拥抱变化吧！

React Router 官方文档

IE 9 的样式表限制

IE 对 CSS 选择器的支持非常有限，按理说 IE 9 应该基本算是一个可以用的浏览器了，然而，它对于样式表也有变态的限制。具体限制规则如下：

• 一个样式表（.css 文件）最多只能包含 4,095 个选择器
• 一个样式表最多只能 @import 31 个样式表
• @import 指令最多只能嵌套 4 层

其中我就结结实实的踩中了第一个坑，因为我们的应用非常复杂，所以单独抽出了一个基础库，包含了多个页面公用的 js 和 css，谁曾想公共的 css 文件选择器数量不知不觉已经达到了 4,300 多个。这样直接导致的后果就是部分选择器及样式被 IE 9 无情的抛弃了。

解决方案：不要触犯以上规则，拆分样式表，去除不必要的选择器

解决工具：gulp-legacy-ie-css-lint

来源参考：so

IE 8 下 resize 事件的频繁触发

最近因为业务需要写了一个 react-lazyload 组件（非常好用喔，已经在阿里的对外业务上全面铺开使用了），但是在 IE 8 下性能巨差。经过艰难的断点调试发现，lazyload 的回调被调用的太过频繁了（即使已经加了 300ms 的 debounce）。经过一番 Google 后发现，IE 8 处理 resize 事件的方式简直是变态。

根据 MDN 的描述：

The resize event is fired when the document view has been resized.

resize 事件应该是当文档可视区域发生变化时触发的（即当你放大或缩小浏览器窗口时），而 IE 8 下却不是。IE 8 下触发 resize 事件的逻辑是：

当一个元素的尺寸发生改变的时候，就触发 resize 事件

这样当你更新 DOM 节点的时候，resize 事件的触发频率及次数可想而知。

解决方案：不需要使用 resize 事件的时候尽量不要绑定这个事件；实在需要的话在 DOM 可能发生改变前解除 resize 事件的绑定，在 DOM 更新完成后重新监听 resize 事件

来源参考：so

这里多说一句，很多应用在 IE 8 下觉得卡顿，也可以检查一下是否因为绑定了 resize 事件的缘故。

详细的原理在这篇博文 里都有解释，本文不再赘述。简单地说，就是在一级菜单项 mouseenter 的时候，根据鼠标之前的移动坐标，判断用户当前是否是想移动到二级菜单。若是，则 setTimeout 一段时间，再重新判断；若不是，则直接激活当前一级菜单项。

一图胜千言：

Demo

目前已经有人根据这个原理写了一个 jQuery 插件 jQuery-menu-aim，而我由于在最近的 React 项目中需要使用这个功能，就顺手写了一个 React 版本。

使用的方法也很简单，引入 react-menu-aim 作为一个 mixin，然后在 componentWillMount 的时候配置一下，最后在 render 的时候调用 mixin 提供的一些事件响应方法即可。

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

var React = require('react');
var ReactMenuAim = require('react-menu-aim');

var Menu = React.createClass({
  // 使用 ReactMenuAim mixin
  mixins: [ReactMenuAim],

  componentWillMount: function() {
    // 在这里配置 ReactMenuAim
    this.initMenuAim({
      submenuDirection: 'right',
      menuSelector: '.menu'
    });
  },

  // 由于 ReactMenuAim 需要响应组件的 mouseenter 等事件，所以若你也需要
  // 响应这些事件，可以把自己的 event handler 作为参数传给 ReactMenuAim
  // 提供的 event handler。
  //
  // 例如下面就是组件自己的 event handler
  handleSwitchMenuIndex: function(index) {
    // ...
  },


  // this.handleMouseLeaveMenu 和 this.handleMouseEnterRow 是 
  // ReactMenuAim 提供的方法，让它们分别响应鼠标离开菜单和鼠标进入每一个
  // 一级菜单选项的事件。
  //
  // 若 ReactMenuAim 判定应该激活当前 mouseenter 的一级菜单时，会调用
  // 传入的回调。在这个例子里，就是我们自己的 this.handleSwitchMenuIndex 方法
  render: function() {
    return (
      <div className="menu-container">
        <ul className="menu" onMouseLeave={this.handleMouseLeaveMenu}>
          <li className="menu-item" onMouseEnter={this.handleMouseEnterRow.bind(this, 0, this.handleSwitchMenuIndex)}>Menu Item 1</li>
          <li className="menu-item" onMouseEnter={this.handleMouseEnterRow.bind(this, 1, this.handleSwitchMenuIndex)}>Menu Item 1</li>
        </ul>
      </div>
    );
  }
});

更多的配置项见 github repo。

废话少说，直接上代码：

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

var Parent = React.createClass({
  getInitialState: function() {
     return {
       text: 'default'
     };
  },
  
  handleChildClick: function(){
    this.setState({
      text: Math.random() * 1000
    });
  },
  
  render: function(){
    console.log('parent render');
    
    return (
      <div className="parent">
       this is parent!
       <Child text={this.state.text} onClick={this.handleChildClick} />
      </div>
    );
  }
});


var Child = React.createClass({
  getInitialState: function() {
    return {
     text: this.props.text + '~'
    };
  },
  
  componentWillReceiveProps: function(nextProps) {
    this.setState({
      text: nextProps.text + '~'
    });
  },
  
  handleClick: function(){
    this.setState({
      text: 'clicked'
    });
    
    this.props.onClick();
  },
  
  render: function() {
    console.log('child render');
    
    return (
     <div className="child">
       I'm child
       <p>something from parent:</p>
       <p>{this.state.text}</p>
       <button onClick={this.handleClick}>click me</button>
     </div>
    );
  }
});

React.render(<Parent/>, document.body);

DEMO

当组件首次渲染时，console 输出内容如下：

1
2

parent render
child render

下面考虑点击 Child 中的 button，问 console 中输出的内容是怎样的？

让我们看看 Child 的 handleClick，首先调用了一次 setState

1
2
3

this.setState({
  text: 'clciked'
});

然后调用了 Parent 的 onClick 回调。而 Parent 的 handleChildClick 方法更新了自己的 state，从而触发了新一轮的 render。

那么，console 中输出的内容莫非是：

1
2
3

child render   // Child setState
parent render  // Parent setState
child render   // Parent state 更新，Child 跟着 re-render

但实际情况是：

1
2

parent render
child render

我们预期的 Child 调用 setState 导致的 render 似乎并没有发生。

下面再来一个简单点的例子：

1
2
3
4
5
6
7
8
9
10
11
12

//...
  handleClick: function() {
    this.setState({
      text: 'clicked'
    });
    
    var newText = this.state.text + ' agian';
    this.setState({
      text: newText
    });
  }
//...

如果我们把 Child 的 handleClick 改写成上面这样，render 的触发情况又是怎样的呢？Child 的 state 中 text 的值又是什么呢？

答案见 DEMO，本文不再赘述。

到这里，我们已经领会了 batchUpdate 的强大之处，但是 batchUpdate 究竟是怎么实现的呢？让我们深入到 React 的源码中一探究竟。

以下内容由于本人能力及精力均有限，尚未深究，仅供参考。如有错误，尽请斧正！

首先，我们在 Child 的 handleClick 中调用了 setState，其简化的调用栈如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

this.setState
...
this.replaceState
...
将更新后的 state 保存为 this._pendingState
...
if (不是在 componentWillMount 的生命周期中)
ReactUpdates.enqueneUpdate
...
将当前 component 存入 dirtyComponents 数组中
...
if (存在 callback)
将 callback 保存到 component._pendingCallbacks 数组中
...

一次 setState 调用就这么结束了，而下一行调用 this.props.onClick() 触发的也是 Parent 的 setState，整体调用栈类似。

那么问题来了，两次 setState 都是把变化存入一个 pending 数组中，那么变化最后究竟是怎么起作用的呢？

实际上我们看看一次事件触发的完整调用栈就能大概明白了。

当一次 DOM 事件触发后，ReactEventListener.dispatchEvent 方法会被调用。而这个方法并不是急着去调用我们在 JSX 中指定的各种回调，而是调用了

1

ReactUpdates.batchedUpdates

这个方法就是 React 整个 batchUpdate 思想的核心。该方法会执行一个 transaction，而要执行的内容被定义在 handleTopLevelImpl，其实就是找到事件对应的所有节点并依次对这些节点触发事件。

在进一步介绍之前，我们需要先了解一下 Transaction。

React 为 Transaction 封装了一个简单的 Mixin，并在源码中生动的介绍了一个 Transaction 是怎么工作的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
 *                       wrappers (injected at creation time)
 *                                      +        +
 *                                      |        |
 *                    +-------------------------------------+
 *                    |                 v        |              |
 *                    |      +---------------+   |              |
 *                    |   +--|    wrapper1   -----+         |
 *                    |   |  +---------------+   v    |         |
 *                    |   |          +-------------+  |         |
 *                    |   |     +----|   wrapper2  -------+   |
 *                    |   |     |    +-------------+  |     |   |
 *                    |   |     |                     |     |   |
 *                    |   v     v                     v     v   | wrapper
 *                    | +---+ +---+   +---------+   +---+ +---+ | invariants
 * perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
 * +----------------->----->|anyMethod------------->
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | +---+ +---+   +---------+   +---+ +---+ |
 *                    |  initialize                    close    |
 *                    +-----------------------------------------+
 **/

实际上，Transacation 就是给需要执行的函数封装了两个 wrapper，每个 wrapper 都有 initialize 和 close 方法。当一个 transaction 需要执行（perform）的时候，会先调用对应的 initialize 方法。同样的，当一个 transaction 执行完成后，会调用对应的 close 方法。

回到刚才的问题，pending 的状态究竟是怎么被改变成真正的状态的呢？其实在刚开始的时候，一个事件触发后 ReactEventListener.dispatchEvent 被调用，这个函数中调用了 batchingStrategy 的 batchUpdate 方法。而 batchingStrategy 中使用了一个 ReactDefaultBatchingStrategyTransaction 的示例 transaction， 那么这个名字超长的类究竟干了什么？

1
2
3
4
5
6
7
8
9
10
11
12
13

function ReactDefaultBatchingStrategyTransaction() {
  this.reinitializeTransaction();
}

assign(
  ReactDefaultBatchingStrategyTransaction.prototype,
  Transaction.Mixin,
  {
    getTransactionWrappers: function() {
      return TRANSACTION_WRAPPERS;
    }
  }
);

注意它被 assgin 的 getTransactionWrappers 方法，返回了一个常量 TRANSACTION_WRAPPERS。

看到这里你应该就明白了，这个常量里定义了最后把 pendingState 改写为真正的 state 的方法。

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

var NESTED_UPDATES = {
  initialize: function() {
    this.dirtyComponentsLength = dirtyComponents.length;
  },
  close: function() {
    if (this.dirtyComponentsLength !== dirtyComponents.length) {
      // Additional updates were enqueued by componentDidUpdate handlers or
      // similar; before our own UPDATE_QUEUEING wrapper closes, we want to run
      // these new updates so that if A's componentDidUpdate calls setState on
      // B, B will update before the callback A's updater provided when calling
      // setState.
      dirtyComponents.splice(0, this.dirtyComponentsLength);
      flushBatchedUpdates();
    } else {
      dirtyComponents.length = 0;
    }
  }
};

var UPDATE_QUEUEING = {
  initialize: function() {
    this.callbackQueue.reset();
  },
  close: function() {
    this.callbackQueue.notifyAll();
  }
};

var TRANSACTION_WRAPPERS = [NESTED_UPDATES, UPDATE_QUEUEING];

我们需要关注的就是 NESTED_WRAPPER 中的 close 方法，也就是这个方法指明了当所有的事件触发响应结束后，flushBatchUpdates()。至于究竟是怎么 flush 的，本文暂不深究。

纵观 React 源码，使用 Transaction 之处非常之多，React 源码注释中也列举了很多可以使用 Transaction 的地方，比如

• 在一次 DOM reconciliation（调和，即 state 改变导致 Virtual DOM 改变，计算真实 DOM 该如何改变的过程）的前后，保证 input 中选中的文字范围（range）不发生变化
• 当 DOM 节点发生重新排列时禁用事件，以确保不会触发多余的 blur/focus 事件。同时可以确保 DOM 重拍完成后事件系统恢复启用状态。
• 当 worker thread 的 DOM reconciliation 计算完成后，由 main thread 来更新整个 UI
• 在渲染完新的内容后调用所有 componentDidUpdate 的回调
• 等等

但是最近在用 ES 6 写测试代码时，chai 会报如下错误：

1

TypeError: Unable to access callee of strict mode function

经过一番研究我发现如下几个点：

1. chai 不支持 strict mode
2. Babel 在将 ES6 module 转换为 ES5 时会自动添加 "use strict"; 指令（这也是 ES 6 的规范）

因为我的测试代码也是用 ES 6 编写，Babel 在转换时给测试代码添加了严格模式的指令，导致 chai 的 expect 方法报错了。

解决方法比较简单：

1. 在使用 Babel 转换 ES6 代码时可以传入参数 {blacklist: strict}，如果使用命令行，可以使用 babel xxx.js --blacklist=strict （在正常的业务代码中不建议使用该参数）
2. 如果使用了 Webpack 或 Browserify，要在配置文件中忽略掉 node_modules 文件夹

最近工作繁忙，博客更新的太慢……