本文作者为 360 奇舞团前端开发工程师
在2015 年，ECMAScript 6 问世，这是 JavaScript 语言的一个重要版本。该版本引入了许多新特性，如 const/let、箭头函数、类等。这些功能大多旨在消除 JavaScript 的怪异之处。因此，所有这些特性都被贴上了 "Harmony "的标签。一些资料称整个 ECMAScript 6 被称为 "ECMAScript Harmony"。除了这些特性外，"Harmony"标签还强调了其他有望成为规范一部分的特性。装饰器（Decorators）就是这些特性中的一个。
自首次提及装饰器以来已经过去了近 10 年。装饰器的规范几乎从头开始重写了好几次，但它还没有成为规范的一部分。由于 JavaScript 早已不是仅仅局限于基于浏览器的应用程序，规范的制定者必须考虑到可以执行 JavaScript 的各种平台上javascript上执行的情况。这正是为什么这个提案进展到第3阶段花费了这么长时间的原因。
全新的东西？
首先，让我们弄清楚什么是程序设计中的装饰器。
"装饰器是一种结构设计模式，通过将对象置于包含行为的特殊包装器对象中，可以将新的行为附加到对象上"。 © refactoring.guru/design-patt...
这里的关键点在于装饰器是一种设计模式。这意味着它通常可以在任何编程语言中实现。如果你对 JavaScript 有基本的了解，那么你很可能已经在不知不觉中使用了这种模式。
听起来有趣吗？那就猜猜世界上最流行的装饰器是什么吧... 认识一下世界上最有名的装饰器--高阶函数 debounce。
防抖
在深入了解去抖函数的细节之前，我们先来了解一下什么是高阶函数。高阶函数是将一个或多个函数作为参数或将一个函数作为结果返回的函数。去抖函数是高阶函数的一个显著例子，同时也是 JS 开发人员最受欢迎的装饰器。
高阶函数 debounce 会延迟调用另一个函数，直到距离上次调用已过去一定时间，但不会改变其行为。最常见的用例是当用户在搜索栏中输入值时，防止向服务器发送多个请求，例如加载自动完成建议。相反，它会等到用户完成或暂停输入后，才向服务器发送请求。
在大多数 JavaScript 语言学习资源的延时部分，你都能找到涉及编写此函数的练习。最简单的实现如下：
javascript
const debounce = (fn, delay) => {
let lastTimeout = null
return (...args) => {
clearInterval(lastTimeout)
lastTimeout = setTimeout(() => fn.call(null, ...args), delay)
}
}该功能的使用方法如下：
javascript
class SearchForm {
constructor() {
this.handleUserInput = debounce(this.handleUserInput, 300)
}
handleUserInput(evt) {
console.log(evt.target.value)
}
}如果使用装饰器的特殊语法（我们将在下一节讨论），相同行为的实现看起来会是这样的：
typescript
class SearchForm {
@debounce(300)
handleUserInput(evt) {
console.log(evt.target.value)
}
}所有繁琐的代码都消失了，只留下了必要的部分。看起来很简洁，不是吗？
高阶组件HOC
下一个例子将来自React世界。尽管在使用React构建的应用程序中，高阶组件（HOC）的使用变得越来越少，但HOC仍然是装饰器使用的一个很好且出名的例子。
让我们看一个名为withModal的HOC的例子：
javascript
const withModal = (Component) => {
return (props) => {
const [isOpen, setIsOpen] = useState(false)
const handleModalVisibilityToggle = () => setIsOpen(!isOpen)
return (
<Component
{...props}
isOpen={isOpen}
onModalVisibilityToggle={handleModalVisibilityToggle}
/>
)
}
}现在，让我们来看看如何使用它：
javascript
const AuthPopup = ({ onModalVisibilityToggle }) => {
// Component
}
const WrappedAuthPopup = withModal(AuthPopup)
export { WrappedAuthPopup as AuthPopup }下面是使用特殊装饰器语法的 HOC 的样子：
typescript
@withModal()
const AuthPopup = ({ onModalVisibilityToggle }) => {
// Component
}
export { AuthPopup }重要提示：函数装饰器不是当前提案的一部分。不过，它们已被列入未来开发装饰器规范时可考虑的事项列表中。
所有的模板代码再次消失，只留下真正重要的内容。
也许有些读者并不觉得这有什么特别之处。在上面的示例中，只使用了一个装饰器。让我们来看看这样一个例子：
javascript
const AuthPopup = ({
onSubmit,
onFocusTrapInit,
onModalVisibilityToggle,
}) => {
// Component
}
const WrappedAuthPopup = withForm(
withFocusTrap(
withModal(AuthPopup)
), {
mode: 'submit',
})
export { WrappedAuthPopup as AuthPopup }看到那些难以阅读的嵌套了吗？你花了多少时间才弄明白代码中发生了什么？现在，让我们看看使用装饰器语法的相同示例：
less
@withForm({ mode: 'submit' })
@withFocusTrap()
@withModal()
const AuthPopup = ({
onSubmit,
onFocusTrapInit,
onModalVisibilityToggle,
}) => {
// Component
}
export { AuthPopup }你是否不同意，从上到下的代码比之前嵌套函数调用的例子更易读？
高阶函数 debounce 和高阶组件 withModal 只是装饰器模式在日常生活中应用的几个例子。这种模式可以在我们经常使用的许多框架和库中找到，尽管我们中的许多人可能经常没有注意到它。试着分析一下你正在进行的项目，寻找应用装饰器模式的地方。你很可能会发现不止一个这样的例子。
javaScript实现
在深入探讨装饰器提案本身及其实现之前，我想让你们先看看这张图片：
通过这张图片，我想提醒你注意 JavaScript 语言最初创建的主要目的。我不是那种喜欢抱怨说："哦，JavaScript 只适合突出显示表单字段 "的人。通常，我把这种人称为 "恐龙"。
JavaScript 主要关注的是我们编写代码的最终用户。这一点非常重要，因为每当 JavaScript 语言中引入新的东西，比如类的实现方式与其他编程语言不同时，就会有同样的抱怨者来抱怨，说这样做对用户不友好。恰恰相反，JavaScript 的一切设计都以最终用户为中心，这是其他编程语言无法比拟的。
JavaScript的主要关注点是我们为其编写代码的最终用户。这是一个关键的理解点，因为每当 JavaScript 语言中引入新的东西，比如类的实现方式与其他编程语言不同时，就会有同样的抱怨者来抱怨，说这样做对用户不友好。恰恰相反，JavaScript 的一切设计都以最终用户为中心，这是其他编程语言无法比拟的。
今天，JavaScript 不仅仅是一种浏览器语言。它可以在包括服务器在内的各种环境中运行。负责为该语言引入新功能的 TC39 委员会面临着满足所有平台、框架和库需求的艰巨任务。不过，主要关注点仍然是浏览器中的终端用户。
装饰器的历史
为了更深入地了解这一提议的历史，让我们回顾一下关键事件列表。
- 2014-04 - 第 0 阶段：装饰器由 Yehuda Katz 提出，最初打算成为 ECMAScript 7 的一部分。
typescript
type Decorator = (
target: DecoratedClass,
propertyKey: string,
descriptor: PropertyDescriptor
) => PropertyDescriptor | void
function debounce(delay: number): PropertyDescriptor {
return (target, propertyKey, descriptor) => {
let lastTimeout: number
const method = descriptor.value
descriptor.value = (...args: unknown[]) => {
clearInterval(lastTimeout)
lastTimeout = setTimeout(() => method.call(null, ...args), delay)
}
return descriptor
}
}在这一阶段，您就可以看到装饰器 API 后来发生如此重大变化的原因之一。装饰器的第一个参数是整个类，即使您只装饰了其中的一个成员。此外，我们还假设开发人员可以更改这个类。JavaScript 引擎总是尽可能地进行优化，在这种情况下，开发人员对整个类进行改变的调用破坏了引擎提供的大量优化。稍后我们将看到，我们将看到这确实是装饰器API被多次从头重写的主要原因之一。
- 2015-03 - 第 1 阶段。在没有重大改动的情况下，该提案进入了第 2 阶段。然而，一个事件的发生对该提案的进一步发展产生了重大影响： TypeScript 1.5 发布，支持装饰器。尽管装饰器被标记为实验性（--experimentalDecorators），Angular 和 MobX 等项目开始积极地使用它们。此外，这些项目的整体工作流程也假定只使用装饰器。由于这些项目的流行，许多开发人员误以为装饰器已经是 JS 官方标准的一部分。这给 TC39 委员会带来了额外的挑战，因为他们必须考虑开发者社区的期望和要求以及语言引擎的优化问题。
- 2016-07 - 第 2 阶段。装饰器提案进入第 2 阶段后，其 API 开始发生重大变化。此外，该提案一度被称为 "JavaScript 的 ESnext 类特性"。在开发过程中，关于如何构建装饰器的想法层出不穷。要全面了解整个修改历史，我建议您查看该提案资源库中的提交。以下是装饰器 API 曾经的示例：
typescript
type Decorator = (args: {
kind: 'method' | 'property' | 'field',
key: string | symbol,
isStatic: boolean,
descriptor: PropertyDescriptor
}) => {
kind: 'method' | 'property' | 'field',
key: string | symbol,
isStatic: boolean,
descriptor: PropertyDescriptor,
extras: unknown[]
}在第二阶段结束时，装饰程序应用程序接口如下所示：
typescript
type Decorator = (
value: DecoratedValue,
context: {
kind: 'class' | 'method' | 'getter' | 'setter' | 'field' | 'accessor',
name: string | symbol,
access?: {
get?: () => unknown,
set?: (value: unknown) => void
},
private?: boolean,
static?: boolean,
addInitializer?: (initializer: () => void) => void
}
) => UpdatedDecoratedValue | void
function debounce(delay: number): UpdatedDecoratedValue {
return (value, context) => {
let lastTimeout = null
return (...args) => {
clearInterval(lastTimeout)
lastTimeout = setTimeout(() => value.call(null, ...args), delay)
}
}
}整个第二阶段耗时 6 年，期间装饰程序接口经历了重大变化。不过，从上面的代码中我们可以看到，突变被排除在外。这使得该提案更容易为 JS 引擎以及各种平台、框架和库所接受。但是，装饰器的发展历史还没有结束。
- 2020年9月，MobX 6版本宣布，告别装饰器。一些完全依赖于装饰器的库开始放弃它们的旧实现，因为它们意识到它们与装饰器的工作方式将不再被标准化。"在 MobX 中，使用装饰器已不再是常态。对于一些人来说，这是个好消息，但其他人可能会讨厌它。这是正常的，因为我认为装饰器的声明性语法仍然是最好的选择。当 MobX 开始时，它是一个 TypeScript 专用的项目，因此装饰器是可用的。虽然还是实验性的，但显然它们将很快被标准化。至少这是我的期望（之前我主要做 Java 和 C#）。然而，这一刻仍然没有到来，与此同时，两个装饰器提案已经被取消。尽管它们仍然可以被转译。" ------ Michel Weststrate，MobX 作者
- 2022-03 - 第三阶段。经过多年的修改和完善，装饰公司终于进入了第三阶段。得益于第二阶段的广泛调整和完善，第三阶段开始时并没有重大变化。一个特别的亮点是创建了一个名为 "装饰器元数据 "的新提案。
- 2022-08 - SpiderMonkey 新闻简报。SpiderMonkey 是 Firefox 使用的浏览器引擎，它是第一个开始实现装饰器的引擎。像这样的实现表明，该提案已基本准备就绪，可以成为规范的正式组成部分。
- 2022年9月 - Babel 7.19.0 第3阶段的装饰器。在编译器中添加对一个提案的支持是任何提案的一个非常重要的更新。大多数提案在其标准化计划中都有类似的项目，而装饰器提案也不例外。
- 2022年11月 - 宣布 TypeScript 4.9。ECMAScript装饰器被列入TS 4.9迭代计划。然而，过了一段时间，TS团队决定将装饰器移到5.0版本。以下是作者的评论：
"尽管装饰器已经达到第3阶段，但我们在规范中发现了一些需要与倡导者讨论的行为。在解决这个问题并审查更改之间，我们预计装饰器将在下一个版本中实现。"
总体上，这个决定是有道理的，因为他们不想冒在TS中过早引入一个特性的风险，特别是如果它没有成为标准的一部分。总会有这样的情况发生的可能性。尽管在这种情况下，可能并不像第一次实现那么重要。
在TS 4.9中，只有装饰器规范的一小部分被包含在内 - 类自动访问器。装饰器规范的这一补充是对实施的初期普遍存在的突变的一种纠正。其背后的原因是通常希望使属性具有响应性，这意味着在属性更改时应该发生一些效果，比如UI重新渲染，例如：
- 2022-11 - 发布 TypeScript 4.9。ECMAScript 装饰器已列入 TS 4.9 迭代计划。然而，经过一段时间后，TS 团队决定将装饰器移至 5.0 版本。以下是作者的评论：
"虽然装饰器已进入第 3 阶段，但我们在规范中发现了一些需要与倡导者讨论的行为。在解决这些问题和审查修改的过程中，我们预计装饰器将在下一个版本中实施"。
总的来说，这一决定是合理的，因为他们不想冒过早将功能纳入 TS 的风险，尤其是如果该功能没有成为标准的一部分。这种情况总是有可能发生的。尽管在这种情况下，它可能不会像第一次实施那样重要。
在 TS 4.9 中，只包含了装饰器规范的一小部分--类自动访问器。对装饰器规范的这一补充是对实施初期普遍存在的突变的一种修正。这背后的原因是，人们往往希望使属性具有反应性，也就是说，当属性发生变化时，会产生一些效果，例如用户界面的重新渲染：
java
class Dashboard extends HTMLElement {
@reactive
tab = DashboardTab.USERS
}- 在使用反应式装饰器的旧实现中，您必须通过添加额外的 set 和 get 访问器来更改目标类，以实现所需的行为。使用自动访问器后，这种行为现在可以更明确地发生，这反过来又允许引擎对其进行更好的优化。
java
class Dashboard extends HTMLElement {
@reactive
accessor tab = DashboardTab.USERS
}另一个有趣的问题是装饰器应该如何工作。由于 TS 团队无法删除在 --experimentalDecorators 标记下工作的旧实现，因此他们决定采用以下方法：如果配置中存在 --experimentalDecorators 标记，则将使用旧实现。如果配置中没有该标记，则使用新的实现。
- 2023-03 - 发布 TypeScript 5.0。按照承诺，TS 团队在 TS 5.0 中发布了完整版的装饰器规范。
- 2023-03 - Deno 1.32。尽管 1.32 版 Deno 支持 TS 5.0，但他们决定推迟与装饰器相关的功能。
"请注意，目前还不支持 ES 装饰器，但我们将努力在未来的版本中默认启用它们"。
- 2023-05 - Angular v16 来了。Angular 16 还增加了对 ECMAScript 装饰器的支持。不过，其他一些围绕装饰器构建的框架（它们受到 Angular 的启发？对其中许多人来说，元数据和参数装饰器是两个重要方面。
"我认为在元数据支持和参数装饰器实现之前，我们不会支持 JS 装饰器。 ©卡米尔-米斯利维奇，NextJS 的创建者
- 2023-08 - 发布 TypeScript 5.2。在 TS 5.2 中，添加了另一个补充装饰器规范的标准--装饰器元数据（Decorator Metadata）。这一提议的主要目的是简化装饰器对使用它们的类元数据的访问。关于语法和用法的争论如此之多的另一个原因是，作者不得不为此创建一个完整的单独提案。
只是语法糖还是糖？
在听完所有的解释和示例之后，你可能会有一个疑问： "那么，JavaScript 中的装饰器是否只是具有特殊语法的高阶函数，仅此而已？
事实并非如此简单。除了前面提到的 JavaScript 如何以最终用户为中心之外，还值得补充的一点是，JS 引擎总是试图使用新语法作为参考点，至少尝试让 JavaScript 更快。
javascript
import { groupBy } from 'npm:lodash@4.17.21'
const getGroupedOffersByCity = (offers) => {
return groupBy(offers, (it) => it.city.name)
}
// OR ?
const getGroupedOffersByCity = (offers) => {
return Object.groupBy(offers, (it) => it.city.name)
}这看起来似乎没有什么区别，但对引擎来说是有区别的。只有在第二种情况下，即使用本地函数时，引擎才能尝试进行优化。
要描述 JavaScript 引擎中的优化工作原理，需要单独撰写一篇文章。要更好地理解这一主题，请不要犹豫，探索浏览器源代码或搜索相关文章。
同样重要的是要记住，JavaScript 引擎有很多，它们执行优化的方式也不尽相同。不过，如果您使用本地语法来辅助引擎，在大多数情况下，您的应用程序代码通常会运行得更快。
可能的扩展
规范中的新语法也为未来的其他功能打开了大门。打个比方，请看构造函数和类。在规范中引入私有字段时，它们是作为类的一项功能引入的。对于那些坚决否认类的有用性并声称构造函数等同于类的人来说，私有字段成了他们放弃构造函数而选择类的另一个理由。这类特性很可能会持续演进。
虽然目前我们目前在很多情况下使用高阶函数实现很多与装饰器相同的效果，但它们仍然没有涵盖将来会添加到装饰器规范中的所有潜在功能。
装饰器规范存储库中的 "可能的扩展 "文件提供了装饰器规范未来可能如何发展的见解。其中一些要点已在第一阶段列出，但在当前标准中并不存在，例如参数装饰器。不过，也有一些全新的概念被提及，如 const/let 装饰器或块装饰器。这些潜在的扩展说明了 JavaScript 中装饰器功能的不断发展和扩展。
事实上，为了进一步增强装饰器规范，我们正在考虑许多建议和扩展。尽管核心装饰器规范尚未标准化，但其中一些建议（如装饰器元数据）已在考虑之中。这说明装饰器在规范中大有可为，我们有望在不久的将来看到装饰器成为标准的一部分。
结语
对于装饰器提案长达10年的深入考虑，的确可能看起来是一个漫长的时期。早期采用装饰器的领先框架和库揭示了初始实现的缺陷，这是事实。然而，这一早期采用也作为一次宝贵的学习经验，突显了与 web 平台协调和开发一种既符合平台和开发者社区，同时保留装饰器本质的解决方案的重要性。对提案进行改进的时间最终有助于使其成为 JavaScript 语言更为健壮和经过深思熟虑的重要补充。
事实上，装饰器将为我们今天编写应用程序的方式带来重大改变。也许不会立即改变，因为当前的规范主要关注类，但随着所有新增内容和正在进行的工作，许多应用程序中的 JavaScript 代码很快将呈现出不同的面貌。我们现在比以往任何时候都更接近终于能看到那些真正的装饰器出现在规范中的时刻。这是一个令人兴奋的发展，有望增强 JavaScript 应用程序的表现力和功能。