ECMAScript装饰器

2024-01-28  本文已影响0人  涅槃快乐是金

在2015年，ECMAScript 6被推出，这是JavaScript语言的一次重要发布。此次发布引入了许多新特性，如const/let、箭头函数、类等。这些特性大多旨在消除JavaScript的差异之处。因此，所有这些特性都被标记为“Harmony”。一些来源称整个ECMAScript 6为“ECMAScript Harmony”。除了这些特性外，“Harmony”标签还突出了其他预计很快成为规范一部分的特性。装饰器就是其中一种期望的特性。

距离第一次提到装饰器已经过去将近10年的时间。装饰器的规范已经被多次几乎从零开始重写，但它们尚未成为规范的一部分。随着JavaScript早已超越了仅仅用于基于浏览器的应用程序，规范的制定者必须考虑JavaScript可以在许多平台上执行的广泛范围。这正是为什么这个提案进入第3阶段花费了这么长时间的原因。

全新的东西？

首先，让我们澄清在编程世界中装饰器是什么。

“装饰器是一种结构型设计模式，它允许你通过将对象放入包含行为的特殊包装对象中，来为对象附加新的行为。” © https://refactoring.guru/design-patterns/decorator

这里的关键点是装饰器是一种设计模式。这意味着通常它可以在任何编程语言中实现。如果你对JavaScript有基本的了解，很有可能你已经在不自觉中使用过这种模式。

听起来有趣吗？那么试着猜猜世界上最受欢迎的装饰器是什么... 让我们见识一下世界上最著名的装饰器，高阶函数——防抖函数。

防抖函数

在深入研究防抖函数的细节之前，让我们回顾一下什么是高阶函数。高阶函数是那些接受一个或多个函数作为参数或将函数作为它们的结果返回的函数。防抖函数是高阶函数的一个显著示例，同时也是JavaScript开发者最常用的装饰器。

高阶函数debounce延迟调用另一个函数，直到自上次调用以来经过了一定的时间，而不改变它的行为。最常见的用例是在用户输入搜索栏的值时，防止发送多个请求到服务器，例如加载自动完成建议。相反，它会等到用户完成或暂停输入，然后才将请求发送到服务器。

在大多数学习JavaScript语言的资源中，在关于超时的部分，你会找到涉及编写这个函数的练习。最简单的实现看起来像这样：

const debounce = (fn, delay) => {
  let lastTimeout = null

  return (...args) => {
    clearInterval(lastTimeout)

    lastTimeout = setTimeout(() => fn.call(null, ...args), delay)
  }
}

使用这个函数可能如下所示：

class SearchForm {
  constructor() {
    this.handleUserInput = debounce(this.handleUserInput, 300)
  }

  handleUserInput(evt) {
    console.log(evt.target.value)
  }
}

当使用下一节中将讨论的装饰器的特殊语法时，相同行为的实现将如下所示：

class SearchForm {
  @debounce(300)
  handleUserInput(evt) {
    console.log(evt.target.value)
  }
}

所有的样板代码都消失了，只留下了必要的部分。看起来很简洁，是吧？

Higher-Order Component (HOC)

下一个例子将来自React世界。尽管在使用React构建的应用程序中，高阶组件（HOC）的使用越来越不常见，但HOC仍然是装饰器使用的一个良好而且广为人知的例子。

让我们看一个名为withModal的HOC的例子：

const withModal = (Component) => {
  return (props) => {
    const [isOpen, setIsOpen] = useState(false)

    const handleModalVisibilityToggle = () => setIsOpen(!isOpen)

    return (
      <Component
        {...props}
        isOpen={isOpen}
        onModalVisibilityToggle={handleModalVisibilityToggle}
      />
    )
  }
}

现在，让我们看看它的用法:

const AuthPopup = ({ onModalVisibilityToggle }) => {
  // Component
}

const WrappedAuthPopup = withModal(AuthPopup)

export { WrappedAuthPopup as AuthPopup }

下面是使用装饰器语法的HOC的样子:

@withModal()
const AuthPopup = ({ onModalVisibilityToggle }) => {
  // Component
}

export { AuthPopup }

重要说明：函数装饰器不是当前提案的一部分。然而，它们在未来发展装饰器规范时可能被考虑。

再一次，所有的样板代码都消失了，只留下了真正重要的部分。

也许有些读者在这个例子中没有看到任何特殊之处。在上面的例子中，只使用了一个装饰器。让我们看一个这样的例子：

const AuthPopup = ({
  onSubmit,
  onFocusTrapInit,
  onModalVisibilityToggle,
}) => {
  // Component
}

const WrappedAuthPopup = withForm(
  withFocusTrap(
    withModal(AuthPopup)
  ), {
  mode: 'submit',
})

export { WrappedAuthPopup as AuthPopup }

看到那些难以阅读的嵌套了吗？你花了多少时间理解代码中发生了什么？现在，让我们看一下相同的例子，但使用装饰器语法：

@withForm({ mode: 'submit' })
@withFocusTrap()  
@withModal()
const AuthPopup = ({
  onSubmit,
  onFocusTrapInit,
  onModalVisibilityToggle,
}) => {
  // Component
}

export { AuthPopup }

您是否不同意纵向展开的代码比前面带有嵌套函数调用的例子更易读？

高阶函数 debounce和高阶组件 withModal只是日常生活中应用装饰器模式的几个例子。这个模式可以在我们经常使用的许多框架和库中找到，尽管我们许多人可能经常不注意到它。尝试分析你正在工作的项目，看看装饰器模式被应用的地方。你可能会发现不止一个这样的例子。

JavaScript实现

在我们深入探讨装饰器提案及其实现之前，我希望我们先看一下这张图片：


通过这张图片，我想提醒你JavaScript语言最初创建的主要目的。我不是那些喜欢抱怨的人，说：“哦，JavaScript只适合用于突出显示表单字段。

JavaScript的主要关注点是我们为其编写代码的最终用户。这是一个关键的理解点，因为每当在JavaScript语言中引入新的东西，比如具有与其他编程语言不同的实现的类，同样的抱怨者就会出现，并开始哀叹事情没有以用户友好的方式完成。相反，在JavaScript中，一切都是以最终用户为目标设计的，这是没有其他编程语言可以吹嘘的地方。

如今，JavaScript不仅仅是一种浏览器语言。它可以在各种环境中运行，包括在服务器上。负责向语言引入新特性的TC39委员会面临着满足所有平台、框架和库需求的艰巨任务。然而，主要关注点仍然是浏览器中的最终用户。

装饰器的历史

为了更深入地了解这一提案的历史，让我们回顾一下关键事件的列表。

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被多次从头开始重写的一个重要原因。

这为TC39委员会带来了额外的挑战，因为他们不得不考虑开发者社区的期望和要求，以及语言引擎中的优化问题。

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[]
}

在stage2结束时，装饰器API如下所示:

ype 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)
    }
  }
}

整个第2阶段历时6年，在此期间，装饰器API经历了重大变化。然而，正如我们从上面的代码中看到的，对于类的修改被排除在外。这使得提案对JS引擎以及各种平台、框架和库更加可接受。但是，装饰器的发展历史还没有结束。

”在MobX中，使用装饰器已不再是常规。这对你们中的一些人来说是个好消息，但其他人会讨厌它。这是有道理的，因为我认为装饰器的声明性语法仍然是最好的。当MobX开始时，它是一个只有TypeScript的项目，所以装饰器是可用的。虽然还是实验性的，但显然它们将很快被标准化。至少那是我的期望（之前我主要做Java和C#）。然而，那个时刻仍然没有到来，两个装饰器提案在此期间已经取消。尽管它们仍然可以被转译。”
© Michel Weststrate，MobX的作者

“虽然装饰器已经达到了第3阶段，但我们在规范中看到了一些需要与冠军们讨论的行为。在解决这个问题并审查变更之间，我们预计装饰器将在下一个版本中实现。”

总的来说，这个决定是有道理的，因为他们不想冒在TS中过早地引入一个特性的风险，尤其是如果它没有成为标准的一部分。这种情况总是有可能发生的。尽管在这种情况下，可能不像第一个实现那样重要。

在TS 4.9中，只包含了装饰器规范的一小部分——类自动访问器。这个对装饰器规范的补充作为对在实现的早期阶段盛行的变异的修正。这背后的原因是通常有一种希望使属性具有响应性的愿望，这意味着在属性更改时应该发生一些效果，比如UI重新渲染，例如：

class Dashboard extends HTMLElement {
  @reactive
  tab = DashboardTab.USERS
}

在旧的实现中，使用响应式装饰器，你必须通过向目标类添加额外的set和get访问器来实现期望的行为。使用自动访问器，这种行为现在变得更加明确，从而允许引擎更好地优化它。

class Dashboard extends HTMLElement {
  @reactive
  accessor tab = DashboardTab.USERS
}

另一件有趣的事情是装饰器应该如何工作。由于TS团队无法删除在--experimentalDecorators标志下工作的旧实现，他们采取了以下方法：如果配置中存在--experimentalDecorators标志，则使用旧实现。如果不存在这个标志，那么将使用新的实现。

“请注意，ES装饰器尚未受支持，但我们将努力在未来的版本中默认启用它们。”

”我认为在元数据支持和参数装饰器实现之前，我们不会支持JS装饰器。”
© Kamil Mysliwiec，NextJS的创建者

只是语法糖吗？

在所有的解释和示例之后，你可能会有一个问题：“那么，JavaScript中的装饰器只是具有特殊语法的高阶函数，就这样了吗？”

事情并不是那么简单。除了之前提到的关于JavaScript主要关注最终用户的内容，还值得补充的是JS引擎总是尝试使用新的语法作为参考点，至少试图使你的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引擎，它们都以不同的方式执行优化。然而，如果通过使用原生语法来协助引擎，你的应用代码在大多数情况下通常会运行得更快。

可能的扩展

规范中的新语法也为将来引入其他功能打开了大门。类比一下构造函数和类。当私有字段被引入规范时，它们是作为类的一个特性引入的。对于那些坚决否认类有用性，声称构造函数是等效的人来说，私有字段成为摆脱构造函数而选择类的另一个理由。这些功能很可能会不断发展。

尽管我们目前在许多情况下可以通过使用高阶函数实现许多与装饰器相同的效果，但它们仍然无法涵盖未来将添加到装饰器规范的所有潜在功能。

装饰器规范存储库中的“possible extensions”文件提供了关于装饰器规范可能如何在未来发展的见解。一些点在最初的阶段中列出，但在当前标准中不存在，比如参数装饰器。然而，还提到了一些全新的概念，如const/let装饰器或块装饰器。这些潜在的扩展展示了JavaScript中装饰器功能的持续发展和扩展。

事实上，有许多提案和扩展正在考虑，以进一步完善装饰器规范。其中一些提案，如装饰器元数据，已经在核心装饰器规范尚未标准化的情况下被考虑。这强调了装饰器在规范中有着光明前景的想法，我们可以期望在不久的将来看到它们成为标准的一部分。

结论

在10多年的时间里对装饰器提案的深入考虑确实可能看起来是一个很长的时间。的确，早期由主要框架和库采用装饰器的情况有助于揭示初始实现的缺陷。然而，这种早期采用也成为了宝贵的学习经验，突显了与Web平台协调以及开发与平台和开发者社区一致的解决方案的重要性，同时保留了装饰器的本质。对提案进行细化的时间最终有助于使其成为JavaScript语言中更强大和经过深思熟虑的补充。

的确，装饰器将会对我们今天编写应用程序的方式产生重大变化。也许不会立即，因为当前的规范主要关注类，但随着所有这些新增和正在进行的工作，许多应用程序中的JavaScript代码将很快看起来不同。我们现在比以往任何时候都更接近最终看到规范中真正的装饰器的时刻。这是一个令人兴奋的发展，有望提高JavaScript应用程序的表达力和功能。

原文：https://dev.to/what1s1ove/ecmascript-decorators-the-ones-that-are-real-g96

上一篇下一篇

猜你喜欢

热点阅读