Typescript: 데코레이터

사양에 대해 제가 이해한 바에 따르면 실례합니다. 우리는 다음을 수행할 수 없습니다.

<strong i="6">@F</strong>
function test() {
}

내 말이 맞아?

유형 직렬화는 나머지 인수와 어떻게 작동합니까?

@F()  
class Foo {  
    constructor(...args: string[]) {  
    }  
}  

function F(<strong i="6">@paramterTypes</strong> types?: Function[]) {  
    return function (target) {  
        target.paramterTypes = types; // ???  
    }  
}

데코레이터를 사용하는 것은 충분히 간단해 보이지만, 데코레이터를 선언하는 섹션이 혼란스럽다는 것을 알았습니다. C.4에서는 데코레이터에 @decorator 주석을 달아야 한다고 하지만 실제로 이러한 일이 일어나는 것을 보여주는 예제는 단 하나도 없습니다.

데코레이터 팩토리는 B에 있는 인터페이스를 구현하는 클래스를 위한 것입니까?

CoverMemberExpressionSquareBracketsAndComputedPropertyName의 해석을 구체화하는 규칙은 무엇입니까?

나는 많은 타이핑이 다양한 지점에서 Function | Object 를 가지고 있다는 것을 알아차렸지만, 이것들은 타입 체크 시간에 Object로 변질될 것입니다. 거기에 Function이 있는 이유는 무엇입니까?

나는 DecoratorFunction 대 ​​DecoratorFactory라는 용어에 대해 미쳤지 않습니다. 저는 Generator와 GeneratorFunction이 있는 제너레이터의 명명법을 따르고 싶습니다. 이 체계를 사용하여 DecoratorFunction의 이름을 Decorator로, DecoratorFactory를 DecoratorFunction으로 이름을 변경합니다.

장식 수출의 경우 [lookahead ≠ @] 는 무엇입니까? HoistableDeclaration 및 ClassDeclaration이 실제로 @ 시작할 수 있습니까?

이것은 #1557의 중복입니다.

#1557이 다른 디자인을 위한 것이므로 실제로 속임수가 아닙니다. 이 문제는 현재 구현되고 있는 데코레이터 디자인에 대한 것입니다.

내 실수.

함수 표현의 데코레이터의 경우 다음과 같이 할 수 없습니다.

@F("color") <strong i="6">@G</strong> 
function myFunc() {
   doSomething();
}

변환:

var _t = function() {
   doSomething();
}
_t = F("color")(_t = G(_t) || _t) || _t;  

function myFunc() {
  return _t.apply(this, arguments)
}

다음과 같은 모든 기능을 바로잡아야 하는 것은 약간 귀찮습니다.

const myFunc = function () {}

당신은 느슨한 게양, 그리고 function.name

PR #2399에 추가된 구현

업데이트: 제안이 업데이트되고 @wycats ES7 JavaScript 데코레이터에 대한 링크가 추가되었습니다.

학급만의 일이 되어 안타깝습니다...
또한 앰비언트 데코레이터는 범위를 벗어났습니까?

기능에 대한 귀하의 제안과 함께 @fdecampredon 은 여전히 ​​게양을 잃는 것 같습니다.

@JsonFreeman 왜? 파일 맨 위에 _t 를 삽입하면?

import something from 'something';

myFunc(something.something());

@F("color") <strong i="8">@G</strong> 
function myFunc() {
  doSomething()
}

import something from 'something';

var _t = function() {
   doSomething();
}
_t = F("color")(_t = G(_t) || _t) || _t;  

myFunc(something.something());

function myFunc() {
  return _t.apply(this, arguments)
}

또한 내 제안에 많은 문제가 있더라도 함수에 데코레이터를 사용할 수 있고(변수 할당 함수를 사용해야 하는 경우에도) 호이스팅을 잃을 수 있기를 진지하게 원합니다.
이 요지 와 같은 경우는 함수와 클래스 모두에 대해 꽤 좋은 데코레이터 사용 사례로 보입니다(특히 여전히 범위에 있는 경우 주변 데코레이터와 결합됨)

@fdecampredon 데코레이터는 표현 자체이기 때문에 일반적인 경우에는 작동하지 않습니다. 예

myFunc();  // assumes function declaration is hoisted

var dec = (t) => t; // defininig a decorator

<strong i="7">@dec</strong>
function myFunc() {}

데코레이터의 함수 선언과 애플리케이션을 호이스트하면 데코레이터가 깨집니다. 함수 선언만 호이스트하고 데코레이터 애플리케이션은 호이스트하지 않으면 장식되지 않은 상태에서 함수를 목격할 수 있습니다. 여기에는 매력적인 솔루션이 없습니다.

이것은 ES6에서 표현식인 클래스 선언 확장 절과 동일한 문제입니다. 결과는 클래스 선언이 아니라 기호(var 선언과 유사하지만 함수 선언은 아님)만 끌어올리는 것이었습니다.

@mhegazy 감사합니다.
그러나 기능 부분이 원래 @jonahandturner 제안을 완전히 포기한 이유는 다음과 같습니다.

decorated function declarations cannot be hoisted to the containing scope

호이스팅을 잃는 것은 확실히 단점이지만 다른 구성에 대한 사용 사례가 있을 때 클래스 전용 기능으로 변환하는 것이 손상될 수 있다는 것을 알았습니다.

원하는 제약 조건 집합이 의미하는 바를 살펴보겠습니다.

• 장식된 기능은 호이스트되어야 합니다.
• 함수는 사용 가능한 즉시 데코레이트되어야 합니다. 따라서 데코레이터 애플리케이션은 호이스트되어야 합니다.
• 데코레이터는 적용되기 전에 정의되어야 합니다. 따라서 데코레이터 정의 자체(또는 데코레이터 표현식에서 참조하는 모든 엔티티)는 호이스트되어야 합니다.
• 데코레이터 표현식은 어휘적으로 적용된 위치에서 평가되므로 애플리케이션을 호이스팅할 수 없습니다.

이에 대해 내가 볼 수 있는 유일한 해결책은 다음과 같습니다. 함수 데코레이터의 경우 @identifier 형식만 허용합니다. 우리는 왼손 표현을 허용하지 않습니다. 또한 식별자는 함수 선언(데코레이트된 함수 포함)에 대한 직접 참조여야 합니다. 범위에서 발생하는 모든 함수 장식은 적용된 순서대로 범위의 맨 위에서 방출되어야 합니다.

호이스팅 규칙을 깨는 문제는 그것이 놀랍다는 것입니다. 잠시 동안 자바스크립트를 작성하는 경우 함수 선언이 사전적으로 선언되기 전에 사용할 수 있을 것으로 예상합니다. 이제 겉보기에 단순한 구문 표시자(데코레이터)를 추가하여 함수 선언의 기본 특성을 변경합니다.

ES7 제안은 아직 초기 단계이므로 발전하고 확장할 것으로 기대합니다. 따라서 최종 제안에는 어떤 형태로든 기능이 포함될 것이라고 생각할 수 있습니다.

나는 그것들을 들어 올려야 한다고 생각합니다. 나는 우리가 기능에 허용하는 유일한 장식은 확실히 그 자체로 게양되는 장식이라고 말하고 있습니다. 즉, 함수 선언을 참조하는 식별자입니다.

그러나 여기에 또 다른 문제가 있습니다. 장식된 모든 기능을 동시에 호이스트하고 장식되지 않은 상태에서 관찰되지 않도록 하는 것은 실제로 불가능합니다. 문제는 데코레이터 주기에서 볼 수 있습니다.

<strong i="7">@dec1</strong>
function dec2(target: Function) {
   // Do stuff
}

<strong i="8">@dec2</strong>
function dec1(target: Function) {
   // Do stuff
}

두 기능이 모두 호이스트되어도 어느 것이 먼저 장식됩니까? dec2가 먼저 장식되면 dec2에 적용될 때까지 dec1 자체가 장식되지 않습니다.

따라서 우리는 다음 중에서 선택해야 합니다.

• 기능이 호이스팅되지 않음
• 장식되지 않은 함수는 호이스트되지만 데코레이터 응용 프로그램은 함께 호이스팅되지 않습니다.

나는 이 중 어느 것도 좋아하지 않지만, 다른 어떤 것도 가능하다고 생각하지 않습니다.

이것은 JS 제안입니다. 따라서 엔진은 표현식이 함수 선언을 참조하는지 여부를 알지 못하지만 정적 분석을 통해 알 수 있습니다. 이걸 고려하세요:

<strong i="6">@dec1</strong>
function dec2(target: Function) {
   // Do stuff
}

dec2 = undefined;

<strong i="7">@dec2</strong>
function dec1(target: Function) {
   // Do stuff
}

으악! Javascript는 더 이상 단순하지 않습니다. :-)

_expressions_ 기능에서만 활성화하는 것이 더 쉬울 것입니다.

const foo = <strong i="6">@decorator</strong> () => {
    // ...   
}
const bar = <strong i="7">@decorator</strong> function() {
    // ...
}

함수 표현식 또는 람다가 호이스트되지 않습니다.

typescript 1.5.0-alpha의 데코레이터에 이와 같은 매개변수를 사용할 수 있습니까?

@dec1({key1: value1, key2, value2})
function dec2(target: Function) {
   // Do stuff
}

신경쓰지 마세요. 매개변수를 사용하고 실제 데코레이터 기능을 반환하는 팩토리를 생성하세요.

예를 들어, 문자열 매개변수가 있는 클래스 데코레이터는 다음과 같습니다.

function decoratorWithString(param: string) { // Decorator factory
    return function(target) { // Actual decorator
        // Do stuff with target and string parameter
    }
}

// Usage
@decoratorWithString('foobar')
class Foo {

}

인사말.

생성자에 선언된 유형을 선택하는 데코레이터를 작성하는 방법을 알아 내려고 노력 중입니다.

여기에 내가 하려고 하는 것을 설명하는 몇 가지 코드가 있습니다. 하지만 이는 고정되어 있습니다. 클래스 D의 생성자 선언에 응답하는 데 필요합니다.

class A {
  public message = "identity: class A";
}

class B {
  public message = "identity: class B";
}

<strong i="8">@decoTest</strong>
class D {
  static metadata:Array<Function> = [];
  constructor(a: A, b: B) {
  }
}
describe("decorators", function() {
  it("should inject constructor types", function() {
    var d = new D(new A(), new B());
    expect(D.metadata.length).toBe(2);
  });
});


function decoTest<T>(target: T, ...rest) {
  target["metadata"].push(A, B); // how do i get this based on constructor ???
  return target;
}

유형 정보가 데코레이터 기능의 범위를 벗어납니다.
각 매개변수에 ParameterDecorator를 사용하여 해당 정보를 추가할 수 있습니다.

ParameterDecorator의 타이핑이나 구현이 정확하지 않습니다. 타이핑에서 대상은 함수이지만 typescript를 사용하는 동안에는 프로토타입 객체입니다.
올바른 유형을 얻으려면 대상 매개변수를 캐스팅해야 합니다.

function MyParameterDecorator (_target: Function, methodName: string, index: number) {
    const target = <InterfaceForMyUseCase><anyt>_target;
    // do stuff
}

대신에:

function MyParameterDecorator (target: InterfaceForMyUseCase, methodName: string, index: number) {
    // do stuff
}

와우 - 매개변수 데코레이터 규칙 !!!!!!!!!!!!!! 이 리포지토리를 참조하십시오

다음은 테스트를 실행한 결과입니다.

LOG: 'injectMe:'
LOG: '  type: class A'
LOG: '  type: class B'
LOG: '  some key'

그리고 코드 :

module ParameterDecorators {
  class A {
    static typeName:string = "type: class A";
    public instanceTypeName = "instance: class A";
  }

  class B {
    static typeName:string = "type: class B";
    public instanceTypeName = "instance: class B";
  }

  @injectTest(A, B, "some key")
  class C {
    static injectMe: Array<any> = [];
    constructor(a: A, b: B) {
    }
  }

  function injectTest(...rest) {
    return function(target): void {
      target["injectMe"] = rest;
    }
  }

  describe("decorators", function() {
    it("should inject dependency-injection keys", function() {
      var c = new C(new A(), new B());
      console.log("injectMe:");
      for (let parm of C.injectMe) {
        if (typeof(parm) === "function") {
          console.log("\t" + parm["typeName"]);
        } else {
          console.log("\t" + parm)
        }
      }
    });
  });
}

나는 데코레이터 기반 API를 사용하여 익스프레스(그러나 모든 웹 프레임워크가 지원될 수 있고 어댑터 인터페이스가 정의됨) 주위에 래퍼를 만들었습니다. https://github.com/cybrown/web-decorators

ClassDecorator, ParameterDecorator 및 MethodDecorator를 사용하고 있습니다.

@cybrown 지금 마스터에 있는 #2635에서 ParameterDecorator 에 대한 서명을 업데이트했습니다.

@rbuckton 감사합니다.

ParameterDecorator에서 매개변수의 이름을 가질 수 있습니까?
이것은 매개변수의 이름이 ParameterDecorator의 첫 번째 인수의 절반이 될 수 있다고 생각하기 때문에 유용할 수 있습니다.
게다가, 그것은 축소자에 의한 매개변수 이름 맹글링에 대한 해결책이 될 수 있습니다.

나는 이것을 성취하도록 요청받았다:

@inject(A, B, "some key")
  class C {
    static injectMe: Array<any> = [];
    constructor(a: A, b: B) {
    }
  }

  function inject(...rest) {
    return function(target): void {
      target["inject"] = rest;
    }
  }

그러나 주입 데코레이터에서 키를 지정하지 않고 대신 데코레이터가 다음 줄을 따라 생성자의 클래스 함수를 자동으로 선택하도록 합니다.

inject(<strong i="9">@parameterTypes</strong> types:Function[]){ ... }

@jonahandturner가 여기에서 설명하는 작업을 수행하는 방법을 찾고

@cmchaelgraham 예, 런타임 유형 정보(AtScript에 설명된 rtti)가 있으면 내부 검사와 같이 완전히 분리된 기능에서도 그런 종류의 사용에 매우 좋습니다.

@cmchaelgraham 은 https://github.com/Microsoft/TypeScript/pull/2589를 살펴보십시오.

@cmicaelgraham 우리는 데코레이터와 함께 작동할 메타데이터 API 를 추가하는 ES7에 대한 제안을 작업 중입니다. #2589는 해당 제안에 대한 실험적 지원을 추가하지만 메타데이터를 읽으려면 별도의 폴리필 이 있어야 합니다.

@rbuckton @cmichaelgraham 원래 데코레이터 대상에 따라 데코레이터에 유형을 주입하도록 컴파일러에 지시하는 특수한 TypeScript 데코레이터를 위한 디자인이 있었습니다. 나는 그것이 @parameterTypes 라고 생각합니다. 더 일반적인 메타 데이터 API를 위해 그 기능이 제거되고 있다고 생각하는 것이 맞습니까? 그렇다면 지원하겠습니다.

TypeScript와 관련된 상태에 대해 조금 말씀해 주시겠습니까? 1.5 출시 예정인가요? 그렇다면 컴파일러 옵션은 어떻게 생겼습니까? 유용한 한 가지는 컴파일러가 생성자 서명에 대해서만 형식 메타데이터를 자동으로 생성하도록 하는 것입니다.

@EisenbergEffect 데코레이터는 1.5의 일부이며 최신 릴리스 1.5-alpha에서 사용할 수 있습니다.

메타 데이터 지원에 관해서. @paramtypes 대한 원래 제안 이후 디자인이 변경되었습니다. 새로운 디자인은 Reflect.metada 제안을 사용하고 있습니다. 작동 방식에 대한 자세한 내용은 #2589를 참조하세요. 또한 @rbuckton 에는 https://github.com/rbuckton/reflectDecorators 에서 메타데이터를 사용하기 위한 pollyfill이 있습니다.

@mhegazy 알겠습니다 . 여기를 참조하십시오: http://blog.durandal.io/2015/04/09/aurelia-update-with-decorators-ie9-and-more/ :smile:

메타데이터 제안에 대해서도 잘 알고 있습니다. 이에 대한 피드백을 해왔습니다. 원래 @parameterTypes 아이디어가 제거되는지 알고 싶었습니다.

공유해 주셔서 감사합니다 @EisenbergEffect . :+1:

예. @paramtypes 의 유일한 문제는 방출이 유형 시스템에 의해 지시되고 전역 프로그램 정보가 필요하다는 것입니다. 이것은 단일 모듈 변환에 대한 시나리오를 중단합니다(#2499 참조). 다른 옵션은 콜 사이트에 넣는 것인데, 이는 작성자 대신 데코레이터 사용자에게 많은 작업을 추가합니다. 그래서 우리는 다시 기본으로 돌아가서 Reflect.metadata 접근 방식을 사용했습니다.

제안의 이전 버전도 봤다면 같은 이유로 앰비언트/디자인 타임 데코레이터를 제거해야 했습니다.

명확히 해 주셔서 감사합니다. 모든 것이 이해가 됩니다. Reflect 기반 접근 방식이 1.5에 도입될지 여부에 대한 아이디어가 있습니까?

예. 현재 마스터에 있습니다. 다음 릴리스에서 사용할 수 있어야 합니다. 현재 실험 플래그 --emitDecoratorMetadata 사용하는 옵트인 기능입니다. 데코레이팅된 엔터티에만 메타데이터를 추가합니다.

"데코레이팅된 엔터티에만 메타데이터를 추가합니다." 그 아이디어를 확장할 수 있습니까? 특별한 데코레이터가 참여합니까? 아니면 어떤 데코레이터와 함께 무엇이든 추가합니까? 즉, 개발자가 Aurelia의 inject 데코레이터를 사용하는 경우 컴파일러가 메타데이터를 생성하도록 트리거합니까?

개발자가 Aurelia의 인젝트 데코레이터를 사용하는 경우 컴파일러가 메타데이터를 생성하도록 트리거합니까?

예.

내가 의미하는 바는 다음과 같습니다.

<strong i="9">@inject</strong>
class Foo {
    constructor(a: number, b: string) {}
}

class Bar {
    constructor(a: number, b: string) {}
}

함께 --emitDecoratorMetadata (즉, 호출에 입력 메타 데이터를 방출 할 컴파일러 reflect.metadata('desing:paramtypes', [Number, String]) 용) Foo 이지만 _not_ Bar .

그것은 우리를 위해 작동합니다. 다음 릴리스, 아마도 다음 주에 Reflect.metadata API에 대한 지원을 준비할 것입니다. 설명 감사합니다!

그래서 이것을 위해 무엇을 방출합니까?

``` 언어=자바스크립트
@주사
클래스 푸 {
생성자(a: A, b: B) {}
}

클래스 바 {
생성자(a: 숫자, b: B) {}
}

would it be (for Foo):

``` javascript
reflect.metadata('desing:paramtypes', [A, B])

@cmchaelgraham 예, 대략적으로 생성된 것입니다.

미친 멋져!!!!

gulp -typescript 를 사용하여 이 리포지토리 구축 - (멋진 @ivogabe)

gulpfile build-ts 명령( emitDecoratorMetadata 옵션 참고):

gulp.task('build-ts', function () {
    var tsResult = gulp.src([
        './views/*.ts',
        './typings/**/*.d.ts',
        './*.ts'
        ],
        {base: "."})
    .pipe(ts({
         typescript: require('typescript'),
         declarationFiles: false,
         noExternalResolve: true,
         target: "es5",
         module: "amd",
         emitDecoratorMetadata: true
    }));

    return merge([
        tsResult.dts.pipe(gulp.dest('.')),
        tsResult.js.pipe(gulp.dest('.'))
    ]);
});

app.ts 회전

import {inject} from 'aurelia-framework';
import {Router} from 'aurelia-router';
import 'bootstrap';
import 'bootstrap/css/bootstrap.css!';

@inject(Router)
export class App {
  public router;
  constructor(router:Router) {
    this.router = router;
    this.router.configure(config => {
      config.title = 'Aurelia';
      config.map([
        { route: ['','welcome'],  moduleId: './welcome',      nav: true, title:'Welcome' },
        { route: 'flickr',        moduleId: './flickr',       nav: true },
        { route: 'child-router',  moduleId: './child-router', nav: true, title:'Child Router' }
      ]);
    });
  }
}

app.js

var __decorate = this.__decorate || (typeof Reflect === "object" && Reflect.decorate) || function (decorators, target, key, desc) {
    switch (arguments.length) {
        case 2: return decorators.reduceRight(function(o, d) { return (d && d(o)) || o; }, target);
        case 3: return decorators.reduceRight(function(o, d) { return (d && d(target, key)), void 0; }, void 0);
        case 4: return decorators.reduceRight(function(o, d) { return (d && d(target, key, o)) || o; }, desc);
    }
};
var __metadata = this.__metadata || (typeof Reflect === "object" && Reflect.metadata) || function () { };
define(["require", "exports", 'aurelia-framework', 'aurelia-router', 'bootstrap', 'bootstrap/css/bootstrap.css!'], function (require, exports, aurelia_framework_1, aurelia_router_1, , ) {
    var App = (function () {
        function App(router) {
            this.router = router;
            this.router.configure(function (config) {
                config.title = 'Aurelia';
                config.map([
                    { route: ['', 'welcome'], moduleId: './welcome', nav: true, title: 'Welcome' },
                    { route: 'flickr', moduleId: './flickr', nav: true },
                    { route: 'child-router', moduleId: './child-router', nav: true, title: 'Child Router' }
                ]);
            });
        }
        App = __decorate([
            aurelia_framework_1.inject(aurelia_router_1.Router), 
            __metadata('design:paramtypes', [aurelia_router_1.Router])
        ], App);
        return App;
    })();
    exports.App = App;
});

특히 흥미로운 것은 생성자 매개변수에 대한 방출된 유형 메타데이터입니다.

        App = __decorate([
            aurelia_framework_1.inject(aurelia_router_1.Router), 
            __metadata('design:paramtypes', [aurelia_router_1.Router])
        ], App);

따라서 이론상으로는 주입 데코레이터 함수를 변경하여 주입에서 지정하지 않고 적절한 클래스를 주입할 수 있지만 대신 생성자에서 유형을 지정할 수 있습니다. :)

@cmhichaelgraham 우리는 프레임워크를 변경하지 않고도 이것을 쉽게 활성화할 수 있습니다. Aurelia의 DI 라이브러리에는 container.addParameterInfoLocator 후크가 있습니다. 형식을 취하고 종속성을 반환할 수 있는 함수를 전달합니다. 다음 릴리스(다음 주)에서는 이것을 핵심 구성에 추가할 수 있으므로 TypeScript 개발자가 쉽게 켤 수 있습니다. 이번 주 출시에 넣었어야 했는데 이게 변경된 줄은 아직 몰랐습니다.

@EisenbergEffect 브릴리언트 !! :+1:

나는 주석을 사용하여 개체의 속성을 관찰 가능한 것으로 표시했는데, 이는 기본 개체를 관찰 가능한 개체로 변환합니다(관심 있는 사람들을 위해 https://github.com/mweststrate/MOBservable/commit/8cc7fc0e20c000db660037c8b5c9d944fe4155d9).

그러나 특히 속성의 경우 클래스 자체의 생성자가 아닌 프로토타입에 주석을 적용하는 것이 다소 부자연스럽게 느껴졌습니다. 즉, 초기 값을 가져오기가 어렵거나 this 도 어렵습니다. this 및 값을 사용할 수 있기 때문에 주석이 수행해야 하는 실제 논리를 수행하는 것입니다.

게다가 굉장한 기능!

Metadata Reflection API를 사용하여 간단한 속성 종속성 주입을 수행할 수 있었습니다.
필요한 변경 사항은 https://github.com/matjaz/property-DI/commit/2b4835e100b72d954b57d0e656ea524539ac17eb에서 확인할 수 있습니다

모든 데코레이터보다 먼저 호출되는 생성된 코드에서 __metadata 데코레이터가 아니어야 합니까? 클래스의 메타 데이터를 사용하여 간단한 deocrator를 만들고 싶었지만 __metadata('design:paramtypes', [TYPES....])가 마지막으로 호출되었으므로 Reflect에서 이러한 데이터를 가져올 수 없습니다.

@ufon 보고 있는 코드를 공유할 수 있습니까?

물론입니다. https://gist.github.com/ufo/5a2fa2481ac412117532

편집하다:
내 나쁜, 내 코드에 다른 실수가 있습니다. 클래스 초기화 후에도 유형을 가져올 수 없습니다.

@ufon , 나는 그때 내가 문제를 볼 수 있는지 확신하지 못합니다. __metadata는 데코레이터 목록의 마지막 항목입니다. 즉, 이것이 가장 먼저 실행되고, 확실히 주입이 실행되기 전에 실행된다는 의미입니다.

    House = __decorate([
        inject_1.inject, 
        __metadata('design:paramtypes', [Floor, String])
    ], House);

여기서 __decorate 정의는 권한 축소를 사용하여 데코레이터를 역순으로 실행합니다.

decorators.reduceRight(function(o, d) { return (d && d(o)) || o; }, target);

이는 데코레이터(표현식)가 선언 순서대로 평가되지만 역순으로 실행되어 외부 데코레이터가 내부 데코레이터의 결과를 소비할 수 있도록 하는 사양과 일치시키기 위한 것입니다.

알겠습니다, 죄송합니다: 죄송합니다. 제 코드에 다른 실수가 있습니다. 클래스 초기화 후에도 유형을 가져올 수 없습니다.

당신은 그들을 어떻게 쿼리하고 있습니까? Reflect.metadata에 대한 pollyfill이 있습니까?

요점에 추가 ...
Reflect.getMetadataKeys(하우스);
이 결과 빈 배열 ..

예, 'reflect-metadata' 패키지가 필요합니다.

그것을 잃어버린 polyfill 같은 외모, @rbuckton 당신은 좀 걸릴 수 있습니다.

받았다고 생각해...
필요는 typescript의 도우미 코드 뒤에 이동됩니다.

var __metadata = this.__metadata || (typeof Reflect === "object" && Reflect.metadata) || function () { };
require('reflect-metadata');

따라서 var __metadata가 초기화되는 동안 폴리필이 아직 로드되지 않았습니다.

하지만 생성된 코드 전에 이러한 요구 사항을 얻을 수 없습니다.

편집: 요점 업데이트

음.. 더 큰 문제입니다. 추적하기 위해 기록된 문제 #2811

그때까지는 다른 모듈에 reflect-metadata 가 필요합니다(두 개의 파일이 필요합니다).
https://github.com/matjaz/property-DI/ 참조

변수/선택적 매개변수를 사용하여 데코레이터를 개발하는 것을 상당히 어렵게 만드는 호출 불일치가 있는 것으로 보입니다. 예로서:

<strong i="6">@F</strong>
prop: number;

@F()
prop: number;

전자에서 F는 매개변수(target, propertyName, propertyDescriptor)를 사용하여 호출되는 반면 후자에서는 F가 매개변수()를 사용하여 호출되며 반환된 내부 함수가 있어야 합니다. 속성 설명자).

내 가정은 @F 와 @F()가 모두 동등하므로 데코레이터가 0개 이상의 매개변수를 지원하는 경우에만 두 호출을 수행할 수 있다는 것입니다.

이것은 다음과 같은 경우에 특히 중요합니다.

<strong i="13">@F</strong>  // Performs some default behaviour.
prop: number;

@F({ option: true }) // Performs some configured behaviour.
prop: number;

이것은 @F 대신 @F()를 명시적으로 호출하여 해결할 수 있지만 실수를 하기 쉽고 데코레이터가 작동해야 하는 모양에도 불구하고 작동하지 않을 때 혼동하기 쉽습니다.

이 경우 다음을 수행하고 싶습니다.

export function F(options?: any): PropertyDecorator {
    return (target, name) => {
        // do something.
    }
}

그것으로 끝났지만 대신 다음과 같은 조잡한 예와 같은 작업을 수행해야 합니다.

export function F(...args: any[]): any {
   var func = (target, name) => {
      // do something.
   }

   if (args.length === 1) return func;
   else if (args.length === 2) func(args[0], args[1]);
}

진짜 고통입니다.

@Tharaxis 이 동작은 @F 및 @F() 는 동일하지 않습니다. @F 는 데코레이터 F @F 호출합니다. 여기서 @F() 는 빈 인수 목록으로 데코레이터 요소 F 를 호출한 다음 결과 데코레이터를 적용합니다.

여기서 문제는 컴파일러가 데코레이터 팩토리 F 의 서명을 할당 가능한 declare type PropertyDecorator = (target: Object, propertyKey: string | symbol) => void; 와 비교한다는 것입니다. 이러한 문제를 파악하려면 더 강력한 확인이 필요하다고 생각합니다. 이 문제를 해결하기 위해 #3246을 기록했습니다. 나는 당신이 올바른 일을하고 있다고 믿으며 컴파일러는 데코레이터 팩토리의 잘못된 사용을 포착해야 합니다.

@mhegazy 그러나 이것이 왜 그런지는 모르겠지만 @F 및 @F() 동등하게 만드는 것을 배제하는 사용 사례가 있습니까 ? 궁극적으로 둘 다 데코레이터 기능의 동일한 호출이기 때문입니다. , 그들 중 하나만 외부 팩토리 함수에 대한 호출을 포함합니까? 이것은 확실히 매우 놀라운 동작이고 API 소비자의 관점에서 데코레이터를 호출하는 데 두 가지 방법이 있어야 하는 이유를 이해하지 못하기 때문에 여기서 최소 놀라움의 원칙이 위반되는 것처럼 보입니다.

JS 관점에서 차이가 있다는 것을 알지만(하나는 F 함수의 참조를 전달하고 다른 하나는 함수를 실행한 다음 데코레이터로 해당 결과의 참조를 전달합니다), 저는 그렇지 않습니다. @F 로 전달된 데코레이터를 빈 매개변수 목록이 있는 팩토리와 암시적으로 일치(및 호출)할 수 없는 이유를 확실히 이해하고 있습니까?

컴파일러는 그것이 팩토리인지 데코레이터인지 알 방법이 없습니다. 이 서명이 있는 경우:

declare function decoratorOrFactory (...args: any[]): any;

이것은 데코레이터입니까 아니면 공장입니까? 빈 인수로 호출해야합니까?

컴파일러가 할 수 있는 대부분은 서명을 호출할 때 서명이 일치하는지 확인하고 일치하지 않으면 오류를 제공하는 것입니다.

@rbuckton 에는 데코레이터가 공장으로 사용되지 않는 경우에 플래그를 지정해야 하는 #3246에 대한 수정 사항이 있으므로 계속 지켜봐 주시기 바랍니다.

@mhegazy , 내가 말하는 것은 데코레이터(즉, @F 또는 @F() )를 사용하는 것은 _항상_ 팩토리 함수 F의 호출이어야 하며, 이는 차례로 적절한 데코레이터 유형을 반환해야 한다는 것입니다. 캡슐화 팩토리가 없는 데코레이터의 최상위 표현은 없습니다.

즉, F의 서명은 항상 다음과 같습니다.

declare function F(...args: any[]): ClassDecorator | PropertyDecorator | MethodDecorator | ParameterDecorator;

또는 그에 상응하는 것.

그런 다음 @F 호출은 컴파일러에서 @F() 와 동일하게 만듭니다. @F 및 @F() 서명은 모두 어떤 형태로든 공장 서명과 일치해야 하므로 호출 혼동 문제를 해결합니다. 데코레이터를 호출하는 방법은 한 가지뿐입니다!

다음을 감안할 때:

declare function F(...args: any[]): PropertyDecorator {
    return (target, name) => {
        // do stuff.
    }
}

@F()
property: number;

그리고

declare function F(target, name) { // Matches PropertyDecorator
    // do stuff.
}

<strong i="22">@F</strong>
property: number;

그들은 같은 일을 하지만 나는 그것들을 다르게 선언해야 합니다! 그러나 양방향으로 존재할 수 있도록 F를 선언하는 것은 정말 번거롭고 일관된 매개변수와 문서를 만드는 것을 불가능하게 만듭니다. 데코레이터가 팩토리를 사용해야 하는지 여부를 선택하고 API 소비자가 이를 사용하려면 미리 이 구분을 알아야 합니다.

@Tharaxis 데코레이터로 사용될 F 를 제공하는 라이브러리를 보고 있다면 @F 와 @F() 가 완전히 다를 것으로 예상합니다. C 와 C() 가 다른 것으로 예상하는 것처럼 첫 번째는 값을 참조하고 두 번째는 값을 호출합니다. @F 는 데코레이터를 적용하고 @F() 는 데코레이터를 생성하는 함수를 호출합니다. 그것들은 동일한 작업이 아니며 그렇게 되어서도 안 됩니다.

@DavidSouther 이것이 그럴 수 없거나 그렇지 않은 타당한 이유가 있습니까? @F 호출과 @F() 호출 간에 기능적 차이는 없지만 정의 및 문서화 방법 간에는 상당히 큰 차이가 있으며 호출에 불필요해야 하는 추가 복잡성이 추가됩니다.

내 제안은 데코레이터를 정의하는 데 두 가지 방법이 있어서는 안 되며 데코레이터를 한 가지 이상 정의할 필요가 없기 때문에 필요하지 않다는 것입니다.

@F 와 @F() 호출 사이에는 기능적 차이가 없습니다.

나는 이것이 논쟁의 주요 포인트라고 생각한다. 나는 이것이 사실이라고 생각하지 않는다. F는 함수에 대한 참조이고, F()는 빈 인수 집합(예: F.call(this, []) )으로 호출될 때 F의 반환 값에 대한 참조입니다. 그리고 이것들은 기능적으로, 그리고 개념적으로 다른 두 가지입니다.

@Tharaxis @F 와 @F() 는 다릅니다. 사용 방법의 차이, 문서화 방법의 차이, 절대적으로 필요한 호출의 차이가 있습니다.

다른 방식으로 질문해 보겠습니다. 왜 모든 데코레이터 기능이 팩토리여야 합니까? 귀하의 제안을 사용하여 간단한 데코레이터를 갖는 것은 불가능합니다.

@mhegazy 후자의 옵션( @F() )은 격리된(및 복제된) 데코레이터 함수와 @F 호출을 통해 기능적 클로저와 추가 오버헤드를 생성한다는 점을 인정합니다. 본질적으로 공유 데코레이터 기능 참조에 대해 수행하므로 클로저를 통한 격리가 "더 안전"하고 일관성이 있어 놀라움의 가능성이 줄어듭니다.

@DavidSouther 귀하의 질문은 귀하가 간단한 데코레이터로 정의하는 것에 달려 있습니다. 다음과 같은 형태의 간단한 데코레이터를 사용하는 것을 방해하는 것은 없습니다.

declare function F(): PropertyDecorator {
    return (target, name) => {
        // do stuff
    }
}

"간단한 구문"보다 2줄만 더 많고 사용 가능한 데코레이터 호출이 무엇인지 더 명확하게 정의하기 때문에 이것이 매우 최소한으로 침습적이라는 것을 알았습니다. 또한 데코레이터를 정의하는 방법은 단 하나뿐이므로(일관성의 가치를 무시하지 말자) "간단한 구문"과 비교하여 이를 완성하는 데 약 2초가 더 걸릴 것입니다.

또한 더 문제가 되는 문제는 다음과 같습니다.

declare function F(options?: any): PropertyDecorator {
    return (target, name) => {
        // do stuff
    }
}

@F()
property1: number;

<strong i="15">@F</strong>
property2: number;

@F({ option: true })
property3: number;

이 중 하나는 다른 것과 같지 않습니다. @F 의 사용은 액면 그대로는 확실히 작동하지만 작동하지 않습니다. 내가 F의 기본 선언이 어떻게 생겼는지 알지 못하지만 F가 존재하고 선택적 인수 집합을 사용할 수 있다는 것만 아는 사람이라고 가정하십시오. 내가 @F 로 실수할 가능성은 현재 메커니즘에서 사소한 일이 아닙니다. 이것은 개발자/문서 작성자에게 @F 가 작동하지 않는다는 사실을 소비자가 인식하도록 하는 데 큰 부담이 됩니다(그러나 @C 는 어떻게든 "다르므로" 작동할 것입니다).

소비자가 걱정할 필요가 없는 "모든 사람에게 맞는" 데코레이터를 원한다면 다음과 같은 끔찍한 일을 해야 합니다.

declare function F(...args: any[]): any {
    var decorator = (target, name) => {
        // do stuff
    }

    // Heaven forbid your decorator formal parameter list also can take 2 parameters.
    return (args.length === 2) ? decorator(args[0], args[1]) : decorator;
}

솔직히 끔찍합니다. 또한 이제 일반화해야 하므로 데코레이터 F에 대한 모든 중요한 매개변수 인텔리센스를 잃게 됩니다.

데코레이터를 정의하고 문서화하기 쉽고 일관성 있게 하는 것에 대해서는 할 말이 많습니다. 우리의 코드를 사용하는 모든 사람이 그 코드의 작성자인 우리와 같은 지식이나 이해력을 가질 것이라고 생각하도록 스스로를 속이지 맙시다.

@Tharaxis 데코레이터를 위한 디자인 초기에 이것에 대해 생각했고 구체적인 요점을 이해합니다. @mhegazy 와 @DavidSouther 가 이 스레드에서 이전에 언급했듯이 이 동작은 JavaScript 함수의 표준 동작과 일치합니다.

데코레이터와 데코레이터 팩토리 모두의 역할을 할 수 있는 함수를 생성하려는 시도는 다소 복잡할 수 있다는 것이 맞습니다. 그러나 일반적으로 항상 데코레이터 팩토리를 사용하고 이 관행이 채택되도록 린터에 규칙을 제공하는 모범 사례를 사용하는 것이 더 나을 수 있습니다.

또한 데코레이터에 대한 유형 검사의 불일치에 대한 이전 요점을 해결하기 위해 방금 PR #3249를 제출했습니다.

안녕하세요 @rbuckton 님 ,

저는 @Tharaxis가 언급한 데코레이터를 잘 사용하지 않는 사용자 중 하나입니다...

내가 가질 질문은 데코레이터가 기능과 일치해야 하는가? 즉, 함수의 경우 this.f 대 this.f()를 반환하는 것은 내가 값을 원할 때도 있고 값을 생성하는 것을 원할 때도 있기 때문에 완전히 의미가 있습니다.

데코레이터의 경우 언어 기능 수준에서 나에게 명확하지 않은 것 같습니다. 나는 단지 데코레이터 @F 를 적용하고 싶다고 주장하고 싶습니다. 나는 그것이 팩토리 또는 정적 메소드로 구현되었는지 여부를 정말로 알고 싶지 않습니다. 내가 데코레이터가 가질 수 있는 일부 기능을 잃어버리지 않는 한 말입니다.

위의 내용이 잘못되었거나 무지한 경우 사과드립니다. 저는 비교적 새로운 자바스크립트 세계입니다.

감사합니다 & 건배

또한 그 질문을 해야 합니다. "함수를 사용하여 정의되었기 때문에"가 아닌 다른 실제 이유가 없는 경우에만 _if_ 함수를 사용하여 구문적 동등성을 유지하는 것이 의미가 있습니까? 나는 데코레이터를 사용하여 정의하기만 하면 _발생_하는 기능과 완전히 관련이 없는 기능이라고 생각합니다.

현재 @F 및 @F() 가 동일하지 않다는 사실은 다음 문제를 유발합니다.

• @F 와 @F() 의 차이점과 이것이 작동하는 이유와 작동하지 않는 이유( @F 대 @F() 를 사용해야 하는 이유)를 이해해야 하는 개발자 declare function A(params?: any): ParameterDecorator 대 declare function B(target, name) , @A 는 작동하지 않지만 @A() 는 작동하고 @B 는 작동하지만 @B() 는 작동하지 않지만 인지적으로는 인수가 없는 데코레이터의 응용 프로그램과 동일합니다.
• 코드 수준에서 문제를 해결하려면 데코레이터의 호출 구문을 적절하게 문서화하는 기능을 제거하는 어수선한 해결 방법이 필요합니다.
• 리팩토링은 '원시 데코레이터'( @F )를 생성했고 이제 일부 매개변수를 추가하려는 경우(그러나 이전 버전과의 호환성을 위해 선택사항으로 설정) 약간 더 많은 작업입니다. 현재 방법에서는 모든 @F 적용을 @F() 로 리팩토링해야 합니다. 일부는 코드 내에서 액세스할 수 없습니다. 코드로 변경하십시오.

@Tharaxis @F 와 @F() 이 소비자에게 높은 인지 부담이 될 수 있음을 이해합니다. 그러나 두 코드가 동등하게 동작하도록 내보낸 코드와 동작을 변경하도록 요청하는 것처럼 들립니다. 이는 두 가지 형식이 동일하게 취급될 가능성이 매우 낮기 때문에 데코레이터를 위한 ES7 제안과 충돌할 가능성이 높습니다. 이것이 발산으로 이어진다면 좋지 않을 것입니다.

또 다른 요점은 여기서 혼동이 함수를 콜백으로 전달하는 것과 함수를 호출하는 것 사이의 혼동과 유사하다는 것입니다. 당신이 이것을 가지고 있었다면

function callbackFactory() {
     return function(...args: any[]) { // do stuff };
}
function takesCallback(cb: (...args: any[]) => void) { }
takesCallback(callbackFactory());

사용자는 혼란 전화를받을 수 있습니다 takesCallback(callbackFactory) 호출하지 않고 callbackFactory . 이것은 실제로 데코레이터에 대해 지적한 혼동과 같지만 언어가 이 두 형식을 동일한 작업을 수행하도록 정규화하면 표현력이 손실됩니다. 때로는 구분이 중요하며 유지해야 합니다. 이것이 일반적으로 데코레이터에게도 적용되는지 확실하지 않지만 이론상으로는 확실히 가능합니다.

@JsonFreeman 나는 당신의 주장을 정말로 이해하지 못합니다. 당신은 데코레이터를 위한 ES7 제안이 존재하기 때문에 데코레이터를 자신의 실체로 이해할 수 없다는 말을 하고 있습니다. 하지만 그게 전부입니다. ES7 데코레이터는 그저 하나의 _제안_이고 제가 아는 한, 그들은' 부분적으로 Google과 귀하 자신이 설명한 데코레이터 작업의 조합을 기반으로 하고 있습니다. 맞습니까? 작동 방식에 대해서는 아직 결정된 바가 없으며 제안서가 승인 전에 _많은_ 반복을 거치게 될 것이므로 TS에서 일관된 방식으로 작동하도록 한 다음 (적어도 시도) TS에서 얻은 경험을 기반으로 아이디어 뒤에 제안에 관련된 다양한 당사자? ES6 사양이 약간 다른 동작을 요구하기 때문에 TS가 나중에 리팩토링해야 하는 기능을 구현한 것은 이번이 처음이 아닙니다. 아직 존재하지 않고 아직 합의되지 않은 사양에 대해 추적하는 한 _항상_ 문제가 발생합니다.

함수에 관한 당신의 예에 관해서는, 우리가 함수가 실제로는 완전히 다른 구조일 때(그리고 그래야만 할 때) 데코레이터와 병합하고 있는 것처럼 보입니다. JavaScript에서 함수로 작업할 때 함수가 어떻게 사용되는지 이해하고 함수 참조와 함수 호출의 차이점을 이해합니다. 함수로서 어떤 용도로 사용되는지에 대해서는 혼동이 없습니다. 데코레이터는 함수가 _아닙니다_ 함수의 동작을 상속해서는 안 됩니다. 함수는 데코레이터를 구성하는 방법일 뿐입니다. 이는 클래스가 함수라고 말하는 것과 같습니다. 그렇지 않은 경우 함수는 사용 가능한 더 분명한 방법이 없었기 때문에 ES6 이전에 클래스를 설명하는 방식일 뿐입니다. 클래스는 함수의 속성을 취하지 않으며 함수처럼 클래스를 호출할 수 없지만 ES6 이전의 함수를 사용하여 클래스를 선언합니다.

그럼에도 불구하고, 나는 그 문제에 대한 나의 논점을 다 써버렸다고 느낀다. 나는 단지 선택을 해결해야 할 것이다. 내 코드에서는 일관성을 위해 항상 팩토리를 사용합니다. 나는 여전히 데코레이터를 문자 그대로 함수로 취급하는 것이 미래에 많은 좌절을 일으킬 가능성이 있다고 생각하지만, 그것은 단지 나입니다.

@mhegazy 이것은 내가 @jonathandturner 데코레이터 https://github.com/jonathandturner/decorators/issues/16 저는 이것이 생각해야 할 문제라고 생각합니다. 현재로서는 이 디자인 선택이 "ES7 Decorator Pitfalls"와 유사한 제목의 많은 블로그 게시물의 주제가 될 것으로 기대합니다.

@Tharaxis , 첫 번째 요점에 동의합니다. 나는 ES7 제안이 우리가 무언가를 잘 디자인하는 것을 방해해서는 안 된다고 생각하지 않으며, 우리 디자인은 어쨌든 ES7의 선구자 중 하나입니다.

"데코레이터는 함수 인수가 아닙니다"에 대해 내가 틀리지 않았다면 우리는 데코레이터 자체에 대해 논의하는 것이 아니라 데코레이터 팩토리에 대해 논의하고 있습니다. 그리고 데코레이터와 함수의 구분에 관계없이 데코레이터 _factories_는 실제로는 함수일 뿐입니다. 그리고 컴파일러가 일반 함수인 데코레이터 팩토리에 대한 호출을 자동으로 생성하도록 요청하는 것처럼 들립니다. 그런 일이 발생하면 프로그래머가 데코레이터 팩토리와 데코레이터를 구분할 방법이 없을 것입니다.

또한 데코레이터를 함수로 취급할 때 좋은 점은 소비자가 그것을 데코레이터로 적용하거나 단순히 적절하다고 생각하는 대로 호출할 수 있다는 것입니다.

@JsonFreeman 인수는 데코레이터를 설명하고 호출하는 두 가지 방법이 있는 현재 상황을 중심으로 돌아

내가 묻는 것은 예입니다. 컴파일러가 @F 를 @F() 호출에 해당하는 것으로 바꾸도록 하고 유형 검사가 사용할 때 0...n 매개변수의 인수 목록을 요구하도록 할 수 있습니까 대괄호 없는 구문. 아마도 당신은 "...프로그래머가 데코레이터 팩토리와 데코레이터를 구별할 방법이 없을 것입니다..."가 의미하는 바를 자세히 설명할 수 있을 것입니다. 데코레이터는 항상 공장에서 답장을 하고, 공장명은 데코레이터 이름인데... 별로 어렵지 않은데 제가 잘못 이해하고 있는 건가요?

소비자가 데코레이터를 적용하도록 허용하는 것에 대한 마지막 요점은 모든 데코레이터가 팩토리를 사용한다고 잘 설명되어 있으면 직접 데코레이터를 호출하는 것이 매우 쉽습니다. <decorator name>(target, name) 와 비교하여 <decorator name>(<argument list>)(target, name) 하면 됩니다. <decorator name>(target, name) 를 예로 들 수 있습니다. 팩토리 사용을 의무화한다는 것은 전자의 예가 항상 작동한다는 것을 의미하지만 강제하지 않는 경우 후자의 예는 때때로 작동하지 않으며 데코레이터가 구현되는 방식에 전적으로 의존한다는 것을 의미합니다.

나는 기능을 사용하는 데코레이터에 문제가 없다는 점을 지적할 필요가 있다고 생각합니다. 그러나 내 문제는 동일한 것을 설명하는 두 가지 방법이 일관성 문제로 이어진다는 것입니다. 특히 그 두 가지 방법이 호출 방법이 달라야 함을 의미할 때 특히 그렇습니다. 이것은 리팩토링에서 언어 일관성에 이르기까지 모든 것을 방해하는 불일치입니다.

내가 몇 가지 포스트에서 설명한 리팩토링 문제는 이미 현재 방법을 검사해야 하는 이유에 충분합니다.

안녕하세요, @Tharaxis 가 말한 내용에 따라 일반 사용자에게 1.5센트 ​​가치가 있습니다.

다음과 같은 경우 현재 제안에 만족합니다.
a) 우주가 그것을 명령합니다.
b) 데코레이터는 상황이 다른 경우 중요한 기능을 잃게 됩니다.

후자는 물론 가치 판단이며 답은 개발자 유형(예: 일반 사용자/전문 사용자 등)에 따라 어느 정도 달라집니다. 저는 전자 범주에 속하며 일반적으로 여러 언어와 프레임워크에 걸쳐 얇게 퍼져 있습니다. 따라서 나에게 '중요한 기능'에는 데코레이터를 2가지 다른 방식으로 작성할 수 있는 유연성이 포함되지 않습니다. 모든 절충안의 예는 존재한다면 훌륭할 것입니다.

이상적으로는 @F 및 @F()가 데코레이터가 구현되는 방식에 관계없이 일관될 수 있다면 좋겠지만 그렇지 않다면 풀밭에서 갈퀴를 피하는 것보다 데코레이터를 작성할 때 팩토리를 사용하는 데 제약을 받는 것을 훨씬 선호합니다. 내가 그들을 사용할 때마다.

감사합니다 & 건배

이 요청은 데코레이터 팩토리가 데코레이터를 사용하는 표준적인 방법이라는 아이디어에 달려 있는 것처럼 보이지만 이것이 어떻게 사용자가 원시 데코레이터를 정의하고 사용할 수 있게 하는지 모르겠습니다. 나는 장식 정의하면 F , 응용 프로그램 @F 로 간주됩니다 @F() 대신 F 자체의 다음 F를 호출의 결과가 장식으로 사용됩니다. 누군가가 데코레이터 팩토리 대신 원시 데코레이터를 적용하려고 하면 어딘가에 오류가 발생한다는 뜻인가요?

이 아이디어는 데코레이터와 데코레이터 팩토리의 자연스러운 구성을 뒤집는 것처럼 느껴집니다. 데코레이터는 데코레이터 위에 구축된 추상화 레이어인 데코레이터 팩토리와 함께 여기에서 확실히 기본 구조처럼 느껴집니다. 그것들은 단지 하나의 패턴일 뿐 그 이상은 아닙니다. 대신 데코레이터 팩토리가 표준적인 것, 기본이 된다면 사람들은 인수를 취하지 않고 평평한 데코레이터를 반환하는 많은 데코레이터 팩토리를 정의할 것입니다. 이것은 매우 어리석게 느껴지기 시작하고 무엇이 기본으로 간주되고 무엇이 더 복잡한 것으로 간주되는지에 대한 자연스러운 직관을 뒤집을 것입니다.

내가 데코레이터에 대해 매우 조심하는 한 가지는 과도한 마법입니다. 나는 개인적으로 코드가 무엇을 하는지 이해하지 못할 때 긴장하고, 컴파일러가 프로그래머가 작성하지 않은 추가 호출을 비밀리에 추가하는 경우 너무 많은 부두교처럼 느껴집니다.

안녕하세요 @JsonFreeman ,

내가 언급했듯이 내 취향은 항상 추악함을 사용자가 아닌 데코레이터의 작성자와 함께 하는 것입니다. 그러나 많은 인수가 없는 팩토리가 매우 추악하다는 데 동의합니다. 이 문제를 해결하기 위해 데코레이터를 사용할 수 있습니까? 예

// wraps rawDecoratorMethod in a no-arg factory method.
<strong i="8">@Decorator</strong>
function rawDecoroatorMethod(target, name, descriptor) {...}

// looks like this one would be a no-op... so that feels not quite right unless there's other advantages.
<strong i="11">@DecoratorFactory</strong>
function decoroatorFactoryMethod(someArg) {...}

어쨌든, 그러한 접근 방식이 의미가 있는 것으로 판명될 수 있다면 주석이 함수의 목적을 문서화한다는 이점이 있습니다. 즉 장식합니다.

건배

좋은 육즙, 데코레이터를 정의하는 데 도움이 되는 데코레이터, Typeception의 심각한 경우.

@JsonFreeman 매개변수가 0인 함수를 사용하는 것이 대신 다수의 (대상, 이름) 함수를 사용하는 것보다 반드시 추악한 것인지 잘 모르겠습니다. 최소한 매개변수가 0인 함수가 다른 메서드에 없는 특정성/명확성 수준을 제공하고(후자의 경우 매개변수가 호출과 일치하지 않기 때문에) 그 위에 문서화할 단일 대상을 제공하는 경우 불필요한 수준의 불일치. 나는 또한 인지된 "가능한" 복잡성으로 인해 한 경로로 가는 것을 꺼려하지만, 현재 구현이 소비 측면에 부과하는 매우 실제적인 "명백한" 복잡성에 비추어 볼 때 더 많은 실수를 해야 합니다. 가능한 것보다 분명한 것.

다른 옵션은 @F 로 호출되는 데코레이터가 ClassDecorator, MethodDecorator, PropertyDecorator 또는 ParameterDecorator의 패턴 또는 ClassDecorator, MethodDecorator, PropertyDecorator를 반환하는 0..n 인수 팩토리 함수 중 하나와 일치할 수 있도록 하는 것입니다. 또는 ParameterDecorator. 그러나 그 구현이 다른 오류를 일으키고(충돌하는 두 함수가 있는 경우 어떤 것이 가장 잘 일치하는 것으로 간주됩니까?) 컴파일러 내에서 과도한 복잡성을 추가할 것이라고 생각합니다. 단순히 @F 호출을 @F() 것이 더 간단한 솔루션이 될 것이며 명시된 다양한 문제를 해결할 것입니다.

죄송합니다. 명확히하기 위해 귀하의 솔루션이 복잡하다고 주장한 것이 아닙니다. 나는 데코레이터를 적용하기 전에 자동으로 호출하는 것이 불투명하다는 것을 의미했습니다. 삽입된 호출은 사용자에게 보이지 않으며 많은 사용자가 기대하지 않을 것 같습니다.

현재의 모습도 복잡하지 않다고 생각합니다. 지적했듯이 라이브러리 작성자는 자신의 기능이 데코레이터로 적용되어야 하는지 여부에 대해 모호하거나 막연한 생각을 할 수 있습니다. 내가 당신에게 줄 것입니다. 그러나 좋은 도서관은 그것을 분명히 할 것입니다.

제안한 체계에서 자동으로 호출을 수행하는 경우 식별자 대신 임의의 데코레이터 표현식을 사용하면 어떻게 됩니까? 그것도 호출되나요?

달리 문서화되지 않는 한 암시적 호출은 놀라울 수 있지만 C# 특성 등과 같은 개념을 사용하지 않은 경우에만 해당된다는 점에 동의합니다.

임의의 데코레이터 표현이 무엇을 의미하는지 자세히 설명해 주시겠습니까?

좋은 육즙, 데코레이터를 정의하는 데 도움이 되는 데코레이터, Typeception의 심각한 경우.

공정한 전화. 주말 오후 늦은 시간에 제대로 생각하지 못한 의견을 제시하는 데 적합합니다. 교훈을 얻었다. 인터넷.실행 취소().

내 요점은 일관된 호출 사이트 구문이 팩토리 사용을 의무화하는 것으로 판명되면 그 이상으로 만족한다는 것입니다. 나는 의심 할 여지없이 보일러 플레이트를 제거하기 위해 데코레이터를 작성할 것입니다. 다시 한 번 나는 데코레이터를 사용할 때 반복되는 고통보다 약간의 고통을 선호합니다(이 시점에서 잠재적인 고통이지만). 다른 사람들은 동의하지 않을 것입니다.

API 향상에도 문제가 있지 않습니까? 팩토리 없이 생성된 데코레이터는 나중에 선택적 매개변수를 추가할 수 없으므로 미래에 @F 및 @F2() 를 예측합니다.

나는 또한 f 및 f() 사용할 때 이 시나리오를 얻을 수 없다는 것을 알지 못합니다. 이들은 소비 측면에서 서로 다른 사용 사례입니다. 데코레이터의 경우에는 항상 대상에 데코레이터를 적용/호출하고 있으며 항상 배후에서 메서드 호출이 진행되고 있습니다.

그러나 나에게 이것의 핵심은 사용성 문제입니다. 데코레이터를 적용할 때 작성자가 구현한 방법을 찾기 위해 Google을 검색할 필요가 없습니다. 패키징이 아니라 동작에 관심이 있습니다.

건배

요약할 마지막 메모만 남기고 조용히 하겠습니다. 요컨대, 이것은 정말로 저에게 있어 인터랙션 디자인 문제일 뿐입니다. 나는 외부에서 디자인된 데코레이터를 보고 싶지만 그 반대는 아닙니다.

UI/UX 전문가로서 저는 이것을 꽤 자주 봅니다. 저는 사용자에게 피해를 줄 수 있는 UI 솔루션을 제안한 재능 있는 개발자와 함께 일했습니다(한 가지 예는 트랜잭션 복잡성을 해결하기 위해 한 경우에 두 개의 저장 버튼이었습니다. 다시 똑똑한 사람과 좋은 사람). 복잡한 구현 세부 사항 논리에 대해 무릎을 꿇고 있을 때 알고 있는 것을 잊고 일반 사용자의 눈으로 보는 것이 어려울 수 있다고 생각합니다.

이제 내가 평균적으로 완전히 틀렸거나 복잡성이 현재 디자인을 요구한다면 모든 것이 좋다면, 나는 그저 정신을 차리고 배워야 할 것입니다.

건배

데코레이터가 식별자가 아니라 다른 표현식인 경우 자동으로 호출하시겠습니까? 예를 들어 데코레이터라고 가정해 보겠습니다. 대체 함수 표현식으로 OR 처리됩니다. 다음과 같은 것:

@(F || function (target) { // default decorator behavior })
class C { }

그러면 이것을 자동으로 호출합니까? 적용되기 전에 기본 데코레이터를 호출하게 되므로 잘못된 결과를 얻을 수 있습니다.

(F || function (target) { // default decorator behavior })()

이것은 옳지 않은 것 같습니다.

@JsonFreeman , 데코레이터 구문은 이와 같은 임의의 표현식을 허용합니까? 나는 개발자들에게 스스로 매달릴 만큼 많은 밧줄을 사용하도록 허용하는 것이 반드시 좋은 생각이라고 100% 확신하지 못하지만, 그것은 단지 나입니다(순전히 나는 재사용/보일러 플레이트 문제를 해결하는 것과 같은 임의의 표현을 보지 못하기 때문에 대신 코드를 보기 흉하게 만들고 따라하기가 훨씬 더 어렵게 만드는 역할을 합니다.

즉, 임의의 표현식 자체가 동일한 팩토리 구문으로 평가되는 경우에만 작동할 것이라고 가정합니다. 따라서 다음과 같습니다.

@(F || () => function(target) { /* default decorator behaviour */ })
class C { }

나는 그것이 당신의 임의의 데코레이터 주위에 약간 더 성가신 비트를 넣어야 한다는 것에 동의하지만 임의의 표현식을 데코레이터로 사용하는 경우 () => 추가하는 것보다 더 큰 문제가 있다고 생각합니다.

참고: 분명히 람다 구문이 선언하는 유일한 방법이라는 의미는 아니지만 () => 가 function() { return function(target) { /*...*/ } } 보다 약간 더 좋습니다.

이 데코레이터 호출 구문 토론을 방해해서 정말 죄송합니다. 하지만 데코레이터 표현식이 호출되는 순서를 공식적으로 명확히 할 수 있는 사람이 있습니까? 특히, 데코레이터 대상 유형의 라인을 따라 원래 소스에서 대상 멤버의 위치와 단일 대상에서 데코레이터의 순서입니다.

@billccn 데코레이터는 아래에서 위로 적용됩니다. 따라서 원본 소스 코드에서

class C {
    <strong i="7">@F</strong>
    <strong i="8">@G</strong>
    method() { }
}

이것은 먼저 메서드에 G를 적용한 다음 결과에 F를 적용합니다. 이것이 당신이 묻는 것입니까?

이것에 대해 어떻게:

<strong i="6">@A</strong>
class Clazz {
    <strong i="7">@B</strong>
    prop = 1;

    <strong i="8">@C</strong>
    method() {}

    <strong i="9">@D</strong>
    get prop() {return 1;}

    <strong i="10">@E</strong>
    method2() {}

    <strong i="11">@F</strong>
    prop2 = 1;
}

범위 순서를 따르므로 모든 속성/메서드를 먼저 선언한 다음 클래스 1을 따릅니다. 즉, B, C, D, E, F, A.

여기 에서 생성된 코드를 볼 수

현재 매개변수 속성을 장식할 수 없는 것 같습니다. 지원될 수 있습니까?

매개변수 속성은 constructor(private prop: Type) 와 같습니다. 여기서 속성(필드)과 매개변수가 함께 선언됩니다. 문제는 둘 다 장식될 수 있다는 것입니다. 따라서 상상력이 풍부한 구문을 발명해야 할 수도 있습니다.

질문: 데코레이터를 사용하여 다음과 같은 일반 개체 메서드의 동작을 수정할 수 있습니까?

var isCreatorUser = () => {  /* code that verifies if user is the creator */ },
    isAdminUser = () => { /* code that verifies if user is admin */ },

var routeConfig = {
    get() {},
    <strong i="7">@isCreatorUser</strong> patch() {},
    <strong i="8">@isAdminUser</strong> <strong i="9">@isCreatorUser</strong> delete() {}
};

... 그렇지 않다면 왜? 정말 유용할 것입니다.

아직은 아니지만 고려하고 있습니다. @rbuckton에 자세한 내용이 있을 수 있습니다.

데코레이터가 데코레이팅되는 유형에서 데코레이트된 결과 유형을 변경할 수 없는 이유를 여쭤봐도 될까요?

예를 들어 MethodDecorator는 다음과 같이 대안적으로 제안될 수 있습니다.

declare type MethodDecorator = <T, R>(target: Object, propertyKey: string | symbol, descriptor: TypedPropertyDescriptor<T>) => TypedPropertyDescriptor<R> | void;

따라서 데코레이터는 사용하기에 더 유연하고 매크로처럼 작동합니다. 데코레이트된 클래스/필드의 유형은 데코레이터 반환 유형에 따라 업데이트될 수 있으므로 유형 안전성이 계속 유지됩니다.

https://github.com/jonathandturner/brainstorming/blob/master/README.md#c4 -defining-a-decorator가 반환 유형이 동일해야 한다고 명시했음을 알고 있습니다. 그러나 type validity 는 여기에서 유효한 주장이 아닙니다. IMHO. 첫째, JavaScript의 데코레이터는 클래스/필드 유형을 변경할 수 있으므로 TS와 JS 간에 호환성 문제가 없습니다. 둘째, 데코레이터는 정적으로 적용되며, TS 컴파일러는 정의 사이트에서 원래 필드 유형과 데코레이트된 필드 유형을 추론할 수 있습니다.

@HerringtonDarkholme 나는 이것을 다른 제안에서 추적해야 한다고 말하고 싶습니다. 주된 이유는 유형에 대한 컴파일러의 이유가 선언을 통한 방식이기 때문입니다. 유형이 선언되면 변경할 수 없습니다. 믹스에 유형 뮤테이터를 추가한다는 것은 털이 많아질 수 있는 선언을 해결할 때 이를 해결해야 함을 의미합니다.

@mhegazy 그래서, 이것을 의도적인 설계가 아니라 구현 용이성을 위한 타협으로 이해할 수 있습니까?

이 제안 에 따르면 데코레이터는 선언적 구문을 유지하면서 디자인 타임에 코드를 실행할 수 있는 기능을 복원합니다. 따라서 다음 코드는
미래의 JavaScript에서는 유효하지만 오늘날의 TypeScript에서는 유효하지 않습니다.

function SafeCtor(target) {
  var safe = function(...args) {
    var instance = Object.create(target.prototype)
    target.call(instance, ...args)
    return instance
  }
  safe.prototype = target.prototype
  return safe
}

<strong i="10">@SafeCtor</strong>
class Snake {
  constructor(name) {
    this.name = name
  } 
}

var snake = Snake('python')
alert(snake instanceof Snake)

이 기능을 지원할 가능성이 적다는 것을 알고 있습니다. 하지만 이것은 structural 대 nominal 타이핑과 같은 유사한 이야기가 아님을 확인하고 싶습니다.

현재 확인은 대상에 할당할 수 있는 데코레이터에서 무언가를 반환해야 한다는 것입니다. 누락된 부분은 유형에 대한 추가 사항을 캡처하지 않는다는 것입니다. 나는 우리가 그것을 하는 방법에 대한 아이디어가 있다고 생각하지 않지만, 우리도 그것에 대해 실제로 생각한 적이 없습니다. 그래서 나는 그것이 정당한 제안이라고 생각하지만 그것을 구현하는 데 드는 비용이 매우 높을 수 있습니다.

이상적으로는 데코레이터가 반환하는 유형이 대상과 동일해야 한다고 생각합니다. 할당의 소스 또는 대상 위치에서 데코레이팅된 유형을 사용할지 여부는 알 수 없습니다.

나는 정말로 우리가 데코레이터 반환 유형과 타겟을 병합해야 한다고 생각하지만 일종의 믹스인(mixin)과 같습니다.

몇 가지 추가 기능 아이디어입니다. TypeScript 컴파일러 출력이 JavaScript이기 때문에 Xtend 와 같은 Java용 유사한 언어가 있습니다.

이 프로젝트에 대한 몇 가지 흥미로운 아이디어에 대해 배울 수 있습니다. 활성 주석을 찾습니다. "활성 주석을 사용하면 개발자가 라이브러리를 통해 Xtend 소스 코드를 Java 코드로 변환 프로세스에 참여할 수 있습니다."

데코레이터를 통해 TypeScript 출력을 제어하는 ​​것은 정말 좋은 기능입니다!

인터페이스용 데코레이터가 가능해야 합니다.

@shumy 문제는 인터페이스가 런타임에 존재하지 않으며 데코레이터가 런타임에만 실행된다는 것입니다.

반환 값과 관련하여 속성 데코레이터를 메서드 데코레이터와 다르게 취급하는 이유가 있습니까? (바벨은 그렇지 않습니다).

내 말은 데코레이터를 통해 속성에 대한 기능을 정의하려면 다음을 수행해야 합니다.

function decorator(proto, name) {
    Object.defineProperty(proto, name, { value: 42 });
}

class Foo {
    <strong i="7">@decorator</strong>
    a: number;
}

Babel은 설명자를 반환해야 하는 반면:

function decorator(proto, name) {
    return { value: 42 };
}

class Foo {
    <strong i="11">@decorator</strong>
    a;
}

이것은 Babel에서 사용될 라이브러리의 일부인 TypeScript에서 데코레이터를 작성하기 어렵게 만듭니다.

속성 데코레이터를 메서드 데코레이터와 동일하게 취급하고 데코레이터의 반환 값을 Object.defineProperty 를 통해 적용해야 한다고 제안합니다. 이것은 또한 메서드와 마찬가지로 단일 속성에 여러 데코레이터를 허용합니다.

현재 (Babel 호환성을 위한) 해결 방법은 속성을 설정하는 것 외에도 데코레이터에서 설명자를 반환하는 것이지만 불필요하게 낭비되는 것 같습니다.

function decorator(proto, name) {
    var d = { value: 42 };
    Object.defineProperty(proto, name, d);
    return d;
}

@mhegazy 위의 내 의견에 대한 통찰력이 있습니까?

@sccolbert TypeScript 에서 데이터 속성의 데코레이터에 대한 속성 설명자의 사용을 허용하지 않기로 선택했습니다. 설명자가 지정한 "값"이 인스턴스가 아닌 프로토타입에 설정된다는 사실 때문에 런타임에 문제가 발생할 수 있기 때문입니다. . 위의 예는 일반적으로 문제가 되지 않지만 다음을 고려하십시오.

function decorator(proto, name) {
  return { value: new Point(0, 0); }
}

class Foo {
  <strong i="7">@decorator</strong>
  p: Point;

  setX(x) { this.p.x = 1; }
}

let a = new Foo();
let b = new Foo();
console.log(a.p.x); // 0
b.setX(10);
console.log(a.p.x); // 10 (!)

생성자 동안 평가될 설명자의 "초기화" 속성을 지원하는 ES의 미래 버전에 대한 제안이 있습니다. 그러면 값이 프로토타입에 설정되는지 또는 인스턴스별로 할당되는지 여부를 제어할 수 있습니다.

지금은 주석의 예에 따라 Object.defineProperty 직접 호출하여 이 제한을 해결할 수 있습니다. 앞으로 이 제한을 완화할지 여부를 계속 조사할 것입니다.

@rbuckton 감사합니다! 같은 의미로 수렴하기 위해 Babel과 이야기하고 있습니까? 그게 가장 중요한 것 같아요.

특정 인스턴스에 대한 값을 지정하기 위해 데코레이터를 사용하는 것이 왜 유용한가요? 속성 이니셜라이저가 그런 용도가 아닌가요?

내 사용 사례는 예제보다 더 복잡합니다. 실제로 데코레이터를 사용하여 속성의 this 컨텍스트에 바인딩된 개체를 반환하는 getter를 정의하여 해당 개체의 메서드가 정의된 인스턴스에 액세스할 수 있도록 합니다.

당신은 모방로 생각할 수 있습니다 설명 프로토콜을 방법에게 접근 파이썬에서 bar 클래스에 정의 된 Foo 인스턴스를 통해 foo (즉, foo.bar )이를 호출 __get__ 반환하는 함수의 방법 BoundMethod . 해당 개체가 호출되면 기본 함수가 self 를 첫 번째 인수로 사용하여 호출되며 이 경우 foo 입니다. 자바 스크립트는 우리가 주변에 통과해야 이유는이 개념이없는 thisArg 하고 전화 function.bind 여기 저기를.

제 경우에는 메서드를 정의하는 것이 아니라 형식이 안전한 신호를 정의합니다. 데코레이터는 다음과 같습니다.
https://github.com/phosphorjs/phosphor-signaling/blob/1.0.1/src/index.ts#L144

속성에 액세스하면 소유자의 this 컨텍스트에 바인딩된 ISignal 구현이 반환됩니다. 이렇게 하면 신호가 정의된 인스턴스를 다시 참조할 수 있습니다.
https://github.com/phosphorjs/phosphor-signaling/blob/1.0.1/src/index.ts#L263

따라서 사실상 이 장황한 동등한 항목의 지름길로 데코레이터를 사용하고 있습니다.

class Foo {
  valueChanged: ISignal<number>;
}

defineSignal(Foo.prototype, 'valueChanged');

@rbuckton

ES3를 대상으로 할 때 데코레이터는 허용되지 않습니다.

왜요? ES3에서 __decorate 를 사용하는 것을 막는 어떤 것도 볼 수 없습니다.

ES3에서는 사용할 수 없는 속성 설명자를 사용합니다.
9월 4일 2015년 2:03 PM, "Koloto" [email protected] a écrit :

@rbuckton https://github.com/rbuckton

ES3를 대상으로 할 때 데코레이터는 허용되지 않습니다.

왜요? ES3에서 __decorate를 사용하는 것을 방해하는 어떤 것도 볼 수 없습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/2249#issuecomment -137717517
.

@sccolbert 속성 데코레이터보다 ES6 프록시를 사용하면 더

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

@DavidSouther 브라우저는 아직 프록시를 지원하지 않습니다 :(

@cybrown 예, 메서드 및 접근자에 대한 속성 설명자를 사용합니다. 일반 속성(접근자가 없는 필드)에서만 테스트했습니다. 그러나 속성(접근자 없음) 및 클래스에 대해 ES3에서 데코레이터를 허용할 수 있는 것 같습니다. 도움이 될 것입니다.

그리고 ES3를 대상으로 할 때 메소드에 가짜 속성 설명자를 사용할 수 있습니다. { writable: true, enumerable: true, configurable: true } 와 같은 것입니다. 그래서 ES3를 지원하지 않을 이유가 없습니다.

@sccolbert 알겠습니다 . 그것은 의미가 있습니다. 덧붙여서, TypeScript는 기능과 메소드에 대한 개선된 _this_ 타이핑 작업을 하고 있습니다. 여기에 도움이 되지 않을까 싶습니다. 타이핑이 문제가 아니라고 생각하지만 런타임 의미론입니다.

@JsonFreeman 개선된 _this_ 타이핑은 다른 사용 사례에서 흥미롭게 들립니다. 그것에 대해 더 많은 정보가 있습니까?

_this_ 타이핑에 대한 가장 발전된 토론은 #3694에 있다고 생각합니다.

건배!

오류 TS1207: 같은 이름의 여러 get/set 접근자에 데코레이터를 적용할 수 없습니다.

<strong i="6">@get</strong>
public get myValue():any{...}

<strong i="7">@set</strong>
public set myValue(value:any){...}

위의 코드는

<strong i="11">@get</strong>
<strong i="12">@set</strong>
public get myValue():any{...}

public set myValue(value:any){...}

Getter 및 setter는 Obect.defineProperty에 대한 한 번의 호출로 정의됩니다. 이것은 오히려 js의 단점, set과 get의 선언은 별개이지만 실제로는 동일한 속성 선언입니다. 컴파일러의 오류 검사는 사용자가 별도로 생각할 때 경고하는 것입니다. 데코레이터는 속성 설명자에 한 번만 적용됩니다.

컴파일러가 동일한 이름의 get 및 set을 감지하고 단일 Object.defineProperty로 결합할 수 있으므로 데코레이터도 결합하지 않는 이유가 궁금합니다.
또는 컴파일러에게 이들을 결합하고 오류를 던지는 대신 경고 메시지를 남기도록 지시하는 옵션 플래그일 수 있습니다.

감사 해요

@TakoLittle : 오늘 우리가 이것을 하지 않는 이유는 부분적으로 데코레이터가 구성되는 방식 때문입니다. 데코레이터는 수학 함수 구성과 동일한 원칙을 따릅니다. 여기서 (_f_ ∘ _g_)(_x_)는 _f_(_g_(_x_))로 구성됩니다. 같은 의미에서 다음과 같이 생각할 수 있습니다.

<strong i="7">@F</strong>
<strong i="8">@G</strong>
class X {}

대략:

F(G(X))

getter와 setter를 모두 장식하면 데코레이터의 구성이 무너집니다.

class C {
  <strong i="15">@F</strong>
  set X(value) {}

  <strong i="16">@G</strong>
  get X() {}
}

여기서 F 및 G 는 어떻게 구성되나요? 순전히 문서 순서를 기반으로 합니까(예: F(G(X)) )? getter 및 setter에 대한 각 데코레이터 세트는 개별적이며 문서 순서(예: G(F(X)) )로 실행됩니까? get 및 set 특정 순서를 암시합니까(즉, get 항상 set 앞에 있거나 그 반대임)? 사용자를 놀라게 하지 않는 가장 일관된 접근 방식을 100% 확신할 때까지 또는 ECMA-262 내에서 최소한 2단계 이상 수용 가능한 데코레이터 제안의 일부인 잘 문서화된 접근 방식이 있을 때까지는 다음을 수행하는 것이 가장 좋습니다. 여기서 더 제한적이고 오류가 발생하면 눈에 띄지 않고 런타임에 예기치 않은 동작이 발생할 수 있는 주요 변경 사항을 도입하지 않고 나중에 해당 제한을 완화할 수 있습니다.

@rbuckton 설명 너무 감사합니다
TS팀 수고하셨습니다!! ^^d

이에 대한 문서는 어디에 있습니까? 구현 커밋을 연결하시겠습니까?

감사 해요.

@mhegazy 사양의 최신 버전 구현 상태는 무엇입니까? 나는 거기에 약간의 변화가 있다는 것을 이해합니다.

이 문제는 제안의 원래 버전을 추적했습니다. 완료되었으므로 이 문제를 종료합니다. 사양에 대한 업데이트가 있는 경우 새로운 문제를 기록하고 모든 주요 변경 사항을 간략하게 설명합니다. 나는 그 제안이 지금 우리가 뛰어들 준비가 되었다고 생각하지 않습니다. 우리는 새로운 제안에 대해 @wycats 와 긴밀히 협력하고 있습니다.

@omeid , https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Decorators.md 에서 설명서를 찾을 수 있습니다.

@mhegazy 업데이트해주셔서 감사합니다. 계속 정보를 받고 싶습니다. 사양 업데이트에 대한 새 문제를 만들 때 알림을 받고 팔로우할 수 있도록 여기에 링크하십시오. Aurelia 커뮤니티는 데코레이터를 많이 사용하며 업데이트 시 TypeScript 및 Babel과 동기화하기를 원할 것입니다. 다시 한 번, TS 팀이 하고 있는 훌륭한 일에 감사드립니다!

기능 장식은 물론 필요합니다.
코드에서 다른 개체를 장식할 계획도 있습니까?