最近看到一个ECMAScript新动态——Optional Chaining在6月5号进入了stage2。Stage2表明委员会已经认可这个新feature，并希望最终能加入到ECMAScript标准中去。我对Optional Chaining（以下简称OC）还是挺感兴趣的，本文就借此机会谈一谈这个新特性。
概述
OC是一个很有名的语法，C#、Swift、Kotlin、Ruby等很多知名语言都有实现。虽然语义上有些许差异，不过大致方向基本相同，语法基本都是以问号和点（?.）的形式表示。一般来说，OC主要有以下三种使用场景，静态调用、动态调用、函数调用：
obj?.prop // optional static property access
obj?.[expr] // optional dynamic property access
func?.(...args) // optional function or method call
当?.前面的变量为null或是undefined时，直接返回undefined。
// undefined if `a` is null/undefined, `a.b` otherwise.
a?.b
a == null ? undefined : a.b
// undefined if `a` is null/undefined, `a[x]` otherwise.
a?.[x]
a == null ? undefined : a[x]
// undefined if `a` is null/undefined, throws a TypeError if `a.b` is not a function,
//otherwise, evaluates to `a.b()`
a?.b()
a == null ? undefined : a.b()
// undefined if `a` is null/undefined,throws a TypeError if `a` is neither null/undefined,
//nor a function invokes the function `a` otherwise
a?.()
a == null ? undefined : a()
它主要解决的问题是：当访问树状结构的对象时，需要逐个判断中间节点是否有效。举个例子，我们想获取地址里的街道信息，但是并不确定地址本身是否存在，因此只能在获取街道前，事先判断一下地址合法性，JS中一般有如下三种写法：
if( address ) {
var street = address.street;
}
var street = address ? address.street : undefined;
var street = address && address.street;
OC的写法如下（还是能短几个字符的）：
var street = address?.street;
上面的例子比较简单，但是更深层次的结构，比如从国别、省份、城市、街道一路下去寻找地址信息，每一层都需要判断是否为undefined，这个代码就会很恶心了。如果使用OC语法糖，可以急速提高可读性：
let street = nation?.province?.city?.street
Babel
得益于Babel的插件@babel/plugin-proposal-optional-chaining，我很早就在开发中使用OC了。
方法很简单，先安装babel的OC插件，再在配置文件里加一行plugins即可，心动的朋友们马上可以尝试了。
yarn add -D @babel/plugin-proposal-optional-chaining
//.babelrc
{
"plugins": ["@babel/plugin-proposal-optional-chaining"]
}
需要注意的是：一般我们都会用eslint，事先得加上新的parserOptions，不然lint会一直报错。
//.eslintrc.js
module.exports = {
parserOptions: {
parser: 'babel-eslint'
},
...
}
Typescript
TS是JS的超级，不过由于种种原因TS也没实现这个语法糖。我曾经试过在TS里用babel插件转义OC，不过VS Code没法支持，遂放弃。
后来找了些折中的方案。
-
ramda pahtOr
R.pathOr('N/A', ['a', 'b'], {a: {b: 2}}); //=> 2 R.pathOr('N/A', ['a', 'b'], {c: {b: 2}}); //=> "N/A"没用过ramda的同学可能看起来有点费劲，pathOr的参数是从右到左看的，等价于：
const obj = {a: {b: 2}}; const res = obj?.a?.b ?? 'N/A'说到这里我顺便提一下
??这个语法糖，叫nullish coalescing operator，也是最近刚被提到stage2的新特性，它是用来代替||的。在上面的例子里，用||并且b=0的话，res = 0 || 'N/A'，返回就错了；使用??就是来避免这类bug的。 -
loadash _get
loadash参数正好与ramda相反，从左到右，而且第二个参数可以是Array或String：
_.get({ a: { b: 2 } }, ['a', 'b'], 'N/A'); _.get({ a: { b: 2 } }, 'a.b', 'N/A'); -
ts-optchain
后来我又找到了一个更好玩的库，只要给第一级对象包一层oc方法，就可以一路点下去了；链路够长的话，甚至比
?.语法糖更节省字符。import { oc } from 'ts-optchain'; const obj: T = { /* ... */ }; const value = oc(obj).propA.propB.propC(defaultValue);前提是给tsconfig.json加一个compiler plugins：
// tsconfig.json { "compilerOptions": { "plugins": [ { "transform": "ts-optchain/transform" }, ] }, }
边界情况
一般开发中，我们掌握上面概述里的OC语法其实也够用了。不过某些场景下，可能会出现一些歧义。
短路
如下，如果a不为null或undefined，x会自增。
a?.[++x]
但是a为null或undefined时，怎么办呢？应该是x不变，理由是OC本质上是一种语法糖，最终会转换为如下三元表达式，自然不会调用++x。
a == null ? undefined : a[++x]
安全调用
在JS的OC里，作用域仅限于调用处，假如后续只用.不使用?.，调用安全是不保障的，就是说如果某一层出现undefined，JS会抛出异常。
a?.b.c(++x).d
a == null ? undefined : a.b.c(++x).d
也许你会觉得这个有什么好争议的。但是，某些语言（如C#、CoffeeScript）会将安全保护一路延续下去；还有上面提到的ts-optchain也是这么使用的——a?.b.c(++x).d会等价于a?.b?.c?.(++x)?.d。对某些开发人员来说，你认为的理所当然可能会导致他人极大的困惑。
Delete
OC是支持安全删除的，这点我不是很能理解，但是委员会的解释是：“为什么不支持呢？”嗯，有理有据，无可辩驳。
delete a?.b
a == null ? true : delete a.b
分组
(a?.b).c和a?.b.c是不一样的。
(a?.b).c
(a == null ? undefined : a.b).c
a?.b.c
a == null ? undefined : a.b.c
注意到没？括号优先级是高于点，在a为undefined时，解析出了undefined.c——这个会抛异常的。所以在使用OC时，尽量不要添加括号，以免引起不必要的麻烦。
轶事
后来我又看了一下Q&A版块，还是挺欢乐的。比如：
- 为什么语法是
?.而不是.? - 为什么
null?.b的结果不是null
是不是很无聊的问题？这是委员每天都在争论的话题。看看它们的回答：
-
.?会与三元表达式冲突，比如1.?foo : bar - 由于
.表达式不关心.前面对象的类型，它的目的是访问.后面的属性，因此不会因为null?.b就返回null，而是统一返回undefined
还有一些边边角角的特性，比如：
- 安全的 construction: new a?.()
- 安全的 template literal：a?.`string`
- 安全的赋值：a?.b = c
- 自增，自减：a?.b++, --a?.b
- 解构赋值： { x: a?.b } = c, [ a?.b ] = c
- for 循环中的临时赋值：for (a?.b in c), for (a?.b of c)
这些问题对开发者的理解成本较大，有些会支持，有些不会支持，有些委员会甚至都不想讨论了。这也难过OC提案这么多年才刚刚突破stage2。
小结
以前我也觉得OC这么甜的语法糖，应该尽早推出，不该整天瞎逼逼些无聊的话题。但事实上语言设计者的思考比我等深远许多。JS本身就是很好的反面教材，当年语言设计过于冲忙，直接导致了许多语法级别的bug；之后积重难返，给web开发留下了无数的巨坑。一个新语法的特性不是三言两语，或是拍拍脑袋就决定的。我就没有考虑过OC有这么多边界问题，其实归根结底还是自己碰到的具体案例太少，没有思考过特定场合的语义特性。有时候我们在埋怨某些语言多年止步不前时候，也可以思考一下其中的难点。