问题标签 [javascript-decorators]

我看到 babel.js 装饰器（在“阶段 1”中可用）在https://github.com/wycats/javascript-decorators实现规范。装饰器似乎仅限于 (1) 类、(2) 访问器和 (3) 方法。就我而言，我想在普通的旧函数上使用装饰器，如

在哪里（只是一个例子）

我看不出装饰器不能应用于函数的任何合乎逻辑的原因。我的问题是，有没有办法做到这一点？或者有什么好的理由不能装饰函数？

事实证明，在https://github.com/wycats/javascript-decorators/issues/4上提出了一个问题。

我看到今天已经在一些 javascript 代码中使用了装饰器。我的问题实际上是两个方面。

第一的：

如果装饰器还没有最终确定，那么今天如何在生产代码中使用它们呢？浏览器支持会不存在吗？

第二：

鉴于今天可以使用它，正如一些开源项目所建议的那样，让装饰器工作的典型推荐设置是什么？

这个问题不是那些询问如何抑制由代码编辑器（如 VSCode）发出的类似警告的问题的重复。

我的问题是 Tsc 命令行编译器警告：

greet.ts:7:7 - 错误 TS1219：对装饰器的实验性支持是一个功能，在未来的版本中可能会发生变化。设置“experimentalDecorators”选项以删除此警告。

这是我的代码：

我在根目录中创建了以下 tsconfig.json：

但tsc还是抱怨。

我正在尝试在运行时动态创建 Typeorm 实体，然后在创建连接时将它们显式添加到连接中。我在弄清楚如何使用属性装饰器时遇到了一些麻烦。

作为控件，以声明方式创建实体可以正常工作：

然后类装饰器可以作为常规函数正常工作：

但PrimaryGeneratedColumn()用作常规功能：

给出：Entity "NewEntity" does not have a primary column. Primary column is required to have in all your entities. Use @PrimaryColumn decorator to add a primary column to your entity.何时创建 typeorm 连接。

我知道这是一个奇怪的用例！但如果有人知道如何做到这一点，将不胜感激！:)

我使用的是赛普拉斯 3.3.1 版。我收到以下错误：

错误：“TS1219：对装饰器的实验性支持是一项可能会在未来版本中更改的功能。设置“experimentalDecorators”选项以删除此警告。”

PS：我已经设置好"experimentalDecorators": true了tsconfig.json。尝试了以下但没有奏效：https ://github.com/cypress-io/eslint-plugin-dev/issues/4

报告错误的代码：

我正在使用 TypeScript 装饰器来定义我的无服务器 API 的 Swagger 文档。有没有办法在我的 API 参数的解构定义中使用装饰器？

我已经尝试了明显的解构路线，我只定义了我的解构元素，并将注释放在对象中它们之前。

以下工作正常。

但是，我实际上并没有像这样得到 pathParameters。我把它们放在一个事件对象中。

我想做这样的事情

事件类型如下所示

但是，上述内容在 TypeScript 中无法正确编译。

在整个处理程序方法中，我从 TypeScript 中得到了各种编译时错误，但实际方法参数本身的错误如下。

Property destructuring pattern expected. ts(1180)

任何人都可以帮助我使用装饰器@Model 和@Emit 吗？我正在尝试更改单击我的组件的顺序并从此处使用文档：https ://github.com/kaorun343/vue-property-decorator 。这是我的代码：

但是当我点击按钮时，变量“order”的值并没有改变。难道我做错了什么？

Vue从vue-property-decorator和导入有什么区别和用例vue？我的理解是，在使用装饰器定义自定义组件时，我需要始终导入Vue，但是在这样做时我应该注意与 ' 的核心相关的任何意外/不同的事情/场景吗？vue-property-decorator@ComponentVue

我必须在此实现中实现箭头函数，并且我需要将来自 AWS 的输入转换为自定义模型，以避免对每个 API 执行相同的逻辑。我想过使用装饰器来完成每个功能。由于编译器将其视为属性，因此它不会找到描述符属性并引发异常。是否有一种解决方法可以欺骗编译器将箭头函数识别为实际函数并传递描述符？

我们正在 Nestjs 中构建高负载后端 api。

我正在为休息请求验证寻找好的解决方案。我们对国际化有一些特定的要求，所以我们决定不使用标准的基于模式的验证管道，因为它不能很好地处理国际化。

我正在考虑为每个请求 DTO 自定义 Mapper 类。所以它获取请求数据并将它们转换为特定的 DTO： class CreateAccountRequestMapper { map(data: any): CreateAccountRequestDto {} } 如果输入无效，它将抛出一些特定于 API 的异常。

在性能方面将其实现到装饰器+管道中是个好主意吗？我不太了解这个概念，但在我看来，我需要对每个请求进行不必要的对象实例化，而如果我直接在处理程序中使用映射器，我会避免它。

装饰器通常意味着显着的开销吗？