一觉醒来,竟发现自己看不懂 JS 了?
共 19768字,需浏览 40分钟
·
2021-06-24 17:43
作者:林不渡
https://juejin.cn/post/6974330720994983950
前言
最近看到了一些很有趣的 ES 提案,如 Record 与 Tuple 数据类型,思路来自 RxJS 的 Observable,借鉴自函数式编程的 throw Expressions,带来更好错误处理的Error Cause
等,可以认为一旦这些提案完全进入到 ES 新特性中,前端 er 们的工作效率又会 upup,这篇文章就来介绍一下我认为值得关注的 ES 提案。
作为前端同学,即使你没有去主动了解过,应该也或多或少听说过 ECMA、ECMAScript、TC39、ES6(这个当然了)这些词,你可能对这些名词代表的概念一知半解甚至是从未了解过,但这很正常,不知道这些名词的关系并不影响你将 ES 新特性用的如臂使指。但了解一下也不亏?所以在开始正式介绍各种提案前,我们有必要先了解一下这些概念。
以下关于背景的介绍大部分来自于雪碧老师的JavaScript20 年-创立标准[1]一节。
ECMA(European Computer Manufacturers Association,欧洲计算机制造商协会)[2],这是一个国际组织,主要负责维护各种计算机的相关标准。我们都知道 JavaScript 这门语言最早来自于网景(Netscape),但网景在和微软(IE)的竞争落得下风,为了避免最终 Web 脚本主导权落入微软手中,网景开始寻求 ECMA 组织的帮助,来推动 JavaScript 的标准化。 在 1996 年,JavaScript 正式加入了 ECMA 大家庭,我们后面会叫它 ECMAScript(下文简称 ES)。TC39 则是 ECMA 为 ES 专门组织的技术委员会(Technical Committee),39 这个数字则是因为 ECMA 使用数字来标记旗下的技术委员会。TC39 的成员由各个主流浏览器厂商的代表构成(因为毕竟最后还要这些人实现嘛)。 ECMA-262 即为 ECMA 组织维护的第 262 条标准,这一标准是在不断演进的,如现在是2020 年 6 月发布的第 11 版[3]。同样的,目前最为熟知的是2015 年发布的 ES6[4]。你还可以在TC39 的 ECMA262 官网[5]上看到 ES2022 的最新草案。 ECMA 还维护着许多其他方面的标准,如ECMA-414[6],定义了一组 ES 规范套件的标准;ECMA-404[7],定义了 JSON 数据交换的语法;甚至还有 120mm DVD 的标准:ECMA267[8]。 对于一个提案从提出到最后被纳入 ES 新特性,TC39 的规范中有五步要走: stage0(strawman),任何 TC39 的成员都可以提交。 stage1(proposal),进入此阶段就意味着这一提案被认为是正式的了,需要对此提案的场景与 API 进行详尽的描述。 stage2(draft),演进到这一阶段的提案如果能最终进入到标准,那么在之后的阶段都不会有太大的变化,因为理论上只接受增量修改。 state3(candidate),这一阶段的提案只有在遇到了重大问题才会修改,规范文档需要被全面的完成。 state4(finished),这一阶段的提案将会被纳入到 ES 每年发布的规范之中。 有兴趣的同学可以阅读 The TC39 process for ECMAScript features[9] 了解更多。
Record & Tuple(stage2)
proposal-record-tuple[10] 这一提案为 JavaScript 新增了两种数据结构:Record(类似于对象) 和 Tuple(类似于数组),它们的共同点是都是不可变的(Immutable),同时成员只能是原始类型以及同样不可变的 Record 和 Tuple。正因为它们的成员不能包含引用类型,所以它们是 按值比较 的,成员完全一致的 Record 和 Tuple 如果进行比较,会被认为是相同的('==='会返回 true)。
你可能会想到社区其实对于数据不可变已经有不少方案了,如 ImmutableJS 与 Immer。而数据不可变同样是 React 中的重要概念。
使用示例:
// Record
const proposal = #{
id: 1234,
title: "Record & Tuple proposal",
contents: `...`,
keywords: #["ecma", "tc39", "proposal", "record", "tuple"],
};
// Tuple
const measures = #[42, 12, 67, "measure error: foo happened"];
个人感想:会是很有用的新成员,尤其是在追求性能优化下以及 React 项目中,gkdgkd。
.at()
Relative Indexing Method (stage 3)
proposal-relative-indexing-method[11]提案引入了at()
方法,用于获取可索引类(Array, String, TypedArray)上指定位置的成员。
在过去 JavaScript 中一直缺乏负索引相关的支持,比如获取数组的最后一个成员需要使用arr[arr.length-1]
,而无法使用arr[-1]
。这主要是因为 JavaScript 中[]
可以对所有对象使用,所以arr[-1]
返回的是 key 为-1
的属性值,而非索引为-1(从后往前排序)的数组成员。
而要获取数组的倒数第 N 个成员,通常使用的方法是arr[arr.length - N]
,或者arr.slice(-N)[0]
,两种方法都有各自的缺陷,因此at()
就来救场了。
另外,还存在获取数组最后一个成员的提案,proposal-array-last[12] (stage1)与获取数组最后一个符合条件的成员的提案 proposal-array-find-from-last[13]。
个人感想:来得有点晚,但也不算晚。
Temporal (stage 3)
proposal-temporal[14]主要是为了提供标准化的日期与时间 API,这一提案引入了一个全局的命名空间 Temporal(类似于 Math、Promise)来引入一系列现代化的日期 API(JavaScript 的 Date API 谁用谁知道嗷,也难怪社区那么多日期处理库了),如:
Temporal.Instant
获取一个固定的时间对象:
const instant = Temporal.Instant.from("1969-07-20T20:17Z");
instant.toString(); // => '1969-07-20T20:17:00Z'
instant.epochMilliseconds; // => -14182980000
Temporal.PlainDate
获取 calendar date:
const date = Temporal.PlainDate.from({ year: 2006, month: 8, day: 24 }); // => 2006-08-24
date.year; // => 2006
date.inLeapYear; // => false
date.toString(); // => '2006-08-24'
Temporal.PlainTime
获取 wall-clock time(和上面一样,不知道咋翻译):
const time = Temporal.PlainTime.from({
hour: 19,
minute: 39,
second: 9,
millisecond: 68,
microsecond: 346,
nanosecond: 205,
}); // => 19:39:09.068346205
time.second; // => 9
time.toString(); // => '19:39:09.068346205'
Temporal.Duration
获取一段时间长度,用于比较时间有奇效
const duration = Temporal.Duration.from({
hours: 130,
minutes: 20,
});
duration.total({ unit: "second" }); // => 469200
更多细节参考ts39-proposal-temporal docs[15]。
个人感想:同样,来得有点晚,但也不算晚。
Private Methods (stage 3)
private-methods[16] 提案为 JavaScript Class 引入了私有属性、方法以及 getter/setter,不同于 TypeScript 中使用private
语法,这一提案使用#
语法来标识私有成员,在阮老师的ES6 标准入门[17]中也提到了这一提案。
所以这个提案已经过了多少年了...
参考阮老师给的例子:
class IncreasingCounter {
#count = 0;
get value() {
console.log("Getting the current value!");
return this.#count;
}
increment() {
this.#count++;
}
}
类似的,还有一个同样处于 stage3 的提案proposal-class-fields[18]引入了static
关键字。
个人感想:对我来说用处比较小,因为毕竟都是写 TS,几乎没有什么机会在 JavaScript 中写 Class 了。但是这一提案成功被引入后,可能会使得 TS 到 JS 的编译产物变化,即直接使用 JS 自身的static
、#
语法。比如现在这么一段 TS 代码:
class A {
static x1 = 8;
}
编译结果是:
"use strict";
class A {}
A.x1 = 8;
而在static
被引入后,则会直接使用static
语法。
Top-level await
(stage4)
我记得这篇文章开始写的时候,这个提案还在 stage3 的,我到底鸽了多久...
proposal-top-level-await[19]这个提案感觉就没有啥展开描述的必要了,很多人应该已经用上了。简单地说,就是你的await
语法不再和async
强绑定了,你可以直接在应用的最顶层使用await
语法,Node 也从 14.8 开始支持了这一提案。
个人感想:可以少写一个 async 函数了,奈斯奥。
Import Assertions (stage 3)
proposal-import-assertions[20] 这一提案为导入语句新增了用于标识模块类型的断言语句,语法如下:
import json from "./foo.json" assert { type: "json" };
import("foo.json", { assert: { type: "json" } });
注意,对 JSON 模块的导入最开始属于这一提案的一部分,后续被独立出来作为一个单独的提案:proposal-json-modules[21]。
这一提案最初起源于为了在 JavaScript 中更便捷的导入 JSON 模块,后续出于安全性考虑加上了import assertions
来作为导入不可执行模块的必须条件。
这一提案同样解决了模块类型与其 MIME 类型不符的情况。
个人感想:和现在如火如荼的 ESM、Bundleless 工具应该会有奇妙的化学反应。
Decorators (stage 2)
proposal-decorators[24]这一提案...,或许是我们最熟悉的老朋友了。但是此装饰器非彼装饰器,历时五年来装饰器提案已经走到了第三版,仍然卡在 stage 2。
这里引用我早前的一篇文章来简单讲述下装饰器的历史:
首先我们需要知道,JS 与 TS 中的装饰器不是一回事,JS 中的装饰器目前依然停留在 stage 2[25] 阶段,并且目前版本的草案与 TS 中的实现差异相当之大(TS 是基于第一版,JS 目前已经第三版了),所以二者最终的装饰器实现必然有非常大的差异。
其次,装饰器不是 TS 所提供的特性(如类型、接口),而是 TS 实现的 ECMAScript 提案(就像类的私有成员一样)。TS 实际上只会对stage-3以上的语言提供支持,比如 TS3.7.5 引入了可选链(Optional chaining[26])与空值合并(Nullish-Coalescing[27])。而当 TS 引入装饰器时(大约在 15 年左右),JS 中的装饰器依然处于stage-1 阶段。其原因是 TS 与 Angular 团队 PY 成功了,Ng 团队不再维护 [AtScript](<https://linbudu.top/posts/2020/08/10/atscript-playground[28]>),而 TS 引入了注解语法(Annotation)及相关特性。
但是并不需要担心,即使装饰器永远到达不了 stage-3/4 阶段,它也不会消失的。有相当多的框架都是装饰器的重度用户,如
Angular
、Nest
、Midway
等。对于装饰器的实现与编译结果会始终保留,就像JSX
一样。如果你对它的历史与发展方向有兴趣,可以读一读 是否应该在 production 里使用 typescript 的 decorator?[29](贺师俊贺老的回答)
个人感想:和类的私有成员、静态成员提案一样,目前使用最广泛的还是 TS 中的装饰器,但是二者的思路完全不同,因此我猜想原生装饰器的提案不会影响 TypeScript 的编译结果。
Iterator Helpers (stage 2)
proposal-iterator-helpers[30]提案为 ES 中的 Iterator 使用与消费引入了一批新的接口,虽然实际上,如 Lodash 与Itertools[31](思路来自于 Python3 中的itertools[32])这样的工具库已经提供了绝大部分能力,如 filter、filterMap 等。其他语言如 Rust、C#中也内置了非常强大的 Iterator Helpers,见Prior Art[33]。
示例:
function* naturals() {
let i = 0;
while (true) {
yield i;
i += 1;
}
}
const evens = naturals().filter((n) => n % 2 === 0);
for (const even of evens) {
console.log(even, "is an even number");
}
个人感想:虽然目前很少会直接操作 Generator 和 Iterator 了,但这些毕竟是语言底部的东西,了解使用与机制还是有好处的。我上一次接触 Iterator,还是为 Nx 编写插件时为其提供 Async Iterator 接口,但也是直接囫囵吞枣的使用rxjs-for-await[34]这个库。对这个提案的关注可能会相对少一些。
throw
Expressions (stage 2)
proposal-throw-expressions[35]这一提案主要提供了const x = throw new Error()
的能力,这并不是throw
语法的替代品,更像是面向表达式(Expression-Oriented)的补齐。
function getEncoder(encoding) {
const encoder =
encoding === "utf8"
? new UTF8Encoder()
: encoding === "utf16le"
? new UTF16Encoder(false)
: encoding === "utf16be"
? new UTF16Encoder(true)
: throw new Error("Unsupported encoding");
}
个人感想:错误处理又可以更自然美观一些了,奈斯!
Set Methods (stage 2)
proposal-set-methods[36]这一提案为 Set 新增了一批新的方法,如:
intersection
/union
/difference
:基于交集/并集/差集创建新的 SetisSubsetOf/isSupersetOf
:判断是否是子集/超集
个人感想:Set 的话用的比较少,但很明显这些方法会是一个不错的能力增强。
Upsert(Map.prototype.emplace) (stage 2)
proposal-upsert[37]这一提案为 Map 引入了 emplace 方法,在当前 Map 上的 key 已存在时,执行更新操作,否则执行创建操作。
个人感想:确实是很甜的语法糖,感觉底层框架、工具库用 Map 多一些。
Observable (stage 1)
proposal-observable[38]这一提案,其实懂的同学看到 Observable 已经懂这个提案是干啥的了,它引入了 RxJS 中的 Observable、Observer(同样是 next/error/complete/start)、Subscriber(next/error/complete)以及部分 Operators(RxJS:我直接好家伙),同样支持高阶 Observable,在被订阅时才会开始推送数据(Lazy-Data-Emitting)。
function listen(element, eventName) {
return new Observable((observer) => {
// Create an event handler which sends data to the sink
let handler = (event) => observer.next(event);
// Attach the event handler
element.addEventListener(eventName, handler, true);
// Return a cleanup function which will cancel the event stream
return () => {
// Detach the event handler from the element
element.removeEventListener(eventName, handler, true);
};
});
}
估计是因为还在 stage1 的关系,目前支持的操作符只有 of、from,但按照这个趋势下去 RxJS 中的大部分操作符都会被吸收过来。
个人感想:感觉需要非常久的时间才能看到未来结果,因为 RxJS 自身强大的多,海量操作符如果要吸收过来可能会是吃力不讨好的。同时,RxJS 的学习成本还是有的,我不认为大家会因为它被吸收到 JS 语言原生就会纷纷开始学习相关概念。
Promise.try (stage 1)
proposal-promise-try[39]提案引入了Promise.try
方法,这一方法其实很早就在bluebird[40]中提供了,其使用方式如下:
function getUserNameById(id) {
return Promise.try(function () {
if (typeof id !== "number") {
throw new Error("id must be a number");
}
return db.getUserById(id);
}).then((user) => {
return user.name;
});
}
Promise.try
方法返回一个 promise 实例,如果方法内部抛出了错误,则会走到.catch
方法。上面的例子如果正常来写,通常会这么写:
function getUserNameById(id) {
return db.getUserById(id).then(function (user) {
return user.name;
});
}
看起来好像没什么区别,但仔细想想,假设下面一个例子中,id 是错误的,
db.getUserById(id)
返回了空值,那么这样 user.name 无法获取,将会走.catch
,但如果不返回空值而是抛出一个同步错误?Promises 的错误捕获功能的工作原理是所有同步代码都位于.then 中,这样它就可以将其包装在一个巨大的try/catch
块中(所以同步错误都能走到.catch
中)。但是在这个例子中,db.getUserById(id)
并非位于.then
语句中,这就导致了这里的同步错误无法被捕获。简单的说,如果仅使用.then
,只有第一次异步操作后的同步错误会被捕获。
而是用Promise.try
,它将捕获db.getUserById(id)
中的同步错误(就像.then
一样,区别主要在 try 不需要前面跟着一个 promise 实例),这样子所有同步错误就都能被捕获了。
Do Expression (stage 1)
proposal-do-expressions[41]这个提案和throw
Expressions 一样,都是面向表达式(Expression-Oriented)的语法,函数式编程的重要优势之一。
看看示例代码:
let x = do {
let tmp = f();
tmp * tmp + 1;
};
let y = do {
if (foo()) {
f();
} else if (bar()) {
g();
} else {
h();
}
};
对于像我一样没接触过函数式编程的同学,这种语法可能确实很新奇有趣,而且对能帮助更好的组织代码。这一提案还存在着一些注意点:
在 do {}
中不能仅有声明语句,或者是缺少 else 的 if,以及循环。空白的 do {}
语句效果等同于void 0
。await
/yield
标识继承自上下文
对于异步版本的do expression
,存在一个尚未进入的提案proposal-async-do-expressions[42],旨在使用async do {}
的语法,如:
// at the top level of a script
(async do {
await readFile("in.txt");
let query = await ask("???");
// etc
});
Pipeline Operator (stage 1)
目前 star 最多的提案,似乎没有之一?
proposal-pipeline-operator[43]提案引入了新的操作符|>
,目前对于具体实现细节存在两个不同的竞争提案[44]。这一语法糖的主要目的是大大提升函数调用的可读性,如doubleNumber(number)
会变为number |> doubleNumber
的形式,对于链式的连续函数调用更是有奇效,如:
function doubleSay(str) {
return str + ", " + str;
}
function capitalize(str) {
return str[0].toUpperCase() + str.substring(1);
}
function exclaim(str) {
return str + "!";
}
在管道操作符下,变为如下形式:
let result = exclaim(capitalize(doubleSay("hello")));
result; //=> "Hello, hello!"
let result = "hello" |> doubleSay |> capitalize |> exclaim;
result; //=> "Hello, hello!"
确实大大提高了不少可读性对吧?你可能会想,上面都是单个入参,那多个呢,如下图示例:
function double(x) {
return x + x;
}
function add(x, y) {
return x + y;
}
function boundScore(min, max, score) {
return Math.max(min, Math.min(max, score));
}
let person = { score: 25 };
let newScore =
person.score
|> double
|> ((_) => add(7, _))
|> ((_) => boundScore(0, 100, _));
newScore; //=> 57
等同于
let newScore = boundScore(0, 100, add(7, double(person.score)));
_ 只是形参名称,你可以使用任意的形参名称。
Partial Application Syntax(stage 1)
proposal-partial-application[45]这一提案引入了新的柯里化(也属于柯里化吧,如果你看了下面的例子觉得不属于,请不要揍我)方式,即原本我们使用 bind 方法来预先固定一个函数的部分参数,得到一个高阶函数:
function add(x, y) {
return x + y;
}
const addOne = add.bind(null, 1);
addOne(2); // 3
const addTen = (x) => add(x, 10);
addTen(2); // 12
使用 Partial Application Syntax,写法会是这样的:
const addOne = add(1, ?);
addOne(2); // 3
const addTen = add(?, 10);
addTen(2); // 12
我们上一个列举的提案proposal-pipeline-operator[46],其实可以在 Partial Application Syntax 的帮助下变得更加便捷,尤其是在多参数情况下:
let person = { score: 25 };
let newScore = person.score |> double |> add(7, ?) |> boundScore(0, 100, ?);
目前的实现暂时不支持 await 关于更多细节,参考 Pipeline operator: Seeking champions[47] 以及 Pipeline operator draft[48]。
await.opts (stage 1)
proposal-await.ops[49]这一提案为 await 引入了await.all/race/allSettled/any
四个方法,来简化 Promise 的使用。实际上它们也正是Promise.all/race/allSettled/any
的替代者,如:
// before
await Promise.all(users.map(async x => fetchProfile(x.id)))
// after
await.all users.map(async x => fetchProfile(x.id))
Array Unique (stage 1)
proposal-array-unique[50]主要是为了解决数组去重的问题,我们以往使用的[...new Set(array)]
无法很好的处理非原始类型的值,这一提案引入了Array.prototype.uniqueBy()
方法来进行数组的去重,类似于Lodash.uniqBy[51]。
个人感想:新的面试题出现了,请实现Array.prototype.uniqueBy()
。2333,但是这个方法能原生支持还是很棒的。
JavaScript20 年-创立标准: https://cn.history.js.org/part-2.html
[2]ECMA(European Computer Manufacturers Association,欧洲计算机制造商协会): https://www.ecma-international.org/
[3]2020 年 6 月发布的第 11 版: https://www.ecma-international.org/publications-and-standards/standards/ecma-262/
[4]2015 年发布的 ES6: https://262.ecma-international.org/6.0/index.html
[5]TC39 的 ECMA262 官网: https://tc39.es/ecma262/
[6]ECMA-414: https://www.ecma-international.org/publications-and-standards/standards/ecma-414/
[7]ECMA-404: https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
[8]ECMA267: https://www.ecma-international.org/publications-and-standards/standards/ecma-267/
[9]The TC39 process for ECMAScript features: https://2ality.com/2015/11/tc39-process.html
[10]proposal-record-tuple: https://github.com/tc39/proposal-record-tuple
[11]proposal-relative-indexing-method: https://github.com/tc39/proposal-relative-indexing-method
[12]proposal-array-last: https://github.com/tc39/proposal-array-last
[13]proposal-array-find-from-last: https://github.com/tc39/proposal-array-find-from-last
[14]proposal-temporal: https://github.com/tc39/proposal-temporal
[15]ts39-proposal-temporal docs: https://tc39.es/proposal-temporal/docs/index.html
[16]private-methods: https://github.com/tc39/proposal-private-methods
[17]ES6 标准入门: https://es6.ruanyifeng.com/#docs/class#%E7%A7%81%E6%9C%89%E5%B1%9E%E6%80%A7%E7%9A%84%E6%8F%90%E6%A1%88
[18]proposal-class-fields: https://github.com/tc39/proposal-class-fields
[19]proposal-top-level-await: https://github.com/tc39/proposal-top-level-await
[20]proposal-import-assertions: https://github.com/tc39/proposal-import-assertions
[21]proposal-json-modules: https://github.com/tc39/proposal-json-modules
[22]proposal-error-cause: https://github.com/tc39/proposal-error-cause
[23]吞吞老师: https://github.com/legendecas
[24]proposal-decorators: https://github.com/tc39/proposal-decorators
[25]stage 2: https://github.com/tc39/proposal-decorators
[26]Optional chaining: https://github.com/tc39/proposal-optional-chaining
[27]Nullish-Coalescing: https://github.com/tc39/proposal-nullish-coalescing
[28]AtScript: https://github.com/angular/atscript-playground
[29]是否应该在 production 里使用 typescript 的 decorator?: https://www.zhihu.com/question/404724504
[30]proposal-iterator-helpers: https://github.com/tc39/proposal-iterator-helpers
[31]Itertools: https://www.npmjs.com/package/itertools
[32]itertools: https://docs.python.org/library/itertools.html
[33]Prior Art: https://github.com/tc39/proposal-iterator-helpers#prior-art
[34]rxjs-for-await: https://github.com/benlesh/rxjs-for-await
[35]proposal-throw-expressions: https://github.com/tc39/proposal-throw-expressions
[36]proposal-set-methods: https://github.com/tc39/proposal-set-methods
[37]proposal-upsert: https://github.com/tc39/proposal-upsert
[38]proposal-observable: https://github.com/tc39/proposal-observable
[39]proposal-promise-try: https://github.com/tc39/proposal-promise-try
[40]bluebird: http://bluebirdjs.com/docs/api/promise.try.html
[41]proposal-do-expressions: https://github.com/tc39/proposal-do-expressions
[42]proposal-async-do-expressions: https://github.com/tc39/proposal-async-do-expressions
[43]proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator
[44]两个不同的竞争提案: https://github.com/tc39/proposal-pipeline-operator/wiki
[45]proposal-partial-application: https://github.com/tc39/proposal-partial-application
[46]proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator
[47]Pipeline operator: Seeking champions: https://docs.google.com/presentation/d/1for4EIeuVpYUxnmwIwUuAmHhZAYOOVwlcKXAnZxhh4Q/edit#slide=id.g79e9b7164e_0_531
[48]Pipeline operator draft: https://tc39.es/proposal-pipeline-operator/
[49]proposal-await.ops: https://github.com/tc39/proposal-await.ops
[50]proposal-array-unique: https://github.com/tc39/proposal-array-unique
[51]...new Set(array)]无法很好的处理非原始类型的值,这一提案引入了
Array.prototype.uniqueBy()`方法来进行数组的去重,类似于[Lodash.uniqBy: https://www.lodashjs.com/docs/lodash.uniqBy
最后
如果你觉得这篇内容对你挺有启发,我想邀请你帮我三个小忙:
点个「在看」,让更多的人也能看到这篇内容(喜欢不点在看,都是耍流氓 -_-)
欢迎加我微信「 sherlocked_93 」拉你进技术群,长期交流学习...
关注公众号「前端下午茶」,持续为你推送精选好文,也可以加我为好友,随时聊骚。
![](https://filescdn.proginn.com/286e9997e6fb83258999535ff309ea50/69c82b7a95a894591ec1695c08bb15ff.webp)