有时候我们打开进程管理器，发现 node 进程一直在运行，但是我们并不知道它在做什么。
如果通过不停打日志的方式来找出原因，会非常耗时，而且不一定能找到问题所在。因为一个异步操作可能是由于另外一个异步操作触发的，这样就会导致我们很难找到根本原因，或者说定位过程会非常艰难。 那么有没有一种更有效率的方法可以帮助我们找出为什么 node 进程一直在运行呢？
kuma 是一个炙手可热的 css-in-js 的解决方案，有人甚至说他是 css-in-js 的未来，这篇文章我们来探讨一下 css-in-js 与 kuma。
在我们的应用中，难免会遇到一些异常情况，比如网络请求失败，或者是用户输入了一些非法的数据等等。这些异常情况如果没有得到处理，就会导致应用崩溃，从而影响用户体验。而 Error Boundaries 就是用可以处理这些异常情况中的一部分。
大家眼里的自动化框架一般都和测试进行绑定，这也可以理解， 毕竟自动化的目的就在于模拟用户行为，确认是否正常工作，代替传统的手工测试。
但实际上自动化和测试是两个问题，我们完全可以单独实现。
比如我可以将自动化框架 A 和 测试框架 B 结合起来使用。也可以将自动化框架 A 和 测试框架 C 一起使用。二者本应该是独立的。
因此本文将只聚焦自动化部分。如果需要扩展自动化测试功能，那么只需要集成一个测试框架进行简单接入就好了，不算复杂。
浏览器为了安全引入了同源策略，这直接导致默认情况下前后端域名如果不同，那么则功能会受限。 随着前后端分离的发展，前端和后端职责的分离，前端会有专门的本地开发服务器(local dev server)用于本地开发。这个时候和后端接口联调时就很可能会遇到跨域安全问题。
这本身是浏览器的一种安全策略，但是却对前端开发造成了影响。如何解决呢？
最近有粉丝和我交流面试遇到的算法题。其中有一道题比较有意思，分享给大家。
ta 说自己面试了一家某大型区块链的公司的前端岗位，被问到了一道算法题。这道题也是一个非常常见的题目了，力扣中也有原题 110. 平衡二叉树，难度为简单。
不过面试官做了一点点小的扩展，难度瞬间升级了。我们来看下面试官做了什么扩展。
最近公司在推行单元测试，但是一些同事对于单元测试只是了解，甚至不怎么了解。因此推动单元测试的阻碍是有的，这种阻碍除了人的层面，还有基础设施的层面。希望通过本文，一方面加深大家对前端测试最佳实践的认知，另一方面可以作为手册，在日常开发中做参考。本文也会不断更新，期待你的参与。
如果大家对前端测试不太清楚，可以先看下文末我写的科普短文。如果你已经对前端测试有所了解，并且希望对前端测试有更深入的了解，以及对如何写出更好的单元测试有兴趣的话，那就让我们开始吧。
TypeScript 的学习资料非常多，其中也不乏很多优秀的文章和教程。但是目前为止没有一个我特别满意的。原因有：
- 它们大多数没有一个清晰的主线，而是按照 API 组织章节的，内容在逻辑上比较零散。
- 大多是“讲是什么，怎么用“，而不是”讲为什么，讲原理“。
- 大多数内容比较枯燥，趣味性比较低。都是干巴巴的文字，没有图片，缺乏能够引起强烈共鸣的例子。
因此我的想法是做一套不同市面上大多数的 TypeScript 学习教程。以人类认知的角度思考问题，学习 TypeScript，通过通俗易懂的例子和图片来帮助大家建立 TypeScript 世界观。
系列安排：
- 上帝视角看 TypeScript
- TypeScript 类型系统
- types 和 @types 是什么？
- 你不知道的 TypeScript 泛型（万字长文，建议收藏）
- TypeScript 配置文件该怎么写？
- TypeScript 是如何与 React，Vue，Webpack 集成的？
- TypeScript 练习题(第一弹)
目录将来可能会有所调整。
注意，我的系列文章基本不会讲 API，因此需要你有一定的 TypeScript 使用基础，推荐两个学习资料。
结合这两个资料和我的系列教程，掌握 TypeScript 指日可待。
接下来，我们通过几个方面来从宏观的角度来看一下 TypeScript。
除了调试，处理异常或许是程序员编程时间占比最高的了。我们天天和各种异常打交道，就好像我们天天和 Bug 打交道一样。因此正确认识异常，并作出合适的异常处理就显得很重要了。
我们先尝试抛开前端这个限定条件，来看下更广泛意义上程序的报错以及异常处理。不管是什么语言，都会有异常的发生。而我们程序员要做的就是正确识别程序中的各种异常，并针对其做相应的异常处理。
然而，很多人对异常的处理方式是事后修补，即某个异常发生的时候，增加对应的条件判断，这真的是一种非常低效的开发方式，非常不推荐大家这么做。那么究竟如何正确处理异常呢？由于不同语言有不同的特性，因此异常处理方式也不尽相同。但是异常处理的思维框架一定是一致的。本文就前端异常进行详细阐述，但是读者也可以稍加修改延伸到其他各个领域。
本文讨论的异常指的是软件异常，而非硬件异常。
1 / 3