Typescript: 기능요청: 클래스 데코레이터 돌연변이

다음과 같은 방법에도 유용합니다.

class Foo {
  <strong i="6">@async</strong>
  bar(x: number) {
    return x || Promise.resolve(...);
  }
}

비동기 데코레이터는 반환 유형을 Promise<any> 로 변경해야 합니다.

@Gaelan , 이것이 바로 우리에게 필요한 것입니다! 믹스인을 사용하는 것이 자연스럽습니다.

class asPersistent {
  id: number;
  version: number;
  sync(): Promise<DriverResponse> { ... }
  ...
}

function PersistThrough<T>(driver: { new(): Driver }): (t: T) => T & asPersistent {
  return (target: T): T & asPersistent {
    Persistent.call(target.prototype, driver);
    return target;
  }
}

@PersistThrough(MyDBDriver)
Article extends TextNode {
  title: string;
}

var article = new Article();
article.title = 'blah';

article.sync() // Property 'sync' does not exist on type 'Article'

이것에 대해 +1. 이것이 구현하기 어렵고 데코레이터 돌연변이 의미론에 대한 합의에 도달하기가 더 어렵다는 것을 알고 있습니다.

+1

이것의 주요 이점이 유형 서명에 추가 멤버를 도입하는 것이라면 이미 인터페이스 병합을 통해 이를 수행할 수 있습니다.

interface Foo { foo(): number }
class Foo {
    bar() {
        return this.foo();
    }
}

Foo.prototype.foo = function() { return 10; }

new Foo().foo();

데코레이터가 클래스를 명령적으로 변경하기 위해 컴파일러가 호출해야 하는 실제 함수인 경우, 이것은 형식 안전 언어인 IMHO에서 수행하는 관용적인 작업처럼 보이지 않습니다.

@masaeedu 데코레이팅된 클래스에 정적 멤버를 추가하는 해결 방법을 알고 있습니까?

@davojan 물론입니다. 여기 있습니다:

class A { }
namespace A {
    export let foo = function() { console.log("foo"); }
}
A.foo();

메서드를 장식할 때 클래스에 _multiple_ 속성을 도입할 수 있는 것도 유용할 것입니다(예: getter에 대한 관련 setter를 생성하는 도우미 또는 이러한 라인을 따라 무언가).

connect 에 대한 react-redux 타이핑은 구성 요소를 취하고 redux를 통해 수신된 연결된 props를 포함하지 않는 props의 수정된 구성 요소를 반환하지만 TS는 connect 정의를 다음과 같이 인식하지 못하는 것 같습니다. 이 문제로 인해 데코레이터. 누구든지 해결 방법이 있습니까?

ClassDecorator 유형 정의가 변경되어야 한다고 생각합니다.

현재 declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void; 입니다. 로 변경될 수도 있습니다.

declare type MutatingClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;
declare type WrappingClassDecorator = <TFunction extends Function, TDecoratorFunction extends Function>(target: TFunction) => TDecoratorFunction;
declare type ClassDecorator = MutatingClassDecorator | WrappingClassDecorator;

분명히 네이밍은 형편없고 이런 종류의 일이 작동하는지 전혀 모릅니다(저는 그냥 Babel 앱을 타이프스크립트로 변환하려고 하고 있는데 이것을 치고 있습니다).

@joyt 문제의 놀이터 재구성을 제공할 수 있습니까? 나는 react-redux를 사용하지 않지만, 앞서 언급했듯이 유형의 모양에 대해 원하는 확장은 인터페이스 병합을 사용하여 선언할 수 있다고 생각합니다.

@masaeedu 는 여기에서 움직이는 부품의 기본 분류입니다.

기본적으로 데코레이터는 React 구성 요소에 많은 소품을 제공하므로 데코레이터의 일반 유형은 상위 집합이 아니라 장식된 구성 요소의 하위 집합입니다.

이것이 도움이 되는지 확실하지 않지만 실행 가능한 유형을 보여주기 위해 실행할 수 없는 샘플을 함께 만들려고 했습니다.

// React types
class Component<TProps> {
    props: TProps
}
class ComponentClass<TProps> {
}
interface ComponentDecorator<TOriginalProps, TOwnProps> {
(component: ComponentClass<TOriginalProps>): ComponentClass<TOwnProps>;
}

// Redux types
interface MapStateToProps<TStateProps, TOwnProps> {
    (state: any, ownProps?: TOwnProps): TStateProps;
}

// Fake react create class
function createClass(component: any, props: any): any {
}

// Connect wraps the decorated component, providing a bunch of the properies
// So we want to return a ComponentDecorator which exposes LESS than
// the original component
function connect<TStateProps, TOwnProps>(
    mapStateToProps: MapStateToProps<TStateProps, TOwnProps>
): ComponentDecorator<TStateProps, TOwnProps> {
    return (ComponentClass) => {
        let mappedState = mapStateToProps({
            bar: 'bar value'
        })
        class Wrapped {
            render() {
                return createClass(ComponentClass, mappedState)
            }
        }

        return Wrapped
    }
}


// App Types
interface AllProps {
    foo: string
    bar: string
}

interface OwnProps {
    bar: string
}

// This does not work...
// @connect<AllProps, OwnProps>(state => state.foo)
// export default class MyComponent extends Component<AllProps> {
// }

// This does
class MyComponent extends Component<AllProps> {
}
export default connect<AllProps, OwnProps>(state => state.foo)(MyComponent)
//The type exported should be ComponentClass<OwnProps>,
// currently the decorator means we have to export ComponentClass<AllProps>

전체 작업 예제를 원하면 https://github.com/jaysoo/todomvc-redux-react-typescript 또는 다른 샘플 react/redux/typescript 프로젝트를 풀다운하는 것이 좋습니다.

https://github.com/wycats/javascript-decorators#class -declaration에 따르면 제안된 declare type WrappingClassDecorator = <TFunction extends Function, TDecoratorFunction extends Function>(target: TFunction) => TDecoratorFunction; 이 유효하지 않다는 것을 이해합니다.

사양은 다음과 같이 말합니다.

@F("color")
<strong i="6">@G</strong>
class Foo {
}

번역:

var Foo = (function () {
  class Foo {
  }

  Foo = F("color")(Foo = G(Foo) || Foo) || Foo;
  return Foo;
})();

따라서 내가 올바르게 이해했다면 다음이 사실이어야 합니다.

declare function F<T>(target: T): void;

<strong i="13">@F</strong>
class Foo {}

let a: Foo = new Foo(); // valid

class X {}
declare function F<T>(target: T): X;

<strong i="16">@F</strong>
class Foo {}

let a: X = new Foo(); // valid
let b: Foo = new Foo(); // INVALID

declare function F<T>(target: T): void;
declare function G<T>(target: T): void;

<strong i="19">@F</strong>
<strong i="20">@G</strong>
class Foo {}

let a: Foo = new Foo(); // valid

class X {}
declare function F<T>(target: T): void;
declare function G<T>(target: T): X;

<strong i="23">@F</strong>
<strong i="24">@G</strong>
class Foo {}

<strong i="25">@G</strong>
class Bar {}

<strong i="26">@F</strong>
class Baz {}

let a: Foo = new Foo(); // valid
let b: X = new Foo(); // INVALID
let c: X = new Bar(); // valid
let d: Bar = new Bar(); // INVALID
let e: Baz = new Baz(); // valid

class X {}
declare function F<T>(target: T): X;
declare function G<T>(target: T): void;

<strong i="29">@F</strong>
<strong i="30">@G</strong>
class Foo {}

<strong i="31">@G</strong>
class Bar {}

<strong i="32">@F</strong>
class Baz {}

let a: X = new Foo(); // valid
let b: Bar = new Bar(); // valid
let c: X = new Baz(); // valid
let d: Baz = new Baz(); // INVALID

@blai

귀하의 예:

class X {}
declare function F<T>(target: T): X;

<strong i="9">@F</strong>
class Foo {}

let a: X = new Foo(); // valid
let b: Foo = new Foo(); // INVALID

F X ( X 의 인스턴스가 아님)를 준수하는 클래스를 반환한다는 것을 의미한다고 가정합니다. 예:

declare function F<T>(target: T): typeof X;

이 경우 주장은 다음과 같아야 합니다.

let a: X = new Foo(); // valid
let b: Foo = new Foo(); // valid

Foo let 는 데코레이터에 의해 변경되었습니다. 원래 Foo 에 더 이상 연결할 수 없습니다. 다음과 효과적으로 동일합니다.

let Foo = F(class Foo {});

@nevir 네, 맞습니다. 설명해주셔서 감사합니다.

참고로, 돌연변이된 클래스 유형을 무효화하는 검사를 끄는 것은 비교적 쉬운 일인 것 같습니다.

diff --git a/src/compiler/checker.ts b/src/compiler/checker.ts
index 06591a7..2320aff 100644
--- a/src/compiler/checker.ts
+++ b/src/compiler/checker.ts
@@ -11584,10 +11584,6 @@ namespace ts {
           */
         function getDiagnosticHeadMessageForDecoratorResolution(node: Decorator) {
             switch (node.parent.kind) {
-                case SyntaxKind.ClassDeclaration:
-                case SyntaxKind.ClassExpression:
-                    return Diagnostics.Unable_to_resolve_signature_of_class_decorator_when_called_as_an_expression;
-
                 case SyntaxKind.Parameter:
                     return Diagnostics.Unable_to_resolve_signature_of_parameter_decorator_when_called_as_an_expression;
         }

         /** Check a decorator */
        function checkDecorator(node: Decorator): void {
             const signature = getResolvedSignature(node);
             const returnType = getReturnTypeOfSignature(signature);
             if (returnType.flags & TypeFlags.Any) {
@@ -14295,9 +14291,7 @@ namespace ts {
             let errorInfo: DiagnosticMessageChain;
             switch (node.parent.kind) {
                 case SyntaxKind.ClassDeclaration:
-                    const classSymbol = getSymbolOfNode(node.parent);
-                    const classConstructorType = getTypeOfSymbol(classSymbol);
-                    expectedReturnType = getUnionType([classConstructorType, voidType]);
+                    expectedReturnType = returnType;
                     break;

                 case SyntaxKind.Parameter:
         }

그러나 나는 컴파일러가 돌연변이된 클래스의 올바른 유형 정의를 출력하도록 할 만큼 지식이 없습니다. 다음 테스트가 있습니다.

테스트/케이스/적합성/데코레이터/클래스/decoratorOnClass10.ts

// <strong i="10">@target</strong>:es5
// <strong i="11">@experimentaldecorators</strong>: true
class X {}
class Y {}

declare function dec1<T>(target: T): T | typeof X;
declare function dec2<T>(target: T): typeof Y;

<strong i="12">@dec1</strong>
<strong i="13">@dec2</strong>
export default class C {
}

var c1: X | Y = new C();
var c2: X = new C();
var c3: Y = new C();

test/baselines/local/decoratorOnClass10.types를 생성합니다.

=== tests/cases/conformance/decorators/class/decoratorOnClass10.ts ===
class X {}
>X : X

class Y {}
>Y : Y

declare function dec1<T>(target: T): T | typeof X;
>dec1 : <T>(target: T) => T | typeof X
>T : T
>target : T
>T : T
>T : T
>X : typeof X

declare function dec2<T>(target: T): typeof Y;
>dec2 : <T>(target: T) => typeof Y
>T : T
>target : T
>T : T
>Y : typeof Y

<strong i="17">@dec1</strong>
>dec1 : <T>(target: T) => T | typeof X

<strong i="18">@dec2</strong>
>dec2 : <T>(target: T) => typeof Y

export default class C {
>C : C
}

var c1: X | Y = new C();
>c1 : X | Y
>X : X
>Y : Y
>new C() : C
>C : typeof C

var c2: X = new C();
>c2 : X
>X : X
>new C() : C
>C : typeof C

var c3: Y = new C();
>c3 : Y
>Y : Y
>new C() : C
>C : typeof C

나는 기대하고 있었다
>C: typeof C 는 >C: typeof X | typeof Y 가 됩니다.

이 기능에 대한 사례 연구로 react-redux의 connect 에 관심이 있는 사람들을 위해 한 곳에서 문제를 추적하기 위해 https://github.com/DefinitelyTyped/DefinitelyTyped/issues/9951 을 제출했습니다.

나는 이 문제에 대한 모든 댓글을 읽었고 데코레이터의 서명이 실제로 래핑된 클래스로 무엇을 할 수 있는지 보여주지 않는다는 아이디어를 얻었습니다.

다음을 고려하십시오.

function decorator(target) {
    target.prototype.someNewMethod = function() { ... };
    return new Wrapper(target);
}

다음과 같이 입력해야 합니다.
declare function decorator<T>(target: T): Wrapper<T>;

그러나 이 서명은 데코레이터가 대상의 프로토타입에 새로운 것을 추가했음을 알려주지 않습니다.

반면에 이것은 데코레이터가 실제로 래퍼를 반환했다는 사실을 알려주지 않습니다.
declare function decorator<T>(target: T): T & { someMethod: () => void };

이것에 대한 소식이 있습니까? 이것은 메타프로그래밍에 매우 강력할 것입니다!

이 문제에 대한 더 간단한 접근 방식은 어떻습니까? 데코레이팅된 클래스의 경우 구문 설탕으로 클래스 이름을 데코레이터 반환 값에 바인딩합니다.

declare function Blah<T>(target: T): T & {foo: number}

<strong i="6">@Blah</strong>
class Foo {
    bar() {
        return this.foo; // Property 'foo' does not exist on type 'Foo'
    }
}

// is desugared to
const Foo = Blah(class Foo {
  // this.foo is not available here
})

new Foo.foo // foo is available here.

구현 측면에서 이것은 데코레이팅된 클래스에 대한 하나의 합성 기호를 도입합니다. 그리고 원래 클래스 이름은 클래스 본문 범위에만 바인딩됩니다.

@HerringtonDarkholme 원하는 표현력을 최대한 제공할 수 있는 실용적이고 실용적인 접근 방식이라고 생각합니다. 좋은 아이디어!

이건 언젠가 꼭 보고싶다

저는 종종 Angular 2 또는 Aurelia에 대한 클래스를 작성합니다. 다음과 같습니다.

import {Http} from 'aurelia-fetch-client';
import {User} from 'models';

// accesses backend routes for 'api/user'
<strong i="9">@autoinject</strong> export default class UserService {
  constructor(readonly http : Http) { }

  readonly resourceUrl = 'api/users';

  async get(id: number) {
    const response = await this.http.fetch(this.resourceUrl);
    const user = await response.json() as User;
    return user;
  }

  async post(id: number, model: { [K in keyof User]?: User[K] }) {
    const response = await this.http.post(`${this.resourceUrl}/`${id}`, model);
    return await response.json();
  }
}

내가 쓰고 싶은 것은 다음과 같다.
데코레이터/api-client.ts

import {Http} from 'aurelia-fetch-client';

export type Target = { name; new (...args): { http: Http }};

export default function apiClient<T extends { id: string }>(resourceUrl: string) {
  return (target: Target)  => {
    type AugmentedTarget = Target & { get(id: number): Promise<T>, post(id, model: Partial<T>) };
    const t = target as AugmentedTarget;
    t.prototype.get = async function (id: number) {
      const response = await this.http.fetch(resourceUrl);
      return await response.json() as T;
    }
  }
}

그런 다음 일반적으로 다음과 같이 적용할 수 있습니다.

import {Http} from 'aurelia-fetch-client';
import apiClient from ./decorators/api-client
import {User} from 'models';

@apiClient<User>('api/users') export default class UserService {
  constructor(readonly http : Http) { }
}

유형 안전성의 손실 없이. 이것은 깨끗하고 표현력이 풍부한 코드를 작성하는 데 도움이 될 것입니다.

이 문제를 되살리십시오.

이제 #13743이 나오고 믹스인 지원이 언어로 제공되므로 이것은 매우 유용한 기능입니다.

@HerringtonDarkholme 은 이 경우에 덜 적합하지만 데코레이터의 반환 유형을 선언해야 하는 일부 동적 기능이 느슨해집니다...

@ahejlsberg , @mhegazy 이것이 가능하다고 생각하십니까?

아직 확실하지 않은 또 다른 사용 시나리오가 있지만 이 대화에서 다루지만 아마도 같은 범주에 속할 것입니다.

메소드의 유형을 완전히 변경하는 메소드 데코레이터를 구현하고 싶습니다(반환 유형이나 매개변수가 아니라 전체 함수). 예

type AsyncTask<Method extends Function> = {
    isRunning(): boolean;
} & Method;

// Decorator definition...
function asyncTask(target, methodName, descriptor) {
    ...
}

class Order {
    <strong i="7">@asyncTask</strong>
    async save(): Promise<void> {
        // Performs an async task and returns a promise
        ...
    }
}

const order = new Order();

order.save();
order.save.isRunning(); // Returns true

JavaScript에서는 완전히 가능하지만 분명히 문제는 아니지만 TypeScript에서는 데코레이팅된 메서드의 유형을 () => Promise<void> 에서 AsyncTask<() => Promise<void>> 로 변경하기 위해 asyncTask 데코레이터가 필요합니다.

이것이 지금은 불가능하고 아마도 이 문제의 범주에 속한다고 확신합니까?

@codeandcats 귀하의 예는 제가 여기에 있는 것과 똑같은 사용 사례입니다!

@ohjames 안녕하세요. 실례합니다. 예시를 더듬는 데 문제가 있습니다. 놀이터에서와 같이 작동하는 것으로 다시 작성할 수 있는 기회가 있습니까?

이에 대한 진전이 있습니까? 나는 이 문제를 모르고 하루 종일 이것을 머리 속에 가지고 있었고 컴파일러가 그것을 선택하지 않는다는 것을 알아내기 위해 그것을 구현하러 갔다. 더 나은 로깅 솔루션을 사용할 수 있는 프로젝트가 있으므로 나중에 다음과 같은 데코레이터를 통해 클래스에 첨부할 본격적인 로거로 확장하기 위해 빠른 싱글톤을 작성했습니다.

<strong i="6">@loggable</strong>
class Foo { }

필요한 코드를 작성했습니다.

type Loggable<T> = T & { logger: Logger };

function loggable<T extends Function>(target: T): Loggable<T>
{
    Object.defineProperty(target.prototype, 'logger',
        { value: Logger.instance() });
    return <Loggable<T>> target;
}

그리고 logger 속성은 런타임에 확실히 존재하지만 유감스럽게도 컴파일러에 의해 선택되지 않습니다.

특히 이와 같은 런타임 구성은 컴파일 타임에 제대로 표시될 수 있어야 하기 때문에 이 문제에 대한 해결 방법을 보고 싶습니다.

나는 지금 당장 나를 얻기 위해 속성 데코레이터에 정착했습니다.

function logger<T>(target: T, key: string): void
{
    Object.defineProperty(target, 'logger',
        { value: Logger.instance() });
}

다음과 같은 클래스에 연결

class Foo {
    <strong i="19">@logger</strong> private logger: Logger;
    ...

그러나 이것은 단순한 @loggable 클래스 데코레이터보다 로거를 활용하는 클래스당 훨씬 더 많은 상용구입니다. (this as Loggable<this>).logger 와 같은 형식 변환이 가능하다고 생각하지만 이것은 특히 몇 번 수행한 후에는 이상적이지 않습니다. 그것은 매우 빨리 지겨워질 것입니다.

https://github.com/jeffijoe/mobx-task 데코레이터를 사용할 수 없기 때문에 전체 앱에 대해 TS를 수행해야 했습니다. 이 문제가 곧 해결되기를 바랍니다. 😄

데코레이터와 TypeScript가 일급 시민으로 취급되는 Angular 2 생태계에서는 매우 짜증납니다. 그러나 데코레이터로 속성을 추가하려고 하는 순간 TypeScript 컴파일러는 아니오라고 말합니다. Angular 2 팀이 이 문제에 약간의 관심을 보일 것이라고 생각했습니다.

@zajrik TS 2.2 이후 적절한 타이핑이 지원되는 클래스 믹스인으로 원하는 것을 달성할 수 있습니다.

다음과 같이 Loggable 믹스인을 정의합니다.

type Constructor<T> = new(...args: any[]) => T;

interface Logger {}

// You don't strictly need this interface, type inference will determine the shape of Loggable,
// you only need it if you want to refer to Loggable in a type position.
interface Loggable {
  logger: Logger;
}

function Loggable<T extends Constructor<object>>(superclass: T) {
  return class extends superclass {
    logger: Logger;
  };
}

그런 다음 몇 가지 방법으로 사용할 수 있습니다. 클래스 선언의 extends 절에서:

class Foo {
  superProperty: string;
}

class LoggableFoo extends Loggable(Foo) {
  subProperty: number;
}

TS는 LoggableFoo superProperty , logger 및 subProperty 가 있다는 것을 알고 있습니다.

const o = new LoggableFoo();
o.superProperty; // string
o.logger; // Logger
o.subProperty; // number

믹스인을 사용하려는 구체적인 클래스를 반환하는 표현식으로 사용할 수도 있습니다.

const LoggableFoo = Loggable(Foo);

또한 클래스 믹스인을 데코레이터로 사용할 수 _수_ 있지만, 약간 다른 의미가 있습니다. 주로 클래스가 클래스를 서브클래싱하도록 허용하기 보다는 클래스를 서브클래스로 만드는 것입니다.

클래스 믹스인은 데코레이터(IMO)에 비해 몇 가지 장점이 있습니다.

1. 그들은 새로운 수퍼 클래스를 생성하여 적용한 클래스가 이를 재정의하는 변경 사항을 갖도록 합니다.
2. TypeScript의 추가 기능 없이 지금 입력 확인
3. 유형 유추와 잘 작동합니다. mixin 함수의 반환 값을 입력할 필요가 없습니다.
4. 그것들은 정적 분석, 특히 jump-to-definition과 잘 작동합니다 logger 구현으로 점프하면 인터페이스가 아닌 믹스인 _구현_으로 이동합니다.

@justinfagnani 믹스인을 고려하지도 않았는데 감사합니다. 오늘 밤에 Loggable 믹스인을 작성하여 Logger 첨부 구문을 좀 더 멋지게 만들겠습니다. extends Mixin(SuperClass) 경로는 TS 2.2 릴리스 이후 지금까지 믹스인을 사용한 방법이므로 선호합니다.

그러나 나는 믹스인보다 데코레이터 구문이라는 아이디어를 선호하므로 이 특정 문제에 대해 약간의 해결책이 있기를 여전히 희망합니다. 내 생각에 데코레이터를 사용하여 상용구 없는 믹스인을 만들 수 있다는 것은 코드를 깔끔하게 정리하는 데 큰 도움이 될 것입니다.

@zajrik 제안이 도움이 되어서 기쁩니다.

나는 여전히 믹스인이 데코레이터보다 더 많은 상용구를 가지고 있다는 것을 이해하지 못합니다. 문법적 가중치는 거의 동일합니다.

클래스 믹신:

class LoggableFoo extends Loggable(Foo) {}

대 데코레이터:

<strong i="12">@Loggable</strong>
class LoggableFoo extends Foo {}

제 생각에는 믹스인이 그 의도에 대해 훨씬 더 명확합니다. 슈퍼클래스를 생성하고 슈퍼클래스가 클래스의 멤버를 정의하므로 믹스인도 멤버를 정의하고 있을 것입니다.

데코레이터는 멤버를 정의하거나 정의하지 않는다고 가정할 수 없는 많은 일에 사용됩니다. 단순히 클래스를 등록하거나 일부 메타데이터를 연결하는 것일 수 있습니다.

공정하게 말하면 @zajrik 이 원하는 것은 다음과 같습니다.

<strong i="7">@loggable</strong>
class Foo { }

이것은 부인할 수 없지만 약간이라도 상용구가 적습니다.

즉, 나는 mixin 솔루션을 좋아합니다. 믹스인이 중요하다는 사실을 계속 잊고 있습니다.

현재 클래스에 속성을 추가하는 것에만 관심이 있다면 믹스인은 기본적으로 한 가지 심각한 문제가 있는 데코레이터와 동일합니다... 클래스에 아직 슈퍼클래스가 없으면 이를 사용하기 위해 빈 슈퍼클래스를 만들어야 합니다. 또한 구문은 일반적으로 더 무거워 보입니다. 또한 매개변수 믹스인이 지원되는지 여부도 명확하지 않습니다( extends Mixin(Class, { ... }) 허용).

이유 목록에서 @justinfagnani , 포인트 2-4는 실제로 믹스인의 장점이 아니라 TypeScript의 결함입니다. JS 세계에서는 적용되지 않습니다.

OP 문제에 대한 믹스인 기반 솔루션에는 프로토타입 체인에 두 개의 클래스를 추가하는 것이 포함되며 그 중 하나는 쓸모가 없다는 것을 우리 모두 분명히 해야 한다고 생각합니다. 이것은 믹스인 대 데코레이터의 의미론적 차이를 반영하지만, 믹스인은 부모 클래스 체인을 가로챌 기회를 제공합니다. 그러나 95%의 시간은 사람들이 하고 싶은 것이 아니라 이 수업을 꾸미고 싶어합니다. 믹스인은 용도가 제한적이지만 데코레이터 및 상위 클래스에 대한 대안으로 믹스인을 홍보하는 것은 의미상 부적절하다고 생각합니다.

믹스인은 기본적으로 한 가지 중요한 성가심으로 데코레이터와 동일합니다... 클래스에 아직 수퍼클래스가 없으면 이를 사용하기 위해 빈 수퍼클래스를 생성해야 합니다.

이것은 반드시 사실은 아닙니다.

function Mixin(superclass = Object) { ... }

class Foo extends Mixin() {}

또한 구문은 일반적으로 더 무거워 보입니다.

나는 이것이 어떻게 되는지 알지 못하므로 우리는 동의하지 않을 수 밖에 없습니다.

또한 매개변수 믹스인이 지원되는지 여부도 명확하지 않습니다(Mixin(Class, { ... }) 확장이 허용됨).

그들은 아주 많이 있습니다. 믹스인은 함수일 뿐입니다.

이유 목록에서 포인트 2-4는 실제로 믹스인의 장점이 아니라 TypeScript의 결함입니다. JS 세계에서는 적용되지 않습니다.

이것은 TypeScript 문제이므로 여기에 적용됩니다. JS 세계에서 데코레이터는 아직 실제로 존재하지 않습니다.

OP 문제에 대한 믹스인 기반 솔루션에는 프로토타입 체인에 두 개의 클래스를 추가하는 것이 포함되며 그 중 하나는 쓸모가 없다는 것을 우리 모두 분명히 해야 한다고 생각합니다.

2개는 어디서 구하시는지 모르겠네요. 패치를 하지 않는 한 데코레이터가 하는 것처럼 하나입니다. 그리고 어떤 프로토타입이 쓸모가 없습니까? mixin 응용 프로그램은 아마도 쓸모없는 속성/메소드를 추가할 것입니다.

이것은 믹스인 대 데코레이터의 의미론적 차이를 반영하지만, 믹스인은 부모 클래스 체인을 가로챌 기회를 제공합니다. 그러나 95%의 시간은 사람들이 하고 싶은 것이 아니라 이 수업을 꾸미고 싶어합니다.

이것이 사실인지 확신할 수 없습니다. 일반적으로 클래스를 정의할 때 상위 클래스 메서드를 재정의할 수 있는 기능과 함께 상속 계층의 맨 아래에 있을 것으로 예상합니다. 데코레이터는 super() 로 작동하지 않는 것을 포함하여 수많은 문제가 있는 클래스를 패치하거나 확장해야 합니다. 이 경우 데코레이트된 클래스는 확장을 재정의할 수 없습니다. 이것은 성능/디버깅 추적을 위해 클래스의 정의된 모든 메서드를 재정의하는 데코레이터와 같은 일부 경우에 유용할 수 있지만 일반적인 상속 모델과는 거리가 멉니다.

믹스인은 용도가 제한적이지만 데코레이터 및 상위 클래스에 대한 대안으로 믹스인을 홍보하는 것은 의미상 부적절하다고 생각합니다.

개발자가 프로토타입 체인에 멤버를 추가하려고 할 때 믹스인은 정확히 의미상 적절합니다. 누군가가 믹스인에 데코레이터를 사용하려는 것을 본 모든 경우에 클래스 믹스인을 사용하면 실제로 데코레이터에서 기대하는 의미 체계, 수퍼 호출이 있는 작업 속성으로 인해 더 많은 유연성을 사용하여 동일한 작업을 수행할 수 있습니다. 물론 그들은 지금 작동합니다.

믹스인은 사용 사례를 직접 다룰 때 부적절하지 않습니다.

개발자가 프로토타입 체인에 구성원을 추가하려는 경우

그것이 바로 제 요점입니다. OP는 프로토타입 체인에 아무 것도 추가하고 싶지 않습니다. 그는 단지 단일 클래스를 변경하기를 원하며 대부분 사람들이 데코레이터를 사용할 때 Object 이외의 상위 클래스도 갖지 않습니다. 그리고 어떤 이유로 Mixin(Object) 는 TypeScript에서 작동하지 않으므로 더미 빈 클래스를 추가해야 합니다. 이제 필요하지 않을 때 2의 프로토타입 체인(Object 제외)이 있습니다. 또한 프로토타입 체인에 새 클래스를 추가하는 데는 적지 않은 비용이 듭니다.

구문 비교 Mixin1(Mixin2(Mixin3(Object, { ... }), {... }), {...}) . 각 믹스인의 매개변수는 가능한 한 믹스인 클래스에서 멀리 떨어져 있습니다. 데코레이터 구문은 분명히 더 읽기 쉽습니다.

데코레이터 구문 자체는 유형 검사가 아니지만 일반 함수 호출을 사용하여 원하는 것을 얻을 수 있습니다.

class Logger { static instance() { return new Logger(); } }
type Loggable<T> = T & { logger: Logger };
function loggable<T, U>(target: { new (): T } & U): { new (): Loggable<T> } & U
{
    // ...
}

const Foo = loggable(class {
    x: string
});

let foo = new Foo();
foo.logger; // Logger
foo.x; // string

클래스를 const Foo = loggable(class { 로 선언해야 하는 것은 약간 짜증나지만 그 외에는 모두 작동합니다.

@ohjames (cc @justinfagnani) Object 와 같은 내장 기능을 확장할 때 주의해야 합니다(인스턴스에서 하위 클래스의 프로토타입을 강타하기 때문에): https://github.com/Microsoft/TypeScript/wiki/FAQ #왜 -extending -built-ins-like-error-array-and-map-work가 작동하지 않는지

@nevir 네, 저는 이미 TypeScript 2.2에서 기본 Object 매개변수와 함께 mixin을 사용 하라는 @justinfagnani 의 제안을 이미 시도했지만 tsc는 코드를 거부했습니다.

@ohjames 여전히 작동합니다. 기본 케이스의 프로토타입에 대해 주의해야 합니다(FAQ 항목 참조).

그러나 일반적으로 null 전달될 때 tslib.__extend 의 동작에 의존하는 것이 더 쉽습니다.

다음 반복 단계에서 이 문제에 집중할 계획이 있습니까? 이 기능의 이점은 많은 라이브러리에서 매우 높다는 것입니다.

방금 이 문제가 발생했습니다. 불필요한 코드를 많이 작성해야 합니다. 이 문제를 해결하는 것은 데코레이터 기반 프레임워크/라이브러리에 큰 도움이 될 것입니다.

@TomMarius 앞서 언급했듯이 데코레이터 함수로 래핑된 클래스는 이미 유형 검사를 제대로 수행하므로 @ 구문 설탕을 사용할 수 없습니다. 대신:

<strong i="8">@loggable</strong>
class Foo { }

다음을 수행하기만 하면 됩니다.

const Foo = loggable(class { });

클래스를 래핑하기 전에 여러 데코레이터 함수를 함께 구성할 수도 있습니다. 구문 설탕이 제대로 작동하도록 하는 것이 중요하지만 이것이 실제로 그렇게 큰 문제가 되어야 하는 것 같지는 않습니다.

@masaeedu 정말 문제는 외부가 아니라 내부 유형 지원입니다. 컴파일 오류 없이 클래스 자체에 데코레이터가 추가하는 속성을 사용할 수 있다는 것은 적어도 나에게는 원하는 결과입니다. 귀하가 제공한 예제는 Foo 에 기록 가능한 유형만 제공하지만 클래스 정의 자체에는 유형을 제공하지 않습니다.

@zajrik 내장 @ 구문을 사용하는 경우에도 데코레이터는 원래 클래스에서 새 클래스를 반환합니다. 분명히 JS는 순수성을 강요하지 않으므로 전달한 원래 클래스를 자유롭게 변경할 수 있지만 이는 데코레이터 개념의 관용적 사용과 일치하지 않습니다. 데코레이터를 통해 클래스 내부에 추가하는 기능을 긴밀하게 연결하는 경우 내부 속성일 수도 있습니다.

나중에 데코레이터를 통해 추가되는 내부적으로 API를 사용하는 클래스에 대한 사용 사례의 예를 제공할 수 있습니까?

위의 로거 예제는 데코레이팅된 클래스의 내부를 조작할 수 있는 일반적인 _want_의 좋은 예입니다. (그리고 Python과 같은 클래스 데코레이션이 있는 다른 언어에서 온 사람들에게 친숙합니다.)

즉, @justinfagnani 의 클래스 믹스인 제안 은 그 경우에 좋은 대안으로 보입니다.

클래스의 내부를 정의할 수 있기를 원하는 경우 이를 수행하는 구조화된 방법은 클래스를 패치하거나 새 하위 클래스를 정의하는 것이 아닙니다. 두 가지 모두 TypeScript가 클래스 컨텍스트에서 추론하는 데 어려움을 겪을 것입니다 하지만 클래스 자체에서 정의하거나 TypeScript가 추론할 수 있는 필요한 속성이 있는 새 슈퍼클래스를 만드는 것입니다.

데코레이터는 클래스나 대부분의 소비자가 볼 수 있는 방식으로 클래스의 모양을 변경해서는 안 됩니다. @masaeedu 바로 여기입니다.

당신이 말하는 것이 사실이지만 TypeScript는 깨끗한 코딩 관행을 시행하기 위해 존재하는 것이 아니라 JavaScript 코드를 올바르게 입력하기 위해 존재하며 이 경우 실패합니다.

@masaeedu @zajrik이 말한 것. 클래스에 속성을 추가한 다음 클래스에서 사용되는 "온라인 서비스"를 선언하는 데코레이터가 있습니다. 메타데이터가 누락되고 제약 조건이 적용되기 때문에 인터페이스를 서브클래싱하거나 구현하는 것은 옵션이 아닙니다(코드 중복을 방지하기 위해 노력하는 경우).

@TomMarius 내 요점은 올바른 유형 검사라는 것입니다. 클래스에 데코레이터 기능을 적용하면 클래스가 변경되지 않습니다. 새 클래스는 원래 클래스의 일부 변환을 통해 생성되며 이 새 클래스만 데코레이터 기능에 의해 도입된 API를 지원하도록 보장됩니다.

"메타데이터 누락 및 제약 조건 적용"이 무엇을 의미하는지 모르지만(구체적인 예가 도움이 될 수 있음) 클래스가 데코레이터가 도입한 API에 명시적으로 의존하는 경우 @justinfagnani 가 보여준 믹스인 패턴을 통해 직접 하위 클래스화해야 합니다. , 또는 생성자 등을 통해 주입하십시오. 데코레이터의 유용성은 수정 이 금지된 클래스가 해당 클래스를 사용하는 코드 의 이점을 위해 확장될 수 있다는 것입니다. 클래스를 직접 정의할 수 있는 경우 extends 를 사용하십시오.

@masaeedu 어떤 종류의 RPC 라이브러리를 개발 중이고 사용자가 비동기식 메서드만 작성하도록 하려는 경우 상속 기반 접근 방식을 사용하면 코드를 복제해야 합니다(또는 올바른 방법을 찾지 못했습니다). , 아마도 - 방법을 알고 있다면 알려주시면 기쁠 것입니다.

상속 기반 접근 방식
정의: export abstract class Service<T extends { [P in keyof T]: () => Promise<IResult>}> { protected someMethod(): Promise<void> { return Promise.reject(""); } }
사용법: export default class MyService extends Service<MyService> { async foo() { return this.someMethod(); } }

데코레이터 기반 접근 방식
정의: export function service<T>(target: { new (): T & { [P in keyof T]: () => Promise<IResult> } }) { target.someMethod = function () { return Promise.reject(""); }; return target; }
사용법: <strong i="17">@service</strong> export default class { async foo() { return this.someMethod(); } }

상속 기반 접근 예제에서 코드 중복을 명확하게 볼 수 있습니다. 저와 제 사용자는 클래스를 복사하여 붙여넣거나 "any"를 유형 매개변수로 사용하기 시작했을 때 유형 매개변수를 변경하는 것을 잊어버리고 라이브러리가 작동을 멈춘 적이 여러 번 있었습니다. 데코레이터 기반 접근 방식은 개발자에게 훨씬 더 친숙합니다.

그 후 상속 기반 접근 방식에는 또 다른 문제가 있습니다. 이제 리플렉션 메타데이터가 누락되어 service 데코레이터를 도입해야 하기 때문에 코드를 훨씬 더 복제해야 합니다. 사용법은 현재 <strong i="22">@service</strong> export default class MyService extends Service<MyService> { async foo() { return this.someMethod(); } } 이며 약간의 불편함이 아니라 그저 비우호적입니다.

의미상으로 클래스가 정의된 후에 수정이 수행되는 것이 사실이지만 장식되지 않은 클래스를 인스턴스화할 방법이 없으므로 때때로 부정확한 코드를 허용하는 것 외에는 클래스의 변형을 적절하게 지원하지 않을 이유가 없습니다(그러나 때로는 더 나은 선을 위해). JavaScript는 여전히 프로토타입에 기반하고 있으며 클래스 구문은 이를 덮기 위한 설탕일 뿐입니다. 프로토타입은 변경 가능하고 데코레이터에 의해 음소거될 수 있으며 올바르게 입력해야 합니다.

클래스에 데코레이터 기능을 적용하면 클래스가 변경되지 않습니다.

사실이 아닙니다. 클래스에 데코레이터 기능을 적용하면 어떤 식으로든 클래스가 변경될 수 있습니다. 당신이 그것을 좋아하든 그렇지 않든.

@TomMarius 당신은 여기에있는 주장과 완전히 관련이없는 일부 계약을 시행하기 위해 추론을 이용하려고합니다. 다음을 수행하면 됩니다.

function service<T>(target: { new (): T & {[P in keyof T]: () => Promise<any> } }) { return target };

// Does not type check
const MyWrongService = service(class {
    foo() { return ""; }
})

// Type checks
const MyRightService = service(class {
    async foo() { return ""; }
})

클래스 내부가 데코레이팅 기능을 인식할 필요는 전혀 없습니다.

@masaeedu 그것은 내 요점이 아니 었습니다. 서비스 데코레이터/서비스 클래스는 몇 가지 새로운 속성을 도입했으며 이러한 속성은 사용할 클래스에서 항상 사용할 수 있지만 유형 시스템은 이를 올바르게 반영하지 않습니다. 당신은 내가 그것을 위해 상속을 사용해야 한다고 말했고, 그래서 내가 왜 내가 할 수 없거나 원하지 않는지 보여주었습니다.

더 명확하게 예제를 편집했습니다.

@masaeedu 그건 그렇고, "데코레이터는 원래 클래스에서 새 클래스를 반환합니다"라는 문장은 올바르지 않습니다. 여기서 우리가 모두 보여준 모든 데코레이터는 변형되거나 직접 원래 클래스를 반환하며 결코 새로운 클래스를 반환하지 않습니다.

@TomMarius 귀하의 의견은 "사용자가 비동기식 메서드만 작성하도록 강제하는" 문제에 대해 언급했는데, 이는 제 의견에서 해결하려고 했던 문제입니다. 사용자가 예상하는 계약을 따랐는지 강제하는 것은 사용자의 코드가 라이브러리로 다시 전달될 때마다 수행되어야 하며 데코레이터가 클래스 내부에 제공된 유형 모양을 변경해야 하는지 여부에 대한 논의와 아무 관련이 없습니다. 사용자 코드에 API를 제공하는 직교 문제는 표준 상속 또는 구성 접근 방식으로 해결할 수 있습니다.

@ohjames 단순히 데코레이터를 적용한다고 해서 클래스가 바뀌는 것은 아닙니다. JS는 순도를 강요하지 않으므로 분명히 코드의 모든 명령문이 다른 것을 수정할 수 있지만 이것은 이 기능 논의와 관련이 없습니다. 기능이 구현된 후에도 TypeScript는 함수 본문 내에서 임의의 구조적 변경 사항을 추적하는 데 도움이 되지 않습니다.

@masaeedu 당신은 비트를 고르고 있지만 큰 그림을 말하는 것입니다. 이 스레드에 있는 내 모든 의견을 검토하십시오. 요점은 개별 문제가 아니라 동시에 발생하는 각 문제에 있습니다. 나는 상속 기반 접근 방식의 문제를 잘 설명했다고 생각합니다. 많은 코드 중복이 있습니다.

명확성을 위해 이것은 나에게 "깨끗한 코드"에 관한 것이 아닙니다. 문제는 실용성입니다. @foo 를 함수 응용 프로그램과 동일하게 취급하면 유형 시스템을 크게 변경할 필요가 없습니다. 반환 유형 에서 함수의 인수 에 유형 정보를 도입하려고 시도하는 웜의 깡통을 열면 동시에 유형 추론 및 TypeScript 유형 시스템의 여러 구석에서 발견되는 다른 모든 마법의 짐승과 상호 작용하는 것입니다. 이것은 과부하가 지금과 같은 방식으로 새로운 기능에 대한 큰 장애물이 될 것입니다.

@TomMarius 이 스레드의 첫 번째 의견은 관련이 없는 깨끗한 코드에 관한 것입니다. 다음 주석은 예제 코드를 제공한 이 온라인 서비스 개념에 대한 것입니다. 첫 번째 단락부터 네 번째 단락까지 주요 불만은 MyService extends Service<MyService> 를 사용하는 데 오류가 발생하기 쉽다는 것입니다. 나는 당신이 이것을 어떻게 다룰 수 있는지에 대한 예를 보여주려고 노력했습니다.

나는 그것을 다시 보았고 데코레이팅된 클래스의 멤버가 데코레이터를 알아야 하는 이유를 설명하는 그 예에서 아무것도 볼 수 없습니다. 표준 상속으로 수행할 수 없는 사용자에게 제공하는 이러한 새 속성은 무엇입니까? 나는 반성으로 작업하지 않았기 때문에 그것에 대해 대충 훑어본 적이 있습니다. 죄송합니다.

@masaeedu 나는 상속으로 그것을 달성할 수 있지만 상속으로 인해 나/내 사용자가 코드를 대량으로 복제해야 하므로 다른 방법을 원합니다. 그리고 저는 하지만 유형 시스템이 현실을 올바르게 반영할 수 없습니다.

요점은 service 가 <T>(target: T) => T & IService 로 선언된 올바른 유형의 <strong i="7">@service</strong> class X { } 가 X 가 아니라 X & IService ; 문제는 실제로는 클래스 내부에서도 사실이라는 것입니다. 의미상 사실이 아닐지라도 말입니다.

이 문제가 야기하는 또 다른 큰 고통은 각각 제약이 있는 일련의 데코레이터가 있을 때 유형 시스템이 대상이 장식된 클래스가 아니라 항상 원래 클래스라고 생각하므로 제약 조건이 쓸모가 없다고 생각한다는 것입니다.

상속으로 달성할 수 있지만 상속으로 인해 나/내 사용자가 코드를 대량으로 복제해야 하므로 다른 방법을 사용하고 싶습니다.

이해가 안되는 부분입니다. 사용자는 IService 를 구현해야 하고 TheirService implements IService 가 다른 계약 { [P in keyof blablablah] } $ 도 준수하는지 확인하고 아마도 { potato: Potato } 그들의 서비스에. 이 모든 것은 클래스 멤버가 @service 를 인식하지 않고도 쉽게 수행할 수 있습니다.

import { serviceDecorator, BaseService } from 'library';

// Right now
const MyService = serviceDecorator(class extends BaseService {
    async foo(): { return ""; }
})

const MyBrokenService1 = serviceDecorator(class extends BaseService {
    foo(): { return; } // Whoops, forgot async! Not assignable
});

const MyBrokenService2 = serviceDecorator(class { // Whoops, forgot to extend BaseService! Not assignable
    async foo(): { return; } 
});

// Once #4881 lands
<strong i="13">@serviceDecorator</strong>
class MyService extends BaseService {
    async foo(): { return ""; }
}

두 경우 모두 serviceDecorator this ~ foo 의 유형으로 제시해야만 달성할 수 있는 간결함의 거대한 승리는 없습니다. 더 중요한 것은, 이를 위한 균일한 타이핑 전략을 제안하는 방법은 무엇입니까? serviceDecorator 의 반환 유형은 장식하는 클래스의 유형을 기반으로 유추되며, 이제 데코레이터의 반환 유형으로 입력됩니다.

안녕하세요 @masaeedu , 간결함은 둘 이상일 때 특히 가치가 있습니다.

@Component({ /** component args **/})
@Authorized({/** roles **/)
<strong i="7">@HasUndoContext</strong>
class MyComponent  {
  // do stuff with undo context, component methods etc
}

그러나 이 해결 방법은 클래스 데코레이터의 대안일 뿐입니다. 메서드 데코레이터의 경우 현재 솔루션이 없으며 멋진 구현이 너무 많이 차단됩니다. 데코레이터는 2단계에서 제안 중입니다 - https://github.com/tc39/proposal-decorators . 그러나 구현이 훨씬 더 일찍 이루어진 경우가 많습니다. 특히 데코레이터는 이미 많은 프레임워크에서 사용되었고 매우 간단한 버전이 이미 babel/ts에 구현되어 있기 때문에 정말 중요한 중요한 벽돌 중 하나라고 생각합니다. 이 문제가 구현될 수 있다면 공식 릴리스까지 실험 상태를 잃지 않을 것입니다. 그러나 그것은 "실험적"입니다.

@pietschy 예, @ 구문 설탕이 유형 검사와 함께 제대로 작동하도록 하는 것이 좋습니다. 현재 함수 합성을 사용하여 합리적으로 유사한 간결성을 얻을 수 있습니다.

const decorator = compose(
    Component({ /** component args **/ }),
    Authorized({ /** roles **/ })
    HasUndoContext
);

const MyComponent = decorator(class {
});

앞의 논의는 데코레이터의 반환 유형이 this 유형으로 클래스 멤버에게 제공되는 일종의 역 타이핑을 수행하는 것이 좋은 아이디어인지 여부에 대한 것입니다.

안녕하세요 @masaeedu , 네, 토론의 맥락을 이해했습니다. 따라서 // do stuff with undo context, component methods etc 입니다. 건배

Mixins를 더 쉽게 만들어야 합니다.

typescript(javascript)는 다중 상속을 지원하지 않으므로 Mixins 또는 Traits를 사용해야 합니다.
그리고 지금은 특히 내가 무언가를 재구성할 때 많은 시간을 낭비하고 있습니다.
그리고 모든 곳에서 "빈 구현"이 있는 인터페이스를 복사하여 붙여넣어야 합니다. (#371)

--
나는 데코레이터의 반환 유형이 수업에 제시되어서는 안된다고 생각합니다.
왜냐하면: .... 흠. 어떻게 설명해야 할지 모르겠어, 내 영어 실력이 형편없어서 미안해... ( 🤔 액자 없이 사진이 존재할 수 있니? ) 이 직업은 interface 입니다.

여기에 내 +1을 추가합니다! 나는 그것이 곧 나오는 것을 보고 싶습니다.

@pietschy 클래스가 데코레이터에 의해 추가된 멤버에 종속되는 경우 그 반대가 아니라 데코레이터의 결과를 확장해야 합니다. 다음을 수행해야 합니다.

const decorator = compose(
    Component({ /** component args **/ }),
    Authorized({ /** roles **/ })
    HasUndoContext
);

class MyComponent extends decorator(class { }) {
    // do stuff with undo context, component methods etc
};

대안은 유형 시스템이 일종의 루프에서 작동하는 것입니다. 여기서 데코레이터 함수의 인수는 반환 유형에 의해 컨텍스트적으로 유형이 지정되고, 반환 유형에 의해 컨텍스트적으로 유형이 지정되는 인수에서 추론됩니다. 우리는 여전히 필요합니다. 이것이 어떻게 작동해야 하는지에 대한 구체적인 제안은 단지 구현을 기다리는 것이 아닙니다.

@masaeedu 안녕하세요. 데코레이터를 구성하고 기본 클래스에 적용해야 하는 이유가 무엇인지 혼란스럽습니다. 내가 이해하는 한 프로토타입은 사용자 랜드 코드가 실행될 때 이미 수정되었습니다. 예

function pressable<T extends {new(...args:any[]):{}}>(constructor:T) {
    return class extends constructor {
        pressMe() {
            console.log('how depressing');
        }
    }
}

<strong i="7">@pressable</strong>
class UserLandClass {
    constructor() {    
        this['pressMe'](); // this method exists, please let me use code completion.
    }
}

console.log(new UserLandClass());

따라서 데코레이터에 의해 정의된 메서드가 이미 존재하고 합법적으로 호출할 수 있는 경우 typescript가 이를 반영하면 좋을 것입니다.

해결 방법을 부과하지 않고 typescript가 이것을 반영하기를 원합니다. 다른 경우
데코레이터가 할 수 있고 모델링할 수 없는 일이라면 적어도
시나리오는 어떤 형태나 형태로 지원되었습니다.

이 스레드는 데코레이터 가 무엇을 해야 하는지, 어떻게 사용해야 하는지, 어떻게 사용하지 않아야 하는지 등에 대한 의견으로 가득 차 있습니다.

데코레이터 가 실제로 하는 일은 다음과 같습니다.

function addMethod(Class) : any {
    return class extends Class {
        hello(){}
    };
}

<strong i="13">@addMethod</strong>
class Foo{
    originalMethod(){}
}

esnext를 타겟팅하는 경우

var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};

function addMethod(Class) {
    return class extends Class {
        hello() {
        }
    };
}
let Foo = class Foo {
    originalMethod() { }
};
Foo = __decorate([
    addMethod
], Foo);

__decorate 는 각 데코레이터를 아래에서 위로 적용하고 각 데코레이터에는 완전히 새로운 클래스를 반환할 수 있는 옵션이 있습니다.

나는 유형 시스템이 이것을 지원하고 인정하는 것이 매우 까다로울 수 있다는 것을 이해하고, 이것을 지원하는 데 매우 시간이 걸릴 수 있다는 것을 이해하지만, 우리 모두가 이것을 시작한 위의 원래 코드 샘플에서 현재 동작에 동의하지 않을 수 있습니까? 스레드, 단순히 잘못된 것입니까?

데코레이터나 믹스인, 기능적 구성 등에 대한 개발자의 의견이 무엇이든 간에 이것은 꽤 분명한 버그인 것 같습니다.

이것이 향후 릴리스의 파이프라인에 있는지 정중하게 여쭤봐도 될까요?

TypeScript는 정말 놀랍고 마음에 듭니다. 그러나 이것은 단순히 부서진 몇 안 되는(유일한?) 조각 중 하나인 것 같으며, 수정되기를 고대하고 있습니다. :)

@arackaf 데코레이터 가 실제로 무엇을 하는지 잘 이해하고 있으며 TypeScript가 이미 데코레이터를 지원하는 유형에 대해 신경 쓰지 않는다고 가정합니다. 이 문제의 전체 토론은 데코레이팅된 클래스가 유형 시스템에서 어떻게 표시되어야 하는지에 대한 것입니다.

나는 new Foo().foo 유형 오류가 버그이며 쉽게 고칠 수 있다는 데 동의합니다. return this.foo; 유형 오류가 버그라는 데 동의하지 않습니다. 이 문제에서 아직까지 아무도 지정하지 않은 유형 시스템의 기능을 요청하고 있는 것입니다. this 유형이 포함하는 클래스에 적용된 데코레이터에 의해 변환되어야 하는 일부 메커니즘을 염두에 둔 경우 이 메커니즘을 명시적으로 제안해야 합니다 .

거의 모든 경우에 데코레이터의 반환 유형을 사용하여 변환을 제안한 바로 그 유형에서 데코레이터의 반환 유형이 유추되기 때문에 이러한 메커니즘은 예상만큼 간단하지 않습니다. 데코레이터 addMethod 가 new () => T 유형의 클래스를 사용하여 new() => T & { hello(): void } 를 생성하는 경우 T 가 T & { hello(): void } 여야 한다고 제안하는 것은 이치에 맞지 않습니다. super.hello 를 참조하는 것이 유효한가요?

이것은 내가 데코레이터의 본문에서 return class extends ClassIWasPassed { ... } 를 수행하는 것으로 제한되지 않기 때문에 특히 적절합니다. 내가 원하는 것은 무엇이든 할 수 있습니다. 빼기 유형, 매핑된 유형, 공용체, 모두 공정한 게임입니다. 모든 결과 유형은 제안하는 이 추론 루프와 잘 작동해야 합니다. 문제를 설명하기 위해 이 예에서 어떤 일이 발생해야 하는지 알려주십시오.

type Constructor<T> = new (...args: any[]) => T
type Greeter = { hello(): string }

function logger<T extends Constructor<Greeter>>(Class: T) {
    return class {
        hello() {
            console.log(new Class().hello()) // Do I get a type error here? After all, the signature of Class is { hello: () => void }
        } 
    };
}

// Or should I get the error here? Foo does not conform to { hello(): string }
<strong i="22">@logger</strong>
class Foo {
    hello() { return "foo"; }
}

문제가 "어렵다"고 그냥 넘겨줄 수는 없습니다. 누군가 실제로 이것이 어떻게 작동해야 하는지 제안해야 합니다.

오류가 아닙니다. Greeter를 준수하는 Logger 클래스를 전달하고 있습니다. 그러나 Foo는 데코레이터에 의해 완전히 다른 것으로 변형되어 더 이상 Greeter를 확장하지 않습니다. 따라서 로거 데코레이터가 Foo를 Greeter로 취급하는 것은 유효해야 하지만 Foo는 데코레이터에 의해 완전히 다른 것에 재할당되기 때문에 다른 사람에게는 유효하지 않습니다.

나는 이것을 구현 하는 것이 지독하게 어려울 것이라고 확신합니다. 이 스레드의 맨 위에 나열된 것과 같은 일반적인 경우에 대해 합리적인 하위 집합이 가능한가요?

@아라카프

그러나 Foo는 데코레이터에 의해 완전히 다른 것으로 변경됩니다.

Foo 가 무엇인지에 대한 정확한 정의는 없습니다. 우리의 전체 경합 포인트는 Foo 의 멤버가 액세스할 수 있어야 하는지(그러므로 공개 API의 일부로 반환해야 하는지) 데코레이터가 this 에서 멤버를 도입했는지 여부입니다. Foo 는 데코레이터가 반환하는 것으로 정의되고 데코레이터가 반환하는 것은 Foo 가 무엇인지에 의해 정의됩니다. 그들은 떼려야 뗄 수 없이 연결되어 있습니다.

나는 이것을 구현하는 것이 매우 어려울 것이라고 확신합니다.

기능이 어떻게 작동해야 하는지에 대한 확실한 제안이 없는 상황에서 구현 복잡성에 대해 이야기하는 것은 아직 시기상조입니다. 이런 말을 해서 죄송합니다. 하지만 "이와 같은 일련의 데코레이터를 해당 클래스에 적용하면 this 에 어떤 일이 발생하는지"에 대한 구체적인 메커니즘을 제안할 사람이 정말로 필요합니다. 그런 다음 다른 부분에 다양한 TypeScript 개념을 연결하고 결과가 의미가 있는지 확인할 수 있습니다. 그래야만 구현 복잡성을 논의하는 것이 합리적입니다.

위에 붙여 넣은 현재 데코레이터 출력이 사양을 준수하지 않습니까? 내가 본 것에서 비롯된 것이라고 생각했다.

그렇다고 가정하면 Foo는 모든 단계에서 상당히 정확한 의미를 가지고 있습니다. 나는 TS가 마지막 데코레이터가 반환하는 것을 기반으로 this (Foo 메서드 내부 및 Foo 인스턴스에서)를 사용할 수 있도록 허용할 것으로 예상합니다. 기능을 충분히 분석할 수 없습니다.

@arackaf "단계"가 없습니다. 우리는 주어진 불변 코드 조각에 대한 this 의 최종 유형에만 관심이 있습니다. this 의 유형이 X 데코레이터 함수 f1...fn 로 장식된 X 의 멤버에 대해 어떤 유형이 되어야 하는지를 최소한 높은 수준에서 설명해야 합니다. X 및 f1...fn 의 유형 서명 중. 원하는 만큼 프로세스 단계를 수행할 수 있습니다. 지금까지 아무도 이것을 하지 않았습니다. 나는 사람들이 데코레이터의 반환 유형이 this 의 유형으로 표시되어야 한다는 것을 의미한다고 추측해 왔지만 내가 아는 한 나는 완전히 틀릴 수 있습니다.

당신의 제안이 변환된 출력의 값에 어떤 일이 일어나는지를 기계적으로 반영하도록 하는 것이라면 당신은 당신이 제안하는 것 대신에 내가 제안하는 것으로 끝납니다: 예를 들어 new Foo().hello() 는 괜찮지만 this.hello() 은(는) 아닙니다. 이 예제의 어떤 시점에서도 장식하고 있는 원래 클래스는 hello 메서드를 얻지 못합니다. __decorate([addMethod], Foo) ( Foo 에 할당됨)의 결과에만 hello 메서드가 있습니다.

나는 사람들이 데코레이터의 반환 유형이 이것의 유형으로 표시되어야 함을 의미한다고 추측했습니다.

아, 죄송합니다. 네, 맞습니다. 정확히 그. 마침표. 그것이 데코레이터가 하는 일이기 때문입니다. 줄의 마지막 데코레이터가 완전히 새로운 클래스를 반환하면 그것이 바로 Foo입니다.

다시 말해:

<strong i="9">@c</strong>
<strong i="10">@b</strong>
<strong i="11">@a</strong>
class Foo { 
}

Foo는 c 가 말하는 세상 무엇이든 됩니다. c 가 any 를 반환하는 함수라면 저는 잘 모르겠습니다. 아마도 원래 Foo 로 대체될 것입니다. 그것은 합리적이고 이전 버전과 호환되는 접근 방식처럼 보입니다.

하지만 c 가 새로운 유형 X $ 을 반환하면 Foo가 이를 존중할 것으로 기대합니다.

내가 뭔가를 놓치고 있습니까?

추가로 명확히 하는 경우

class X { 
    hello() {}
    world() {}
}
function c(cl : any) : X {  // or should it be typeof X ?????
    //...
}

<strong i="25">@c</strong>
<strong i="26">@b</strong>
<strong i="27">@a</strong>
class Foo { 
    sorry() {}
}

new Foo().hello(); //perfectly valid
new Foo().sorry(); //ERROR 

내가 뭔가를 놓치고 있습니까?

@arackaf 예, 이 순진한 접근 방식이 빠져 있는 것은 데코레이터가 임의의 유형을 자유롭게 반환할 수 있고 결과가 Foo 유형과 호환된다는 제한이 없다는 것입니다.

이것으로 만들 수 있는 부조리의 수는 얼마든지 있습니다. c this 를 입력하는 순환성에 대한 내 이의를 보류한다고 가정해 보겠습니다. this 의 유형에 따라 결정되며, 이는 c 등. 여전히 작동하지 않습니다. 여기 또 다른 무의미한 예가 있습니다.

type Constructor<T> = new (...args: any[]) => T
type Greeter = { hello(): string }

function logger<T extends Constructor<Greeter>>(Class: T) {
    return class {
        hello() {
            console.log(new Class().hello())
        }
    };
}


<strong i="15">@logger</strong>
class Foo {
    foo() { return "bar" }
    // Whoops, `this` is `{ hello(): void }`, it has no `foo` method
    hello() { return this.foo(); }
}

이 경우 완전히 무해한 코드에 대해 오류를 생성하거나 this 가 데코레이터의 반환 유형과 정확히 동일하다는 명제를 조정해야 합니다.

문제가 있는지 잘 모르겠습니다. @logger 은 foo 메서드 없이 완전히 새로운 hello() 메서드를 사용하여 완전히 새로운 클래스를 반환하도록 선택했습니다. Foo .

new Foo().foo()

더 이상 유효하지 않습니다. 런타임 오류가 발생합니다. 나는 그것이 또한 컴파일 타임 오류를 생성해야한다고 말하고 있습니다.

즉, 모든 것을 정적으로 분석하는 것이 너무 어렵다면 반환되는 내용을 정확히 나타내기 위해 명시적 유형 주석을 logger 에 추가하도록 강제하는 것이 완전히 합리적일 것입니다. 그리고 그러한 유형 주석이 없으면 Foo 가 다시 반환된다고 가정하는 것으로 되돌릴 수 있습니다. 그것은 이전 버전과의 호환성을 유지해야 합니다.

@arackaf 타이핑이나 런타임 평가 측면에서 코드에는 문제가 없습니다. new Foo().hello() 를 호출할 수 있으며, 이는 내부적으로 장식된 클래스의 hello 를 호출하고, 이는 장식된 클래스의 bar 를 호출합니다. 원래 클래스 내에서 bar 를 호출하는 것은 오류가 아닙니다.

플레이그라운드에서 다음 전체 예제를 실행하여 직접 사용해 볼 수 있습니다.

// Code from previous snippet...

const LoggerFoo = logger(Foo)
new LoggerFoo().hello()

물론입니다. 하지만 호출하는 데 오류가 있다고 말했습니다.

new Foo().foo()

타이핑이나 런타임 평가 측면에서 코드에는 문제가 없습니다. new Foo().hello()를 호출할 수 있습니다. 내부적으로 장식된 클래스의 hello를 호출하고 장식된 클래스의 막대를 호출합니다.

그러나 그것은 오류라고 말해야합니다.

let s : string = new Foo().hello();

Foo의 hello 메서드는 이제 Logger가 반환하는 클래스별로 void를 반환합니다.

물론입니다. 하지만 new Foo().foo() 를 호출하는 것은 오류라고 말했습니다.

@arackaf 하지만 그건 중요하지 않습니다. new Foo().foo() 를 호출하지 않았습니다. this.foo() 를 호출했는데 코드가 런타임에 제대로 작동하는데도 유형 오류가 발생했습니다.

하지만 let s : string = new Foo().hello() 라고 말하는 것은 오류여야 합니다.

다시 말하지만 이것은 관련이 없습니다. Foo.prototype.hello () => string 한다고 말하는 것이 아닙니다( () => void 이어야 한다는 데 동의합니다). 나는 유효한 호출 this.bar() 오류에 대해 불평하고 있습니다. 이식하는 것이 무의미한 유형을 외과적으로 이식했기 때문입니다.

여기에 두 개의 푸가 있습니다. 당신이 말할 때

class Foo { 
}

Foo는 클래스 내부의 변경 불가능한 바인딩이고 클래스 외부의 변경 가능한 바인딩입니다. 따라서 jsbin에서 확인할 수 있으므로 완벽하게 작동합니다.

class Foo { 
  static sMethod(){
    alert('works');
  }
  hello(){ 
    Foo.sMethod();
  }
}

let F = Foo;

Foo = null;

new F().hello();

위의 예는 비슷한 작업을 수행합니다. 외부 바인딩이 변경되기 전에 원래 클래스에 대한 참조를 캡처합니다. 나는 아직도 당신이 무엇을 운전하고 있는지 잘 모르겠습니다.

this.foo(); 는 완벽하게 유효하며 유형 오류를 예상하지 않습니다(참조가 필요한 경우 TS 사람을 비난하지도 않을 것입니다. 이것을 추적하는 것이 어려울 것이라고 확신하기 때문입니다)

this.foo(); 는 완벽하게 유효하며 유형 오류를 예상하지 않습니다.

좋습니다. 그래서 우리는 동의합니다. 하지만 이것은 이제 this 가 데코레이터가 반환하는 모든 인스턴스 유형이 되어야 한다는 제안을 승인하거나 기각해야 함을 의미합니다. 유형 오류가 아니어야 한다고 생각한다면 내 예에서 { hello(): void } 대신 this 가 되어야 합니까?

this 는 인스턴스화된 항목에 따라 다릅니다.

<strong i="7">@c</strong>
class Foo{
}

new Foo(). // <---- this is based on whatever c returned 

function c(Cl){
    new Cl().  // <----- this is an object whose prototype is the original Foo's prototype
                   // but for TS's purpose, for type errors, it'd depend on how Cl is typed
}

한 가지 구체적인 예를 들어볼까요? 그렇게 하면 훨씬 더 이해하기 쉬울 것입니다. 다음 스니펫에서:

type Constructor<T> = new (...args: any[]) => T
type Greeter = { hello(): string }

function logger<T extends Constructor<Greeter>>(Class: T) {
    return class {
        hello() {
            console.log(new Class().hello())
        }
    };
}

<strong i="6">@logger</strong>
class Foo {
    foo() { return "bar" }
    hello() { return this.foo(); } /// <------
}

this 의 유형은 무엇입니까? { hello(): void } 이면 foo 가 { hello(): void } 의 구성원이 아니기 때문에 유형 오류가 발생합니다. { hello(): void } 가 아니면 this 는 단순히 데코레이터 반환 유형의 인스턴스 유형이 아니며 $# 유형에 도달하기 위해 사용하는 대체 논리를 설명해야 합니다 this .

편집: Foo 에 데코레이터를 추가하는 것을 잊었습니다. 결정된.

화살표가 있는 this 는 물론 원래 Foo 의 인스턴스입니다. 유형 오류가 없습니다.

아 - 이제 요점을 알았습니다. 그러나 나는 여전히 문제가 어디에 있는지 알지 못합니다. this.foo() WITHIN 원래 Foo 는 유형 오류가 아닙니다. 이는 Foo 식별자에 바인딩된 (지금은 연결할 수 없는) 클래스에 유효합니다.

독특하고 재미있는 상식이지만 이것이 TS가 돌연변이 클래스 데코레이터를 처리하는 것을 막아야 하는 이유를 모르겠습니다.

@arackaf 당신은 질문에 대답하지 않습니다. 구체적으로 this 의 유형은 무엇입니까? " this is Foo and Foo is this "라고 끝없이 순환적으로 대답할 수는 없습니다. this 의 멤버는? hello(): void 이외의 멤버가 있는 경우 멤버를 결정하는 데 사용되는 논리는 무엇입니까?

" this.foo() WITHIN original Foo is not type error"라고 말할 때에도 여전히 다음 질문에 답해야 합니다. this 의 구조적 유형은 무엇이며 유형 오류가 아닙니다. this.foo() 합니까?

또한 원래 클래스는 "접근할 수 없음"이 아닙니다. 해당 코드 조각에 정의된 모든 기능은 런타임에 능동적으로 실행되며 모두 문제 없이 작동합니다. 제가 제공한 플레이그라운드 링크를 실행하셔서 콘솔을 봐주세요. 데코레이터는 hello 메서드가 데코레이팅된 클래스의 hello 메서드에 위임된 새 클래스를 반환하고, 이 클래스는 차례로 데코레이팅된 클래스의 foo 메서드에 위임합니다.

독특하고 재미있는 상식이지만 이것이 TS가 돌연변이 클래스 데코레이터를 처리하는 것을 막아야 하는 이유를 모르겠습니다.

유형 시스템에는 "트리비아"가 없습니다. 사용 사례가 너무 틈새 시장이기 때문에 TSC-1234 "naughty boy, you can't do that" 유형 오류가 발생하지 않습니다. 기능으로 인해 완전히 정상적인 코드가 놀라운 방식으로 중단되는 경우 기능을 재고해야 합니다.

사용 사례가 너무 틈새 시장이기 때문에 TSC-1234 "naughty boy, you can't do that" 유형 오류가 발생하지 않습니다.

이것이 바로 데코레이터가 클래스 정의에 추가한 메서드를 사용하려고 할 때 얻는 것입니다. 현재 클래스에 정의를 추가하거나 인터페이스 병합, any 등으로 캐스팅하여 이 문제를 해결해야 합니다.

this 가 무엇이며 어디에 있는지에 대한 모든 질문에 답변했습니다.

문제의 간단한 사실은 this 의 의미는 당신이 어디에 있느냐에 따라 달라진다는 것입니다.

type Constructor<T> = new (...args: any[]) => T
type Greeter = { hello(): string }

function logger<T extends Constructor<Greeter>>(Class: T) {
    return class {
        hello() {
            console.log(new Class().hello())
        }
    };
}

class Foo {
    foo() { return "bar" }
    hello() { return this.foo(); } /// <------
}

const LoggableFoo = logger(Foo)
new LoggableFoo().hello() // Logs "bar"

new Class() - 클래스가 원래 Foo를 가리키고 있고 TypeScript의 관점에서 보면 클래스가 입력되는 형식이기 때문에 hello(): string 에 액세스할 수 있습니다(Greeter 확장). 런타임에 원래 Foo의 인스턴스를 인스턴스화하게 됩니다.

new LoggableFoo().hello() 는 Greeter를 통해 입력한 다른 방법으로는 도달할 수 없는 메서드를 호출하는 void 메서드를 호출합니다.

했다면

<strong i="21">@logger</strong>
class Foo {
    foo() { return "bar" }
    hello() { return this.foo(); }
}

그러면 Foo는 이제 hello(): void만 있는 클래스이고 new Foo().foo()는 유형 오류여야 합니다.

그리고 다시 hello() { return this.foo(); } 는 TypeError가 아닙니다. 왜 그런가요? 해당 클래스 정의에 더 이상 연결할 수 없다고 해서 해당 메서드가 무효화되는 것은 아닙니다.

TypeScript가 이러한 극단적인 경우를 완벽하게 만들 것이라고 기대하지 않습니다. 언제나처럼 여기 저기에 유형 주석을 추가해야 하는 것은 꽤 이해할 만합니다. 그러나 이러한 예 중 어떤 것도 @logger 가 Foo 의 바인딩 대상을 근본적으로 변경할 수 없는 이유를 보여주지 않습니다.

logger 가 새 클래스를 반환하는 함수이면 Foo가 이제 참조하는 것입니다.

나는 이것이 무엇이며 어디에 있는지에 대한 모든 질문에 답했습니다.
문제의 간단한 사실은 this 의 의미가 당신이 어디에 있느냐에 따라 달라진다는 것입니다.

정말 답답합니다. 좋아요, 변경됩니다. Foo , 정적 바인딩 등입니다. 형식 서명은 무엇입니까? this 의 멤버는? 내가 당신에게 필요한 것은 this 내부에 hello 에 대한 간단한 유형 서명일 때 당신은 태양 아래 있는 모든 것에 대해 이야기하고 있습니다.

new LoggableFoo().hello() 는 Greeter를 통해 입력한 다른 방법으로는 도달할 수 없는 메서드를 호출하는 void 메서드를 호출합니다.

이것은 도달할 수 없는 것과 다릅니다. 도달 가능한 모든 방법은 도달 가능한 경로를 할인할 때 "그렇지 않으면 도달할 수 없습니다".

당신이 했다면:

그러나 이것은 말 그대로 내가 한 일입니다. 그것은 바로 내가 만든 예제에 대한 설명과 함께 다시 붙여넣은 내 코드 조각입니다. 나는 심지어 내가 미친 약을 먹고 있지 않은지 확인하기 위해 diff 검사기를 통해 실행했으며 유일한 차이점은 제거한 댓글입니다.

그리고 다시 hello() { return this.foo(); } 는 TypeError가 아닙니다. 왜 그런가요?

당신(그리고 여기 있는 다른 사람들)은 this 유형이 데코레이터의 인스턴스화된 반환 유형이 되기를 원하기 때문에 { hello(): void } 입니다( foo 멤버가 없음에 주의). Foo 의 멤버가 데코레이터의 반환 유형으로 this 를 볼 수 있게 하려면 hello this 유형은 { hello(): void } . { hello(): void } 이면 유형 오류가 발생합니다. 유형 오류가 발생하면 내 코드가 제대로 실행되기 때문에 슬픕니다.

유형 오류가 아니라고 말하면 데코레이터의 반환 유형을 통해 this 유형을 제공하는 자체 체계를 포기하는 것입니다. this 의 유형은 데코레이터가 반환하는 것과 상관없이 { hello(): string; bar(): string } 입니다. 이 문제를 방지하기 this 유형을 생성하기 위한 몇 가지 대체 체계가 있을 수 있지만 그것이 무엇인지 지정해야 합니다.

데코레이터가 실행된 후 Foo 가 원래 정의된 것과 완전히 다른 것을 참조할 수 있다는 것을 이해하지 못하는 것 같습니다.

function a(C){
    return class {
        x(){}
        y(){}
        z(){}
    }
}

<strong i="7">@a</strong>
class Foo {
    a(){ 
        this.b();  //valid
    }
    b() { 
        this.c();  //also valid
    }
    c(){ 
        return 0;
    }
}

let f = new Foo();
f.x(); //valid
f.y(); //also valid
f.z(); //still valid

this 가 위의 Foo 내부에서 뭔가 다른 것이 있다는 점에서 이상한 점을 발견했다고 생각합니다 Foo 가 (데코레이터가 실행된 후) 결과적으로 생성되는 경우와는 다릅니다.

무엇을 말해야 할지 잘 모르겠습니다. 그것이 바로 데코레이터가 작동하는 방식입니다. 내 유일한 주장은 TypeScript가 무슨 일이 일어나고 있는지 더 밀접하게 일치해야 한다는 것입니다.

다시 말해, (원래) Foo 내부의 유형 서명은 데코레이터가 실행되면 Foo가 생성하는 것과 다릅니다.

다른 언어에서 비유를 빌리자면 장식된 Foo 내부에서 이것은 C# 익명 유형에 해당하는 것을 참조하는 것입니다. 완전히 실제 유형입니다. 그렇지 않으면 유효하지만 실제로 직접 참조할 수는 없습니다. 위에서 설명한 오류 및 비 오류를 얻는 것이 이상하게 보일 수 있지만 다시 말하지만 그것이 작동하는 방식입니다. 데코레이터는 우리에게 이와 같은 기이한 일을 할 수 있는 엄청난 힘을 줍니다.

위의 Foo 내부에서 뭔가 다른 것이 있다는 점에서 이상한 점을 발견했다고 추측합니다. (데코레이터가 실행된 후) Foo에서 결과적으로 생성되는 경우와 다릅니다.

아니오. 저는 거기에서 이상한 점을 찾지 못했습니다. 왜냐하면 그것은 제가 200개의 댓글을 전에 제안했던 것과 정확히 일치하기 때문입니다. 당신은 앞의 토론을 읽었습니까?

귀하가 게시한 스니펫은 전혀 논란의 여지가 없습니다. 내가 동의하지 않는 사람들과 당신이 도움을 요청한 사람들은 추가 로 다음을 원합니다.

function a(C){
    return class {
        x(){}
        y(){}
        z(){}
    }
}

<strong i="10">@a</strong>
class Foo {
    a(){ 
        this.b();  //valid
    }
    b() { 
        this.c();  //also valid
    }
    c(){ 
        return 0;
    }
    d(){
        // HERE: All of these are also expected to be valid
        this.x();
        this.y();
        this.z();
    }
}

let f = new Foo();
f.x(); //valid
f.y(); //also valid
f.z(); //still valid

나는 이것을 건전하게 할 수 있다는 데 동의하지 않으며 그러한 제안이 어떻게 작동하는지 알아 내려고 필사적으로 노력했습니다. 최선의 노력에도 불구하고 this 이(가) 가질 것으로 예상되는 회원의 전체 목록이나 이러한 목록이 제안서에 따라 구성되는 방식을 추출할 수 없습니다.

다시 말해, (원래) Foo 내부의 유형 서명은 데코레이터가 실행되면 Foo가 생성하는 것과 다릅니다.

그런데도 왜 나와 말다툼을 하느냐? 나는 말했다: "나는 new Foo().foo가 타입 에러가 되는 것이 버그라는 것에 동의하고, 그것에 대해 쉽게 고칠 수 있다. 나는 this.foo를 반환한다는 것에 동의하지 않는다. 타입 에러가 되는 것은 버그이다." 유사하게, 귀하의 예에서 new Foo().x() 가 유형 오류인 것은 버그이지만 this.x() 인 유형 오류는 그렇지 않다는 데 동의합니다.

이 페이지 상단의 스니펫에 두 개의 댓글이 있는 것을 보셨습니까?

        return this.foo; // Property 'foo' does not exist on type 'Foo'

^^ 제가 문제라고 생각하는 부분입니다. 데코레이터의 반환 유형이 this 에 표시되어서는 안 되며 $ new Foo() 에만 표시되어야 한다는 데 동의합니다. 또는 동의하지 않고 해당 기능도 원합니다. 이 경우 이전 댓글의 스니펫은 관련이 없습니다.

나는 마침내 당신의 요점을 이해합니다. 귀하의 Greeter 코드에서 이것을 얻는 것이 매우 어려웠지만 지금 추적 중입니다. 인내해주셔서 감사합니다.

유일한 합리적인 해결책은 Foo(Foo 내부 )가 원래 Foo의 유형 결합(derp는 교집합을 의미함)과 마지막 데코레이터가 반환하는 모든 것을 지원하는 것이라고 말하고 싶습니다. Greeter와 같은 미친 예제의 경우 원래 Foo 를 지원해야 하며, 마지막 데코레이터 가 반환하는 모든 것을 지원해야 합니다. 이것이 데코레이터를 사용하는 요점 이기 때문입니다(위의 많은 설명에 따라).

예, 가장 최근의 예에서 Foo x, y, z, a, b, c 내부에서 모두 작동합니다. a 의 두 가지 버전이 있는 경우 둘 다 지원합니다.

@arackaf np님도 기다려주셔서 감사합니다. 내 예제가 가장 명확하지 않은 이유는 놀이터에서 내가 요리할 수 있는 모든 것을 게시하여 고장난 방법을 보여주기 때문입니다. 체계적으로 생각하기 어렵네요.

유일한 합리적인 해결책은 Foo(Foo 내부)가 원래 Foo의 유형 합집합과 마지막 데코레이터가 반환하는 모든 것을 지원하는 것입니다.

좋습니다. 이제 세부 사항에 대해 알아보겠습니다. 내가 이것을 잘못 이해하고 있다면 저를 수정하십시오. 그러나 "union"이라고 말하면 둘 다의 유형 멤버가 있어야 함을 의미합니다. 즉, A & B 이어야 합니다. 그래서 우리는 this 가 typeof(new OriginalClass()) & typeof(new (decorators(OriginalClass))) 가 되기를 원합니다. 여기서 decorators 는 모든 데코레이터의 합성 유형 서명입니다. 일반 영어에서 우리는 this 가 "원래 클래스"의 인스턴스화된 유형과 모든 데코레이터를 통과한 "원본 클래스"의 인스턴스화된 유형의 교차점이 되기를 원합니다.

여기에는 두 가지 문제가 있습니다. 하나는 내 예와 같은 경우 존재하지 않는 멤버에 액세스할 수 있다는 것입니다. 데코레이터에 많은 멤버를 추가할 수 있지만 this.newMethod() 를 사용하여 클래스에서 멤버에 액세스하려고 하면 런타임에 토할 것입니다. newMethod 는 데코레이터 함수에서 반환된 클래스에만 추가되며 원래 클래스의 멤버는 액세스할 수 없습니다(특별히 return class extends OriginalClass { newMethod() { } } 패턴을 사용하지 않는 한).

다른 문제는 "원래 클래스"가 잘 정의된 개념이 아니라는 것입니다. this 에서 데코레이트된 멤버에 액세스 할 수 있다면 return 문의 일부로 사용할 수도 있으므로 "원래 클래스"의 공개 API의 일부일 수 있습니다. 저는 여기에서 손을 흔드는 편이라 구체적인 예를 생각하기에는 너무 지쳐있지만, 곰곰이 생각해보면 말도 안 되는 예가 나올 수 있을 것 같아요. this 에서 액세스한 항목을 반환하지 않거나 최소한 this.something() 을 반환한 결과 반환 유형이 유추되지 않은 구성원을 분리하는 방법을 찾아 이 문제를 해결할 수 있습니다.

@masaeedu 네, 답변 전에 연합/교차 부분에 대해 수정했습니다. TS를 처음 접하는 사람에게는 직관적이지 않습니다.

나머지는 이해했습니다. 솔직히 데코레이터는 일반적으로 완전히 다른 유형을 반환하지 않고 일반적 으로 전달된 유형을 보강하므로 대부분의 경우 교차로가 안전하게 "그냥 작동"합니다.

나는 당신이 말하는 런타임 오류가 드물고 의도적으로 잘못된 개발 결정의 결과라고 말하고 싶습니다. 나는 당신이 이것에 대해 정말로 신경써야 하는지 확신하지 못하지만, 그것이 정말로 문제라면, 나는 마지막 데코레이터가 반환한 것을 사용하는 것이 괜찮은 두 번째 장소가 될 것이라고 말하고 싶습니다. (그래서, 클래스는 자체적으로 정의한 방법을 사용하려고 합니다. 이상적이지는 않지만 작업하는 데코레이터에 대해 지불할 가치가 있는 가격).

그러나 실제로, 나는 당신이 생각하고 있는 런타임 오류가 예방할 가치가 없다고 생각합니다. 확실히 데코레이터가 올바르게 작동하는 것을 희생시키면서 말이죠. 게다가, 부주의하거나 어리석은 경우 TS에서 런타임 오류를 생성하는 것은 매우 쉽습니다.

interface C { a(); }
class C {
    foo() {
        this.a();  //<--- boom
    }
}

let c = new C();
c.foo();

두 번째 이의 제기에 대해

또한 return 문의 일부로 사용할 수 있으므로 "원래 클래스"의 공개 API의 일부일 수 있습니다.

나는 그것에 대해 아무런 문제가 없다고 생각합니다. 나는 데코레이터를 통해 클래스에 추가된 모든 것이 절대적으로 일류 시민 이 되기를 원합니다 . 어떤 잠재적인 문제가 있을지 궁금합니다.

다른 좋은 옵션 중 하나는 이것을 부분적으로만 구현하는 것입니다.

현재 클래스는 항상 정의된 대로 유형이 지정됩니다. 따라서 Foo 내부에서는 데코레이터에 관계없이 foo가 정의된 방식을 기반으로 합니다. 데코레이터 사용 사례의 일부 유용한 하위 집합(즉, 가장 일반적인 경우)에 대해 "그냥" 확장하는 것은 엄청나게 큰 개선이 될 것입니다.

데코레이터가 원본을 확장하는 것을 반환하는 경우에만(클래스 내부의 this 관점에서) 클래스 확장을 허용하면 어떻게 될까요?

function d(Class) {
    return class extends Class {
        blah() { }
    };
}

<strong i="9">@d</strong>
class Foo {
    a() { }
    b() { }
    c() { 
        this.blah(); // <---- valid
    }
}

그냥 작동하게 하고 blah 및 데코레이터가 추가한 모든 것에 대해 최고 수준의 지원을 제공하십시오. 그리고 완전히 새로운 클래스(예: Greeter)를 반환하는 것과 같은 미친 작업을 수행하는 사용 사례의 경우 현재 동작을 계속하고 데코레이터가 수행하는 작업을 무시합니다.

Btw, 당신이 무엇을 선택하든 상관없이 어떻게 주석을 달겠습니까? 현재 주석을 달 수 있습니까? 나는 시도했다

function d<T>(Class: new() => T): T & { new (): { blah(): void } } {
    return class extends Class {
        blah() { }
    };
}

뿐만 아니라 해당 테마에 대한 많은 변형이 있지만 TypeScript에는 아무 것도 없었습니다. :)

@arackaf 데코레이터는 함수일 뿐입니다. 일반적인 경우 어딘가에 .d.ts 파일에서 가져오고 구현 방법을 모릅니다. 구현이 완전히 새로운 클래스를 반환하는지, 원래 클래스의 프로토타입에서 멤버를 추가/빼기/교체하고 반환하는지 또는 원래 클래스를 확장하는지 알 수 없습니다. 사용할 수 있는 것은 함수의 구조적 반환 유형뿐입니다.

어떻게든 데코레이터를 클래스 상속에 묶고 싶다면 먼저 JS에 대한 별도의 언어 개념을 제안해야 합니다. 오늘날 데코레이터가 작동하는 방식은 일반적인 경우 this 를 변경하는 것을 정당화하지 않습니다. 예를 들어, 저는 개인적으로 항상 상속보다 구성을 선호하며 항상 다음을 수행합니다.

function logger<T extends Constructor<Greeter>>(Class: T) {
    return class {
        readonly _impl;
        constructor() {
            this._impl = new Class()
        }
        // Use _impl ...
    };
}

이것은 미친 학문적 실험이 아닙니다. 이것은 믹스인을 수행하기 위한 늪지 표준 접근 방식이며, 제가 여러분에게 제공한 예를 깬 것입니다. 사실 return class extends Class 를 제외한 거의 모든 것은 내가 여러분에게 제공한 예제와 중단 되며 많은 경우 return class extends Class 로 중단됩니다.

이 작업을 수행하려면 모든 종류의 고리와 비틀림을 통과해야 하고 유형 시스템은 모든 단계에서 당신과 싸울 것입니다. 왜냐하면 당신이 하는 일이 일반적인 경우에 무의미하기 때문입니다. 더 중요한 것은 일단 구현하면 모든 사람이 다른 복잡한(그러나 건전한) 개념을 구현하려고 할 때마다 유형 시스템의 이 무의미한 구석을 재빠르게 움직여야 한다는 것입니다.

중요하다고 느끼는 이 사용 사례가 하나 있다고 해서(기존 유형 시스템에서 원하는 것을 건전하게 표현하는 대안적 방법을 보여주기 위해 이 스레드에서 여러 번 시도했습니다) 해야 할 일은 어떤 대가를 치르더라도 제안된 접근 방식을 계속 사용하는 것입니다. 데코레이터 함수의 반환 유형을 포함하여 임의의 인터페이스를 클래스에 병합할 수 있으므로 데코레이터를 사용하는 방식으로 데코레이터를 사용하기를 고집한다면 아무데도 가지 못하는 것이 불가능한 일이 아닙니다.

@arackaf :

function d<T>(Class: new() => T): T & { new (): { blah(): void } } {
    return class extends Class {
        blah() { }
    };
}

extends 절에서 잘 작동해야 합니다.

class C extends d(S) {
  foo() {
    this.blah(); // tsc is happy here
  }
}

유형 시스템에서 훨씬 더 쉽고 이미 정의된 의미 체계를 사용합니다. 이것은 이미 작동합니다. 선언된 클래스에 대한 슈퍼클래스를 만드는 대신 서브클래스로 해결하려는 문제는 무엇입니까?

@masaeedu

오늘날 데코레이터가 작동하는 방식은 일반적인 경우에 이를 변경하는 것을 정당화하지 않습니다.

(클래스) 데코레이터의 주요 용도는 어떤 식으로든 클래스 내부의 this 값을 절대적으로 긍정적으로 변경하는 것입니다. Redux의 @connect 와 MobX의 @observer 는 둘 다 수업을 받고 기능이 추가된 원래 수업의 새 버전을 내보냅니다. 이러한 특정 경우에 this 의 실제 구조가 변경된다고 생각 하지 않습니다( this.props 의 구조만). 그러나 그것은 중요하지 않습니다.

위의 주석에서 볼 수 있듯이 데코레이터를 사용하여 클래스를 변경하는 것은 매우 일반적인 사용 사례입니다. 더 좋든 나쁘든 사람들은 통사론적 대안을 싫어하는 경향이 있습니다.

let Foo = a(b(c(
    class Foo {
    }
})));

반대로

<strong i="19">@a</strong>
<strong i="20">@b</strong>
<strong i="21">@c</strong>
class Foo {
}

이제 데코레이터가

function d (Class){
    Class.prototype.blah = function(){
    };
}

또는

function d(Class){
    return class extends Class {
        blah(){ }
    }
}

중요하지 않아야합니다. 어떤 식으로든 많은 사람들이 주장하는 사용 사례는 어떤 주석이 필요한지, 우리에게 아무리 불편하더라도 TypeScript에 function c 가 C 클래스를 사용한다고 알릴 수 있다는 것입니다. C & {blah(): void} 구조의 클래스를 반환합니다.

이것이 오늘날 우리 중 많은 사람들이 데코레이터를 적극적으로 사용하는 이유입니다. 우리는 이 동작의 유용한 하위 집합을 유형 시스템에 통합하기를 정말 원합니다.

데코레이터가 유형 시스템이 추적할 수 없는 기이한 일을 할 수 있다는 것은 쉽게 증명됩니다. 괜찮은! 하지만 주석을 달 수 있는 방법이 있어야 합니다.

<strong i="38">@c</strong>
class Foo {
    hi(){ this.addedByC(); }
}

유효합니다. c 에 대한 새로운 유형 주석 구문이 필요한지 또는 기존 유형 주석 구문이 이를 달성하기 위해 c 에서 서비스로 제공될 수 있는지 모르겠지만 일반적인 사용을 수정하기만 하면 됩니다. 이 경우(원래 클래스에 영향을 미치지 않고 가장자리를 있는 그대로 두는 것)는 TS 사용자에게 큰 이점이 될 것입니다.

@justinfagnani 참고하세요

function d<T>(Class: new() => T): T & { new (): { blah(): void } } {
    return class extends Class {
        blah() { }
    };
}

생산하다

'typeof(익명 클래스)' 유형은 'T & (new () => { blah(): void; })' 유형에 할당할 수 없습니다.
'typeof(익명 클래스)' 유형은 'T' 유형에 할당할 수 없습니다.

TS 놀이터에서 일부 옵션이 잘못 설정되어 있는지 확실하지 않습니다.

선언된 클래스에 대한 슈퍼클래스를 만드는 대신 서브클래스로 해결하려는 문제는 무엇입니까?

나는 단지 데코레이터를 사용하려고합니다. 1년 넘게 JS에서 행복하게 사용하고 있습니다. TS가 따라잡기를 간절히 바라고 있습니다. 그리고 나는 확실히 하위 분류와 결혼하지 않았습니다. 때때로 데코레이터는 속성이나 메서드를 추가하기 위해 원래 클래스의 프로토타입을 변경합니다. 어느 쪽이든 목표는 TypeScript에 다음을 알리는 것입니다.

<strong i="17">@c</strong>
class Foo { 
}

c 에 의해 생성된 새 멤버가 있는 클래스가 생성됩니다.

@arackaf 우리는 다시 동기화되지 않습니다. 토론은 이것에 관한 것이 아닙니다 .

<strong i="8">@a</strong>
<strong i="9">@b</strong>
<strong i="10">@c</strong>
class Foo {
}

대 이것:

let Foo = a(b(c(
    class Foo {
    }
})));

나는 당신이 전자를 사용할 수 있고 여전히 new Foo() 의 적절한 타이핑을 가질 수 있기를 기대합니다. 이에 대한 논쟁은 다음과 같습니다.

<strong i="18">@a</strong>
<strong i="19">@b</strong>
<strong i="20">@c</strong>
class Foo {
    fooMember() { 
        this.aMember(); this.bMember(); this.cMember(); 
    }
}

대 이것:

class Foo extends (<strong i="24">@a</strong> <strong i="25">@b</strong> <strong i="26">@c</strong> class { }) {
    fooMember() { 
        this.aMember(); this.bMember(); this.cMember(); 
    }
}

후자는 유형 시스템을 손상시키지 않고 작동합니다. 전자는 내가 이미 설명한 여러 면에서 문제가 있습니다.

@masaeedu 전자가 작동하도록 할 수 있는 제한된 사용 사례가 실제로 없습니까?

정확히 말하면 TypeScript가 위의 예에서 a , b 및 c 에 추가하도록 지시할 수 있는 주석이 없는지 유형 시스템이 전자를 처리하도록 하십시오. 후자와 구별할 수 없을 정도로?

그것은 TypeScript의 킬러 발전이 될 것입니다.

@arackaf 죄송합니다. type 매개변수가 인스턴스 유형이 아닌 생성자 유형을 참조하도록 해야 합니다.

이것은 작동합니다:

type Constructor<T = object> = new (...args: any[]) => T;

interface Blah {
  blah(): void;
}

function d<T extends Constructor>(Class: T): T & Constructor<Blah> {
  return class extends Class {
    blah() { }
  };
}

class Foo extends d(Object) {
  protected num: number;

  constructor(num: number) {
    super();
    this.num = num;
    this.blah();
  }
}

나는 단지 데코레이터를 사용하려고합니다.

그것은 당신이 해결하려는 문제가 아니라 동어반복입니다. Q: "그 망치로 무엇을 하려고 합니까?"와 같습니다. A: "그냥 망치를 사용하세요."

의도한 확장으로 새 슈퍼클래스를 생성하는 것이 작동하지 않는 실제 사례가 있습니까? TypeScript는 지금 그것을 지원하기 때문에 그리고 내가 말했듯이, 그 경우에 클래스 내부에서 클래스의 유형에 대해 추론하는 것이 훨씬 쉽습니다.

Mobx의 @observer render() 을 보니 클래스 모양이 변경되지 않는 것처럼 보입니다.

@connect @connect 실제로 데코레이터를 올바르게 입력하는 복잡성의 좋은 예입니다. 정적이 복사되므로 결과는 인스턴스 측 인터페이스를 버리고 대부분의 경우 TS가 확인하지 않는 정적 측을 유지합니다. @connect 는 실제로 데코레이터가 되어서는 안 되며 connect는 HOC로 사용되어야 합니다. 데코레이터로서 매우 혼란스럽기 때문입니다.

1년 넘게 JS에서 행복하게 사용하고 있습니다.

글쎄... 당신은 정말. JS에는 데코레이터가 없습니다. 당신은 아마도 Babel과 TypeScript에서 약간 다르게 구현된 특정 존재하지 않는 이전 제안을 사용했을 것입니다. 다른 장소에서는 데코레이터가 표준화 프로세스를 계속 진행해야 한다고 주장하고 있지만 진행 속도가 느려지고 있으며 아직 확실하지 않다고 생각합니다. 많은 사람들은 그것들이 추가되어서는 안 되거나 단지 주석이 되어서는 안 된다고 주장합니다. 그래서 의미 체계는 여전히 공중에 떠 있을 수 있습니다.

데코레이터에 대한 불만 중 하나는 정확히 클래스의 모양을 변경할 수 있어 정적으로 추론하기가 어렵다는 것입니다. 일부 제안은 적어도 데코레이터가 그렇게 할 수 있는 능력을 제한하기 위해 논의되었습니다. 가장 최근의 제안에 사양 언어가 있습니다. 나는 개인적으로 선의로 행동하는 데코레이터가 클래스의 모양을 변경해서는 안 된다고 주장합니다. 그래서 정적 분석을 위해 무시할 수 있습니다. 표준 JS에는 함수 구현이 수행하는 작업을 분석에 알려주는 유형 시스템이 없다는 점을 기억하십시오.

• TS가 따라잡을 수 있기를 바랄 뿐입니다.

TypeScript가 어떤 식으로든 여기에서 어떻게 뒤처져 있는지 알 수 없습니다. 적어도 무엇 뒤에? 데코레이터가 일을 합니다. 클래스가 원하는 방식으로 동작하는 다른 유형의 JS가 있습니까?

데코레이터는 이제 2단계이며 거의 모든 JS 프레임워크에서 사용됩니다.

@connect 에 관해서는 react-redux가 매달 약 250만 다운로드를 기록하고 있습니다. 당신이 다르게 구현했을 것이기 때문에 디자인이 어떻게든 "틀렸다"는 말을 듣는 것은 믿을 수 없을 정도로 오만합니다.

현재 데코레이터가 도입한 메소드를 사용하려는 시도는 TypeScript에서 유형 오류를 초래하여 인터페이스 병합, 추가된 메소드에 대한 주석 수동 추가 또는 클래스를 변경하기 위해 데코레이터를 사용하지 않는 것과 같은 해결 방법이 필요합니다. 데코레이터를 사용하지 마십시오).

데코레이터가 클래스 모양을 변경하고 있다는 사실을 TS 컴파일러에 수동으로 공들여 알리는 방법이 정말로 없을까요? 어쩌면 이것은 미쳤지만 TS는 새로운 데코레이터를 배송할 수 없었습니다.우리가 사용할 수 있는 유형

let c : 데코레이터

그리고 해당 유형의 데코레이터가 클래스에 적용되는 경우에만 IF, TS는 해당 클래스를 Input & { blah() } ?

말 그대로 모든 사람들은 우리가 데코레이터를 사용할 수 없다는 것을 알고 있습니다. 또한 보컬 그룹이 데코레이터를 싫어한다는 것도 알고 있습니다. 이 게시물은 어떻게 TS가 어떻게든 형식 시스템이 데코레이터가 클래스 정의를 변경하고 있음을 이해하도록 할 수 있는지에 관한 것입니다. 그것은 많은 사람들에게 큰 도움이 될 것입니다.

정확히 말하면 TypeScript가 위의 예에서 유형 시스템이 전자를 후자와 구별할 수 없도록 처리하기 위해 위의 예에서, b, c에 추가하도록 지시할 수 있는 주석이 없습니까?

예, 원하는 Foo 의 모양을 선언하는 것은 매우 쉽습니다. 인터페이스 병합을 사용하기만 하면 됩니다. 다음을 수행하기만 하면 됩니다.

interface Foo extends <whateverextramembersiwantinfoo> { } 
<strong i="9">@a</strong>
<strong i="10">@b</strong>
<strong i="11">@c</strong>
class Foo { 
    /* have fun */
}

지금 당장은 반환되는 항목에 해당하는 매개변수화된 형식을 내보내는 데 사용하는 데코레이터 라이브러리가 무엇이든 예상해야 할 것입니다. 그렇지 않으면 추가하려는 멤버를 직접 선언해야 합니다. #6606 을 얻으면 interface Foo extends typeof(a(b(c(Foo)))) 하면 됩니다.

현재 데코레이터가 도입한 메소드를 사용하려는 시도는 TypeScript에서 유형 오류를 초래하여 인터페이스 병합, 추가된 메소드에 대한 주석 수동 추가 또는 클래스를 변경하기 위해 데코레이터를 사용하지 않는 것과 같은 해결 방법이 필요합니다. 데코레이터를 사용하지 마십시오).

데코레이터 도입 멤버에 불가지론적일 때 작성 중인 클래스를 데코레이팅하고 그렇지 않은 경우 데코레이팅된 클래스를 확장하는 옵션을 언급하지 않았습니다. 이것이 내가 최소한 데코레이터를 사용하는 방법입니다.

지금 사용하고 있는 라이브러리의 코드 스니펫을 알려주실 수 있나요? 이것이 문제가 되는 부분입니다.

죄송합니다. 귀하의 마지막 의견을 따르지 않았지만 인터페이스 병합과 함께 그 이전의 귀하의 의견은 정확히 제가 이 문제를 해결하는 방법입니다.

현재 내 데코레이터는 Type도 내보내야 하며, 보여주신 대로 인터페이스 병합을 사용하여 데코레이터에 의해 새 구성원이 추가되고 있음을 TS에 나타냅니다. 많은 사람들이 열망하는 이 추가된 상용구를 버리는 기능입니다.

@arackaf 아마도 당신이 정말로 원하는 것은 함수 인수의 컨텍스트 타이핑과 상호작용하기 위해 선언 병합을 위한 방법일 것입니다.

확신하는. 나는 클래스에서 데코레이터를 사용하는 기능을 원하고 개념적으로 내가 데코레이터를 정의한 방법에 따라 일부 인터페이스 병합이 발생하여 데코레이팅된 클래스에 추가 멤버가 추가되기를 원합니다.

나는 그것이 일어나도록 내 데코레이터에 어떻게 주석을 달아야 하는지 전혀 모르지만, 나는 그다지 까다롭지 않습니다. 미래의 TS 버전이 저에게 영향을 준 어떤 구문도 저를 엄청나게 행복하게 만들 것입니다. :)

데코레이터는 이제 2단계이며 거의 모든 JS 프레임워크에서 사용됩니다.

그리고 그들은 단지 2단계에 있고 매우 느리게 움직이고 있습니다. 나는 데코레이터가 일어나기를 간절히 바라고 그들이 함께 움직이도록 도울 수 있는 방법을 알아 내려고 노력하고 있지만 그들은 여전히 ​​확실하지 않습니다. 나는 여전히 프로세스에 영향을 미칠 수 있는 사람들이 그들에게 반대하거나 주석으로 제한되기를 원하는 사람들을 알고 있지만 그들이 방해할 것이라고는 _생각하지 않습니다_. JS가 아닌 현재 컴파일러 데코레이터 구현에 대한 내 요점은 의미합니다.

@connect 의 경우 react-redux는 한 달에 약 250만 다운로드를 기록하고 있습니다. 당신이 다르게 구현했을 것이기 때문에 디자인이 어떻게든 "틀렸다"는 말을 듣는 것은 믿을 수 없을 정도로 오만합니다.

저를 오만하게 하는 등 인신공격은 삼가해 주십시오.

1. 내가 인신공격한게 아니니까 인신공격하지마.
2. 당신의 주장에 전혀 도움이 되지 않습니다.
3. 프로젝트의 인기가 기술 비평에서 제외되어서는 안 됩니다.
4. 우리는 같은 것에 대해 이야기하고 있습니까? redux-connect-decorator는 하루에 4번 다운로드됩니다. react-redux의 connect() 함수는 내가 제안한 것처럼 HOC처럼 보입니다.
5. 내 생각에 선한 데코레이터는 클래스의 공개 형태를 변경해서는 안 되며 확실히 관련 없는 클래스로 대체해야 하며 꽤 합리적이며 JS 커뮤니티에서 충분한 동의를 얻을 것이라고 생각합니다. 동의하지 않더라도 오만함과는 거리가 멀다.

현재 데코레이터가 도입한 메소드를 사용하려는 시도는 TypeScript에서 유형 오류를 초래하여 인터페이스 병합, 추가된 메소드에 대한 주석 수동 추가 또는 클래스를 변경하기 위해 데코레이터를 사용하지 않는 것과 같은 해결 방법이 필요합니다. 데코레이터를 사용하지 마십시오).

우리가 데코레이터를 전혀 사용하지 말라고 제안하는 것이 아니라, @masaeedu 가 형식 안전 방식으로 프로토타입을 수정하기 위해 기존 메커니즘인 상속 및 믹스인 응용 프로그램이 있다고 말합니다. d 예제가 믹스인으로 사용하기에 적합하지 않은 이유를 물어보려고 했는데 데코레이터를 사용하고 싶다는 말 외에는 답변을 하지 않았습니다.

내 생각에는 괜찮지만 대화를 상당히 비판적으로 제한하는 것 같으므로 다시 고개를 숙이겠습니다.

@justinfagnani 내가 말하던

import {connect} from 'react-redux'

connect 위에서 말했듯이 클래스(컴포넌트)를 받아서 다른 것을 뱉어내는 함수가 있을 뿐입니다.

현재 Babel과 TypeScript에서 다음과 같이 connect 를 사용하는 옵션이 있습니다.

class UnConnectedComponent extends Component {
}

let Component = connect(state => state.foo)(UnConnectedComponent);

또는 이와 같이

@connect(state => state.foo)
class Component extends Component {
}

나는 우연히 후자를 선호하지만 당신이나 다른 누군가가 전자를 선호한다면 그렇게 하십시오. 많은 도로가 로마로 연결됩니다. 나는 비슷하게 선호한다

<strong i="19">@mappable</strong>
<strong i="20">@vallidated</strong>
class Foo {
}

~ 위에

let Foo = validated(mappable(class Foo {
}));

또는

class Foo extends mixin(validated(mappable)) {
}
//or however that would look.

내가 데코레이터를 사용하는 이유가 분명하다고 생각했기 때문에 귀하의 질문에 명시적으로 대답하지 않았지만 명시적으로 말할 것입니다. 저는 데코레이터가 제공하는 인체 공학 및 구문을 선호합니다. 이 전체 스레드는 인터페이스 병합과 같은 상용구를 필요로 하지 않도록 데코레이터가 문제의 클래스를 어떻게 변경하는지 TS에 알려주는 기능을 얻으려는 것입니다.

OP가 예전에 말했듯이 우리는 단지 원합니다.

declare function Blah<T>(target: T): T & {foo: number}

<strong i="31">@Blah</strong>
class Foo {
    bar() {
        return this.foo; // Property 'foo' does not exist on type 'Foo'
    }
}

new Foo().foo; // Property 'foo' does not exist on type 'Foo'

그냥 일하기 위해. 이 특정 구문에 대한 다른 대안이 존재한다는 사실은 명백하고 중요하지 않습니다. JS/TS 커뮤니티의 많은 사람들이 이 특정 구문을 싫어한다는 사실 또한 명백하고 중요하지 않습니다.

TS가 이 구문이 작동하도록 하는 방법이 제한적이긴 하지만 제공할 수 있다면 언어와 커뮤니티에 큰 이점이 될 것입니다.

@arackaf connect 를 사용하면 $# this 의 추가 구성원에 액세스해야 하는 방법을 언급하는 것을 소홀히 했습니다. AFAICT, 구성 요소 구현은 connect 가 수행하는 작업에 완전히 불가지론적이어야 하며 자체 props 및 state 사용합니다. 그런 의미에서 connect 가 디자인된 방식은 당신보다 @justinfagnani 의 데코레이터 사용법과 더 일치합니다.

설마. 고려하다

@connect(state => state.stuffThatSatisfiesPropsShape)
class Foo extends Component<PropsShape, any> {
}

그럼 나중에

<Foo />

그것은 유효해야합니다 - PropsShape 소품은 Redux 저장소에서 제공되지만 TypeScript는 Foo의 원래 정의에서 벗어나기 때문에 이것을 알지 못합니다. 따라서 누락된 소품에 대한 오류가 발생하고 any 로 캐스팅해야 합니다.

하지만 분명히 하자면, 원래 OP에서 제공한 정확한 사용 사례는 여기 위의 두 번째 설명에서 복제된 것으로, 우리 코드 기반과 그 외양에서 볼 때 다른 많은 사람들에게도 매우 일반적입니다. 우리는 말 그대로 다음과 같은 것을 사용합니다.

<strong i="6">@validated</strong>
<strong i="7">@mappable</strong>
class Foo {
}

그리고 TypeScript를 만족시키기 위해 일부 인터페이스 병합을 추가해야 합니다. 해당 인터페이스를 데코레이터 정의에 투명하게 병합하는 방법이 있으면 정말 좋을 것입니다.

우리는 이것으로 계속해서 원을 그리게 됩니다. Foo 의 유형이 connect 의 반환 유형이어야 한다는 데 동의 합니다. 우리는 이에 대해 전적으로 동의합니다.

우리가 다른 점은 Foo 내부 의 멤버가 this 가 데코레이터 반환 유형과 그것이 의미하는 "원래 Foo"의 일종의 재귀적 융합인 것처럼 가장해야 하는지 여부입니다. 이에 대한 사용 사례를 시연 하지 않았습니다 .

우리가 다른 점은 Foo 내부의 구성원이 이것이 의미하는 것이 무엇이든 데코레이터 반환 유형과 "원래 Foo"의 일종의 재귀적 융합인 척해야 하는지 여부입니다. 이에 대한 사용 사례를 시연하지 않았습니다.

나는 가지고있다. 위의 내 의견과 그 문제에 대해서는 OP의 원래 코드를 참조하십시오. 이것은 매우 일반적인 사용 사례입니다.

connect 이 구성 요소 내부에서 액세스할 것으로 예상되는 프로토타입에 추가되는 항목을 보여주세요. 대답이 "아무것도"이면 완전히 관련이 없으므로 connect 를 다시 언급하지 마십시오.

@masaeedu 충분히 공정하고 동의합니다. 나는 주로 데코레이터가 원래 클래스를 수정하지 않아야 하는 방법, connect 이 잘못 설계되었는지 등에 대한 @justinfagnani 의 주장에 응답했습니다.

나는 단지 다른 옵션이 존재한다는 사실에도 불구하고 I 및 많은 다른 사람들이 선호하는 구문을 시연했을 뿐입니다.

이 경우, 예, 클래스를 가져오고 데코레이팅된 클래스 내부에서 사용되는 새 메서드로 새 클래스를 다시 내보내는 인기 있는 npm 라이브러리에 대해 알지 못합니다. 이것은 나와 다른 사람들이 우리 자신의 믹스인을 구현하기 위해 우리 자신의 코드에서 자주 하는 일이지만 실제로 npm에 대한 예가 없습니다.

그러나 이것이 일반적인 사용 사례라는 점에서 논쟁의 여지가 없는 것은 아닙니다. 그렇죠?

@arackaf 아니요, @connect this 의 회원에 액세스하지 않기 때문에 그렇지 않습니다. 사실 저는 이 정확한 스니펫을 확신합니다.

@connect(state => state.stuffThatSatisfiesPropsShape)
class Foo extends Component<PropsShape, any> {
    render(){
        this.props.stuffFromPropsShape // <----- added by decorator
    }
}

오늘 TypeScript에서 문제 없이 컴파일됩니다. 붙여넣은 스니펫은 요청한 기능과 아무 관련이 없습니다.

@masaedu - 정말 죄송합니다 - 제가 틀렸다는 것을 깨닫고 그 댓글을 삭제했습니다. 그래도 시간 낭비를 방지할 만큼 빠르지는 않습니다. :(

@arackaf 패턴이 얼마나 흔한지 모르겠고 개인적으로 직접 사용하거나 사용하는 라이브러리를 사용하지 않았습니다. 한동안 Angular 2를 사용했기 때문에 내 인생에서 데코레이터를 사용한 적이 없는 것과 같습니다. 이것이 내가 데코레이터가 도입한 데코레이터 멤버에 액세스할 수 없는 것이 골칫거리인 라이브러리를 사용하는 구체적인 예를 요청한 이유입니다.

클래스의 구성원이 this 를 기대하는 모든 경우에 클래스 본문이나 클래스의 extends 절에 요구 사항을 충족하는 무언가가 있어야 합니다. 이것은 데코레이터에서도 항상 작동하는 방식입니다. 클래스가 의존하는 일부 기능을 추가하는 데코레이터가 있는 경우 클래스는 데코레이터가 반환하는 모든 것을 확장해야 하며 그 반대는 안됩니다. 그냥 상식입니다.

이게 왜 상식인지 모르겠습니다. 이것은 현재 우리 코드 베이스의 코드입니다. 클래스의 프로토타입에 메서드를 추가하는 데코레이터가 있습니다. TypeScript 오류가 발생했습니다. 당시 나는 이 선언문을 거기에 던졌다. 인터페이스 병합을 사용할 수 있었습니다.

그러나 아무 것도 사용하지 않는 것이 좋습니다. TypeScript에 "이 데코레이터는 적용되는 모든 클래스에 이 메서드를 추가합니다. - 클래스 내부의 this 도 액세스할 수 있도록 허용합니다"라고 말할 수 있다면 정말 좋을 것입니다.

이 스레드의 다른 많은 사람들이 비슷한 데코레이터를 사용하는 것으로 보이므로 이것이 작동하지 않아야 한다는 것이 상식이 아닐 수도 있음을 고려하시기 바랍니다.

@arackaf 네, 그래서 export class SearchVm extends (@mappable({...}) class extends SearchVmBase {}) 해야 합니다. 매핑 가능성에 따라 달라지는 것은 SearchVm 이지 그 반대가 아닙니다.

내보내기 클래스 SearchVm 확장(@mappable({...}) 클래스 확장 SearchVmBase {})

이 스레드의 요점은 그런 상용구를 피하는 것입니다. 데코레이터는 그런 일을 하는 것보다 훨씬 더 멋진 DX를 제공합니다. 그보다는 저와 같은 코드를 작성하기로 선택한 이유가 있습니다.

이 스레드에 대한 주석을 읽으면 많은 다른 사람들이 더 간단한 데코레이터 구문을 사용하려고 하므로 우리가 "해야 할" 일이나 "상식" 등을 재고하려고 한다는 것을 확신할 수 있기를 바랍니다.

원하는 것은 특별히 데코레이터와 관련이 없습니다. 문제는 TypeScript의 "이봐 TypeScript, 이 구조에 대해 당신이 전혀 알지 못하는 일이 일어나고 있습니다. 이에 대해 모두 말하겠습니다"라고 말하는 메커니즘이 현재 너무 제한적이라는 것입니다. 지금은 인터페이스 병합만 있지만 함수가 인수에 인터페이스 병합을 적용할 수 있기를 원합니다. 이는 어떤 식으로든 데코레이터와 특별히 관련이 없습니다.

지금은 인터페이스 병합만 있지만 함수가 인수에 인터페이스 병합을 적용할 수 있기를 원합니다. 이는 어떤 식으로든 데코레이터와 특별히 관련이 없습니다.

확인. 그럴 수 있지. 별도의 문제를 열겠습니까, 아니면 이 문제의 이름을 변경하시겠습니까?

@arackaf 유일한 "보일러 플레이트"는 내가 class { } 를 가지고 있다는 사실입니다 . a) 얼마나 많은 데코레이터를 사용하든 관계없이 고정된 7자 b) 데코레이터는 (아직 ) 임의의 클래스 반환 표현식에 적용, c) 특별히 귀하의 이익을 위해 데코레이터를 사용하고 싶었기 때문입니다. 이 대체 공식:

export class SearchVm extends mappable({...})(SearchVmBase)
{
}

원래 하고 있는 것보다 더 장황하지 않습니다.

확인. 그럴 수 있지. 별도의 문제를 열겠습니까, 아니면 이 문제의 이름을 변경하시겠습니까?

별도의 문제가 좋을 것입니다.

원래 하고 있는 것보다 더 장황하지 않습니다.

더 이상 장황하지 않지만 많은 사람들이 단순히 그 구문을 싫어한다는 사실을 고려하기를 바랍니다. 좋든 나쁘든 많은 사람들이 DX 데코레이터가 제공하는 것을 선호합니다.

별도의 문제가 좋을 것입니다.

내일 하나를 입력하고 컨텍스트를 위해 이 링크에 연결하겠습니다.

이 작업을 도와주셔서 감사합니다. :)

내가 들어갈 수 있다면, @masaeedu 나는 이 진술에 동의하지 않습니다:

원하는 것은 특별히 데코레이터와 관련이 없습니다. 문제는 TypeScript의 "이봐 TypeScript, 이 구조에 대해 당신이 전혀 알지 못하는 일이 일어나고 있습니다. 이에 대해 모두 말하겠습니다"라고 말하는 메커니즘이 현재 너무 제한적이라는 것입니다. 지금은 인터페이스 병합만 있지만 함수가 인수에 인터페이스 병합을 적용할 수 있기를 원합니다. 이는 어떤 식으로든 데코레이터와 특별히 관련이 없습니다.

확실히 TypeScript는 클래스 데코레이터의 반환 유형 을 보고 돌연변이된 클래스가 어떤 유형이어야 하는지 알아낼 수 있습니다. "인수에 인터페이스 병합 적용"이 필요하지 않습니다. 내가 보기에 그것은 전적으로 데코레이터와 관련이 있습니다.

또한 연결된 구성 요소에 더 이상 props가 필요하지 않다는 것을 TypeScript가 알지 못하는 경우는 React 및 TypeScript와 함께 Redux를 사용하는 것을 꺼리게 한 측면 중 하나입니다.

@codeandcats 잘 작동합니까? https://github.com/Zalastax/openschedule/blob/335ee3834122da7f65ba35f89d8fd737309fc4fb/src/components/week-selection/index.tsx _ .tsx

@codeandcats 쓰레드가 시작된 이후로 나는 이것과 함께 서클에 들어가고 있으며 더 이상 할 수 없습니다. 앞의 토론을 주의 깊게 살펴보고 실제로 내가 @arackaf 에 대해 동의하지 않는 부분을 이해하려고 노력하십시오.

<strong i="8">@bar</strong> class Foo { } 을 할 때 Foo 의 유형은 bar 의 반환 유형이어야 한다는 데 동의합니다. Foo this #$가 어떤 식으로든 영향을 받아야 한다는 데 동의하지 않습니다. connect 를 사용하는 것은 여기서 경합의 요점과 전혀 관련이 없습니다. 왜냐하면 connect 는 장식된 구성 요소가 프로토타입에 추가하는 멤버를 인식하고 사용할 것으로 기대하지 않기 때문입니다.

나는 당신이 @masaeedu 에 좌절했다는 것을 이해할 수 있지만, 내가 이 앞뒤로 적극적으로 내 의견을 표명하지 않았다고 해서 지난 48시간 동안 내가 토론을 팔로우하지 않았다고 생각하지 마십시오 - 그러니 제발 겸손한 친구를 살려주세요.

내가 이해하는 한, 당신은 데코레이팅된 클래스 내부에서 데코레이터에 의해 자체적으로 만들어진 돌연변이에 대해 알면 안 된다고 생각하지만 외부에서는 알아야 합니다. 나는 그것에 동의하지 않습니다. @arackaf 가 클래스 내부에서 변형된 버전을 봐야 한다고 생각한다는 사실은 내 의견의 요지와 다릅니다.

어느 쪽이든 TypeScript는 데코레이터 함수에서 반환된 유형을 클래스의 정보 소스로 사용할 수 있습니다. 따라서 이것은 당신이 제안한 것처럼 새로운 기괴한 인수 돌연변이 기능이 아니라 데코레이터 문제입니다.

@Zalastax 데코레이터 기능을 데코레이터가 아닌 함수로 사용하고 있습니다. 적용해야 하는 데코레이터가 여러 개인 경우 중첩해야 합니다. 이는 기술적으로 더 이상 장황하지 않지만 구문적으로는 즐겁지 않습니다. 무슨 말인지 아십니까?

겸손 등

소음.

@arackaf 가 클래스 내부에서 변형된 버전을 봐야 한다고 생각한다는 사실은 내 의견의 요지와 다릅니다.

그것은 당신이 응답하고 있는 단락의 중심점이므로, 당신이 다른 것에 대해 이야기하고 있다면 그것은 부적절합니다. @arackaf 가 원하는 것은 대략적으로 함수 인수에 대한 인터페이스 병합입니다. 이것은 데코레이터와 독립적인 기능으로 더 잘 해결됩니다. 당신이 원하는 것은 (내가 원하는 것과 분명히 동일함) <strong i="12">@foo</strong> class Foo { } 가 Foo 에 대해 const Foo = foo(class { }) 와 같은 유형 서명을 생성하지 않는 TypeScript의 버그를 수정하는 것입니다.

내가 이해하는 한, 당신은 데코레이팅된 클래스 내부에서 데코레이터에 의해 자체적으로 만들어진 돌연변이에 대해 알면 안 된다고 생각하지만 외부에서는 알아야 합니다. 나는 그것에 동의하지 않는다

우리가 동의하는 것에 대해 이야기하기로 결정했지만 "나는 이 진술에 동의하지 않습니다"로 시작한다면, 당신은 시간 낭비일 뿐입니다.

이 소금으로 감자 튀김을 먹을 수 있습니까?

아, 알겠습니다. 동료를 애용하는 것은 벌금이지만 사람들이 당신을 끌어들인다면 그것은 소음입니다.

@arackaf가 제안한 것을 구현하기 위해 "인수 돌연변이" 개념이 필요한 이유를 모르겠습니다.

우리가 @arackaf 에 동의하는지 여부에 관계없이 내 겸손한 의견으로는 TypeScript가 데코레이터 결과에서 실제 유형을 단순히 추론할 수 있습니다.

수치심을 느끼셨다면 사과드립니다. 의도는 당신을 얻는 것이 었습니다.
사실 누구나 용서할 수 있는 거대한 엉성한 실
스키밍. 당신이 인식하지 못하는 것이 여전히 매우 분명하기 때문에 나는 이것을 지지합니다
에 대한 오해로 인해 나와 "동의하지 않습니다".
내 위치.

예를 들어, 인터페이스가 함수에 병합되는 이유에 대한 귀하의 질문
주장은 아담의 문제를 해결하는 가장 좋은 방법은 관련 항목을 살펴보는 것입니다.
Adam과의 토론에서 그는 이미 인터페이스 병합을 사용하고 있다고 말합니다.
그러나 각 선언 사이트에서 이 작업을 수행해야 하는 것은 성가신 일입니다.

나는 이것의 모든 기술적 측면이 죽도록 두들겨 맞았다고 생각합니다. 나
스레드가 대인 문제에 의해 지배되는 것을 원하지 않으므로 이것은
내 마지막 게시물이 될 것입니다.

사실, 데코레이터에는 두 가지 버그가 있습니다. 반환 유형이 존중되지 않고 클래스 내부에서 추가된 멤버가 존중되지 않습니다(클래스 내부 this ). 그리고 예, 전자가 더 쉽게 해결할 수 있기 때문에 후자에 더 관심이 있습니다.

여기에 별도의 케이스를 열었습니다. https://github.com/Microsoft/TypeScript/issues/16599

안녕하세요 여러분, 저는 주말 동안 이 대화를 놓쳤습니다. 그리고 아마도 지금 다시 가져올 이유가 많지 않을 것입니다. 그러나 나는 이러한 종류의 토론이 뜨겁다는 것을 모두에게 상기시키고 싶습니다. 일반적으로 참여하는 모든 사람은 선의입니다. 정중한 어조를 유지하면 대화를 명확하게 하고 방향을 잡는 데 도움이 되며 새로운 참여자를 육성할 수 있습니다. 이렇게 하는 것이 항상 쉬운 것은 아니지만(특히 인터넷이 독자에게 색조를 맡길 때), 미래 시나리오에서는 이것이 중요하다고 생각합니다. 😃

이에 대한 상태는 어떻습니까?

@alex94puchades 아직 2단계 제안 이므로 아직 시간이 좀 남아 있습니다. TC39는 적어도 약간의 움직임이 있는 것으로 보입니다 .

이 의견 에 따르면 빠르면 11월에 3단계를 제안할 수 있을 것으로 보입니다.

데코레이터로 함수 서명을 변경하는 해결 방법

빈 와퍼 함수 추가

export default function wapper (cb: any) {
    return cb;
}

정의 추가

export function wapper(cb: IterableIterator<0>): Promise<any>;

결과

<strong i="13">@some</strong> decorator // run generator and return promise
function *abc() {}

wapper(abc()).then() // valid

/핑

누군가 이것에 대한 해결책을 찾고 있다면 내가 생각해낸 한 가지 해결 방법이 아래에 있습니다.

중첩된 개체가 필요하기 때문에 최상의 솔루션은 아니지만 실제로 데코레이터의 속성이 클래스 인스턴스의 평면이 아니라 개체에 있기를 원했기 때문에 잘 작동합니다.

이것은 내가 Angular 5 모달에 사용하는 것입니다.

사용자 정의 ConfirmModalComponent 에 사용할 수 있는 @ModalParams(...) 데코레이터가 있다고 가정합니다. @ModalParams(...) 데코레이터의 속성을 내 사용자 지정 구성 요소에 표시하려면 데코레이터가 값을 할당할 속성이 있는 기본 클래스를 확장해야 합니다.

예를 들어:

export class Modal {
    params: any;

    constructor(values: Object = {}) {
        Object.assign(this, values);
    }
}

export function ModalParams (params?: any) {
    return (target: any): void  => {
        Object.assign(target.prototype, {
            params: params
        });
    };
}

@Component({...})
@ModalOptions({...})
@ModalParams({
    width:             <number> 300,
    title:             <string> 'Confirm',
    message:           <string> 'Are you sure?',
    confirmButtonText: <string> 'Yes',
    cancelButtonText:  <string> 'No',
    onConfirm:         <(modal: ConfirmModalComponent) => void> (() => {}),
    onCancel:          <(modal: ConfirmModalComponent) => void> (() => {})
})
export class ConfirmModalComponent extends Modal {
    constructor() {
        super();
    }

    confirm() {
        this.params.onConfirm(this); // This does not show a syntax error 
    }

    cancel() {
        this.params.onCancel(this); // This does not show a syntax error 
    }
}

다시 말하지만, 그것은 매우 아름답지는 않지만 내 사용 사례에 잘 작동하므로 다른 사람이 유용하다고 생각했습니다.

@lansana 하지만 유형을 얻지 못합니까?

@confraria 불행히도 그렇지는 않지만 확장하는 일반 Modal 클래스를 구현하면 이를 달성할 수 있는 방법이 있을 수 있습니다. 예를 들어 다음과 같은 것이 작동할 수 있습니다(테스트되지 않음).

export class Modal<T> {
    params: T;
}

export function ModalParams (params?: any) {
    return (target: any): void  => {
        Object.assign(target.prototype, {
            params: params
        });
    };
}

// The object in @ModalParams() should be of type MyType
@ModalParams({...})
export class ConfirmModalComponent extends Modal<MyType> {
    constructor() {
        super();
    }
}

:/ 네, 하지만 유형이 데코레이터에서 분리되고 확실히 둘 중 두 개를 사용할 수 없습니다.:(게다가 클래스가 메서드를 구현하지 않으면 오류가 발생합니다. 현재 이 패턴에 맞는 유형을 얻는 방법입니다.

예, 이것이 가능하면 TypeScript를 훨씬 더 훌륭하고 표현력 있게 만들 수 있습니다. 바라건대 곧 무언가가 올 것입니다.

@lansana 예, 요점은 클래스 데코레이터가 클래스가 다른 것을 확장하거나 구현할 필요 없이 자체적으로 클래스의 서명을 변경할 수 있으면 좋을 것입니다(노력과 유형 정보의 중복이기 때문에) .

참고 사항: 귀하의 예제에서 params 는 개체 참조이기 때문에 장식된 모달 구성 요소 클래스의 모든 인스턴스에서 정적일 수 있다는 점에 유의하십시오. 비록 그것이 의도한 것일 수도 있지만. : - ) 하지만 나는 빗나간다...

편집: 이것에 대해 생각하면서 데코레이터가 클래스 서명을 수정할 수 있도록 하는 것의 단점을 알 수 있습니다. 클래스 구현에 특정 유형 주석이 분명히 포함되어 있지만 데코레이터가 이 모든 것을 급습하고 변경할 수 있다면 개발자에게 약간의 비열한 트릭이 될 것입니다. 많은 사용 사례는 분명히 새 클래스 논리를 통합하는 것과 관련이 있으므로 불행히도 대부분은 확장 또는 인터페이스 구현을 통해 더 쉽게 촉진될 것입니다. 또한 기존 클래스 서명과 조정되고 충돌이 발생하는 경우 적절한 오류가 발생합니다. Angular와 같은 프레임워크는 물론 클래스를 보강하기 위해 데코레이터를 많이 사용하지만 디자인은 클래스가 자체 구현에서 사용할 수 있는 데코레이터로부터 새로운 로직을 "얻거나" 혼합하도록 허용하지 않습니다. 프레임워크 조정 논리의 클래스 논리. 그것은 어쨌든 나의 _겸손한_ 의견입니다. : - )

데코레이터 + 핵보다는 고차 클래스를 사용하는 것이 더 나은 것 같습니다. 나는 사람들이 이 물건에 데코레이터를 사용하고 싶어한다는 것을 알고 있지만 compose + HOC를 사용하는 것이 갈 길이며 아마도 이런 식으로 유지될 것입니다... 영원히 ;) MS 등에 따르면 데코레이터는 메타데이터를 클래스에만 첨부하기 위한 것입니다. Angular와 같은 데코레이터의 큰 사용자를 확인하면 이 용량에서만 사용된다는 것을 알 수 있습니다. 그렇지 않으면 TypeScript 유지 관리자를 설득할 수 있을지 의심됩니다.

진정한 기능 구성을 가능하게 하고 그러한 참여를 생성하는 그러한 강력한 기능이 TS 팀에서 오랫동안 무시되어 왔다는 것은 슬프고 약간 이상합니다.

이것은 실제로 우리가 코드를 작성하는 방법에 혁명을 일으킬 수 있는 기능입니다. 모든 사람이 Bitly 또는 NPM과 같은 것에 대한 작은 믹스인을 릴리스하고 Typescript에서 정말 멋진 코드 재사용을 할 수 있습니다. 내 자신의 프로젝트에서 나는 즉시 @Poolable @Initable @Translating 을 만들고 아마도 더 많이 만들 것입니다.

모든 강력한 TS 코어 팀을 부탁합니다. 구현에 "필요한 모든 것"은 반환된 인터페이스가 존중되어야 한다는 것입니다.

// taken from my own lib out of context
export function Initable<T extends { new(...args: any[]): {} }>(constructor: T): T & Constructor<IInitable<T>> {
    return class extends constructor implements IInitable<T> {
        public init(obj: Partial<T> | any, mapping?: any) {
            setProperties(this, obj, mapping);
            return this
        }
    }
}

이 코드를 불만 없이 실행할 수 있습니다.

<strong i="14">@Initable</strong>
class Person {
    public name: string = "";
    public age: number = 0;
    public superPower: string | null = null;
}
let sam = new Person();

sam.init({age: 17, name: "Sam", superPower: "badassery"});

@AllNamesRTake

귀하의 요점에 동의하지만 다음과 같이 동일한 것을 달성할 수 있습니다.

class Animal {
    constructor(values: Object = {}) {
        Object.assign(this, values);
    }
}

그런 다음 init 함수가 필요하지도 않습니다. 다음과 같이 하면 됩니다.

const animal = new Animal({name: 'Fred', age: 1});

@lansana
네, 하지만 그렇게 하면 내가 원하는 것이 항상 슈퍼 듀퍼가 아닌 내 생성자가 오염될 것입니다.

또한 풀링 가능한 개체 및 기타 항목을 만들기 위해 유사한 믹스인이 있습니다. 구성을 통해 기능을 추가할 수 있는 가능성만 있으면 됩니다. init 예제는 생성자를 더럽히지 않고 수행한 작업을 수행하는 데 필요한 방법이므로 다른 프레임워크에서 유용합니다.

@AllNamesRTaken 오랫동안 이 상태에 있었고 제안이 이미 2단계에 있기 때문에 지금 데코레이터를 건드려도 소용이 없습니다. https://github.com/tc39/proposal-decorators 가 완료될 때까지 기다리세요. 그러면 모든 사람이 동의하는 형식으로 가져올 것입니다.

@쿠키몬스타
내가 요청하는 것은 순전히 기능이 아니라 유형에 관한 것이기 때문에 나는 당신에게 강력하게 동의하지 않습니다. 따라서 ES 물건과 관련이 있다면 별로 없습니다. 위의 내 솔루션은 이미 작동하지만 캐스트하고 싶지 않습니다..

@AllNamesRTaken 경고가 전혀 없는 믹스인으로 _오늘_ 이 작업을 수행할 수 있습니다.

function setProperties(t: any, o: any, mapping: any) {}

type Constructor<T> = { new(...args: any[]): T };

interface IInitable<T> {
  init(obj: Partial<T> | any, mapping?: any): this;
}

// taken from my own lib out of context
function Initable<T extends Constructor<{}>>(constructor: T): T & Constructor<IInitable<T>> {
    return class extends constructor implements IInitable<T> {
        public init(obj: Partial<T> | any, mapping?: any) {
            setProperties(this, obj, mapping);
            return this
        }
    }
}

class Person extends Initable(Object) {
    public name: string = "";
    public age: number = 0;
    public superPower: string | null = null;
}
let sam = new Person();
sam.init({age: 17, name: "Sam", superPower: "badassery"});

앞으로 믹스인 제안을 JS로 가져오면 다음과 같이 할 수 있습니다.

mixin Initable {
  public init(obj: Partial<T> | any, mapping?: any) {
    setProperties(this, obj, mapping);
    return this
  }
}

class Person extends Object with Initable {
    public name: string = "";
    public age: number = 0;
    public superPower: string | null = null;
}
let sam = new Person();
sam.init({age: 17, name: "Sam", superPower: "badassery"});

@justinfagnani mixin은 내가 이러한 기능을 시작하는 방법이었고 내 구현은 실제로 다음과 같이 작동합니다.

class Person extends Initable(Object) {
    public name: string = "";
    public age: number = 0;
    public superPower: string | null = null;
}
let sam = new Person();     
sam.init({age: 17, name: "Sam", superPower: "badassery"});

이것은 해결 방법으로 멋지지만 데코레이터가 내 의견으로는 유형을 변경할 수 있도록 허용하는 장점을 실제로 제거하지는 않습니다.

편집 : 또한 init에 대한 부분에서 타이핑을 느슨하게 합니다.

이 기능을 사용하면 HoC를 더 쉽게 작성할 수 있습니다.
이 기능이 추가되기를 바랍니다

@kgtkr 그게 내가 이것을 간절히 원하는 주된 이유입니다 ...

react-router 정의에 약간의 비상이 있습니다. 일부 사람들은 클래스 데코레이션 인터페이스를 갖는 것보다 유형 안전성이 더 중요하다고 결정했기 때문입니다. 맨 아래 이유는 withRouter 가 일부 소품을 선택 사항으로 만들기 때문입니다.

이제 사람들이 장식 대신 withRouter 의 기능 인터페이스를 사용하도록 강요받는 불화가 있는 것 같습니다.

이 기능을 해결하기 시작하면 세상이 더 행복한 곳이 될 것입니다.

같은 불화*가 얼마 ​​전에 material-ui 타이핑과 withStyle 에서 발생했습니다. 이는 데코레이터로 사용하도록 설계되었지만 TypeScript 사용자가 안전하게 사용하려면 다음을 사용해야 합니다. 정규 기능으로. 먼지가 대부분 해결되었지만 프로젝트를 처음 접하는 사람들에게는 지속적인 혼란의 원인이 됩니다!

* 글쎄, "불화"는 강한 단어 일 수 있습니다

나는 이것을 오랫동안 지켜보았고, 그것이 도착할 때까지 다른 사람들이 앞으로 호환되는 방식으로 이 동작을 달성하기 위해 나의 작은 해킹으로부터 이익을 얻을 수 있기를 바랍니다. 그래서 여기, 아주 기본적인 스칼라 스타일의 케이스 클래스 copy 메소드를 구현했습니다...

다음과 같이 데코레이터를 구현했습니다.

type Constructor<T> = { new(...args: any[]): T };

interface CaseClass {
  copy(overrides?: Partial<this>): this
}

function CaseClass<T extends Constructor<{}>>(constructor: T): T & Constructor<CaseClass> {
  return class extends constructor implements CaseClass {
    public copy(overrides: Partial<this> = {}): this {
      return Object.assign(Object.create(Object.getPrototypeOf(this)), this, overrides);
    }
  }
}

이 코드는 copy 메서드가 연결된 익명 클래스를 만듭니다. 데코레이터를 지원하는 환경에서 JavaScript에서 예상대로 정확하게 작동합니다.

TypeScript에서 이것을 사용하고 실제로 유형 시스템이 대상 클래스의 새 메서드를 반영하도록 하려면 다음 해킹을 사용할 수 있습니다.

class MyCaseClass extends CaseClass(class {
  constructor(
    public fooKey: string,
    public barKey: string,
    public bazKey: string
  ) {}
}) {}

MyCaseClass CaseClass 데코레이터 내부의 익명 클래스에서 상속된 copy 메서드에 대한 입력을 노출합니다. 그리고 TypeScript가 선언된 유형의 변형을 지원하면 이 코드는 예기치 않은 오류 없이 일반적인 데코레이터 구문 <strong i="18">@CaseClass</strong> etc 으로 쉽게 수정할 수 있습니다.

다음 주요 TypeScript 릴리스에서 이것을 볼 수 있다면 좋을 것입니다. 프록시 클래스의 이상한 엉망을 내보내는 대신 더 깨끗하고 간결한 코드를 만드는 데 도움이 될 것이라고 믿습니다.

이 기능은 언제 사용할 수 있습니까?

반복되는 작업을 처리하기 위해 클래스 데코레이터를 사용하고 싶었습니다.
하지만 이제 클래스를 초기화할 때 다음 오류가 발생합니다. Expected 0 arguments, but got 1

function Component<T extends { new(...args: any[]): {} }>(target: T) {
    return class extends target {
        public constructor(...args: any[]) {
            super(...args);
            resolveDependencies(this, args[0])
        }
    }
}

<strong i="8">@Component</strong>
export class ExampleService {
    @Inject(ExampleDao) private exampleDao: ExampleDao;

    // <strong i="9">@Component</strong> will automatically do this for me 
    // public constructor(deps: any) {
    //  resolveDependencies(this, deps);
    // }

    public getExample(id: number): Promise<Example | undefined> {
        return this.exampleDao.getOne(id);
    }
}

new ExampleService({ exampleDao }) // TS2554: Expected 0 arguments, but got 1.

이 기능이 곧 제공되기를 바랍니다! :)

@iainreid820 이 접근 방식을 사용하면서 이상한 버그를 경험하셨나요?

오랜 기다림! 그동안 현재 로드맵에 있는 문제로 이 문제가 해결되고 있습니까?
문제 5453 과 같은?

저는 Material UI 를 사용하고 있으며 TypeScript가 withStyles 에 대한 데코레이터 구문을 지원하지 않는다는 것을 깨달았습니다. https://material-ui.com/guides/typescript/#decorating -components

다음 TypeScript 릴리스에서 해당 제한을 수정하십시오. 클래스 데코레이터는 지금 나에게 꽤 쓸모없는 것 같습니다.

Morphism Js 의 메인테이너로서 이것은 이러한 종류의 라이브러리에 대한 큰 한계입니다. 나는 함수 데코레이터의 소비자가 함수 https://github.com/nobrainr/morphism# --toclassobject-decorator의 대상 유형을 지정해야 하는 것을 피하고 싶습니다. 그렇지 않으면 HOF 대신 데코레이터를 사용하는 것이 약간 쓸모없는 것처럼 들립니다. 😕
이에 대처할 계획이 있습니까? 이 기능을 구현하는 데 도움이 되는 방법이 있습니까? 미리 감사합니다!

@bikeshedder 머티리얼 UI 예제는 클래스 믹스인 사용 사례이며 믹스인에서 올바른 유형을 얻을 수 있습니다. 대신에:

const DecoratedClass = withStyles(styles)(
  class extends React.Component<Props> {
...
}

쓰다:

class DecoratedClass extends withStyles(styles)(React.Component<Props>) {
...
}

@justinfagnani 그것은 나를 위해 작동하지 않습니다 :

내 코드는 다음과 같습니다. https://gist.github.com/G-Rath/654dff328dbc3ae90d16caa27a4d7262

@G-Rath 대신 new () => React.Component<Props, State> 가 작동해야 한다고 생각합니까?

@emyann 주사위가 없습니다. 새 코드로 요지를 업데이트했지만 이것이 의미하는 바입니까?

class CardSection extends withStyles(styles)(new () => React.Component<Props, State>) {

형식을 지정해도 extends withStyles(styles)(...) 는 기본적으로 적절한 제안처럼 들리지 않습니다. withStyles는 클래스 믹스인이 아닙니다.

withStyles는 A 구성 요소 클래스를 사용하여 $ B 클래스를 생성합니다. 이 클래스는 렌더링될 때 A 클래스를 렌더링하고 여기에 소품 + classes 소품을 전달합니다.

withStyles의 반환 값을 확장하면 실제로 classes 소품을 받는 A 클래스를 구현하는 대신 B 래퍼를 확장하게 됩니다.

형식에 관계없이 extends withStyles(styles)(...) 기본적으로 적절한 제안처럼 들리지 않습니다. withStyles는 클래스 믹스인이 아닙니다.

물론. 왜 여기에 많은 반발이 있는지 잘 모르겠습니다.

즉, 데코레이터는 3단계에 매우 가깝기 때문에 TS가 곧 적절한 지원을 받을 것이라고 생각합니다.

나는 더 깨끗한 구문을 원하는 사람들의 말을 듣습니다. 여러 HoC를 데코레이터로 적용할 때. 우리가 사용하는 임시 해결 방법은 실제로 파이프 함수 내부에 여러 데코레이터를 래핑한 다음 해당 순수 함수를 사용하여 구성 요소를 장식하는 것입니다. 예

@flow([
  withStyles(styles),
  connect(mapStateToProps),
  decorateEverything(),
])
export class HelloWorld extends Component<Props, State> {
  ...
}

여기서 flow 는 lodash.flow 입니다. 많은 유틸리티 라이브러리가 recompose , Rx.pipe 등과 같은 것을 제공하지만 라이브러리를 설치하지 않으려면 물론 간단한 파이프 함수를 작성할 수 있습니다.

데코레이터를 사용하지 않는 것보다 읽기가 더 쉽습니다.

export const decoratedHelloWorld = withStyles(styles)(
  connect(mapStateToProps)(
    decorateEverything(
       HelloWorld
))))

내가 이것을 사용하는 또 다른 이유는 데코레이터 사양이 발표되고 적절하게 지원되면 이 패턴을 쉽게 찾고 교체할 수 있기 때문입니다.

@justinfagnani 이상하게 extends React.Component<Props, State> 를 extends withStyles(styles)(React.Component<Props, State>) 로 변경하려고 하면 ESLint에서 구문 오류가 발생하므로 동일한 방식으로 @G-Rath의 유형 오류를 확인할 수 없습니다.

하지만 다음과 같이 하면 new 문제(같은 문제일 수도?)가 나타납니다.

class MyComponent extends React.Component<Props, State> {
  /* ... */
}

const _MyComponent = withStyles(styles)(MyComponent)
const test = new _MyComponent // <--------- ERROR

오류는 다음과 같습니다.

Cannot use 'new' with an expression whose type lacks a call or construct signature.

이것은 Material UI에서 반환된 유형이 생성자가 아님을 의미합니까(그래야 하지만)?

@sagar-sm 하지만 Material UI 유형으로 보강된 올바른 유형을 얻었습니까? 당신이 할 것 같지 않습니다.

참고로 저는 Material UI의 withStyles 를 데코레이터로 사용하려고 했기 때문에 이것을 우연히 발견했는데 작동하지 않아 다음 질문을 했습니다. https://stackoverflow.com/questions/53138167

이것이 필요하면 비동기 함수를 bluebird로 반환할 수 있습니다.

비슷한 일을 하려고 했습니다. ATM 다음 해결 방법을 사용하고 있습니다.

먼저 내 "mixin" 데코레이터가 있습니다.

export type Ctor<T = {}> = new(...args: any[]) => T 
function mixinDecoratorFactory<MixinInterface>() {
    return function(toBeMixed: MixinInterface) {
        return function<MixinBase extends Ctor>(MixinBase: MixinBase) {
            Object.assign(MixinBase.prototype, toBeMixed)
            return class extends MixinBase {} as MixinBase & Ctor<MixinInterface>
        }
    }
}

인터페이스에서 데코레이터 만들기

export interface ComponentInterface = {
    selector: string,
    html: string
}
export const Component = mixinDecoratorFactory<ComponentInterface>();

그리고 그것이 내가 사용하는 방법입니다.

@Component({
    html: "<div> Some Text </div>",
    selector: "app-test"
})
export class Test extends HTMLElement {
    test = "test test"
    constructor() {
        super()
        console.log("inner;     test:", this.test)
        console.log("inner;     html:", this.html)
        console.log("inner; selector:", this.selector)
    }
}

export interface Test extends HTMLElement, ComponentInterface {}
window.customElements.define(Test.prototype.selector, Test)


const test = new Test();
console.log("outer;     test:", test.test)
console.log("outer;     html:", test.html)
console.log("outer; selector:", test.selector)

트릭은 병합 선언을 만들기 위해 클래스와 동일한 이름으로 인터페이스를 만드는 것입니다.
여전히 클래스는 Test 유형으로만 표시되지만 typescript의 검사는 작동합니다.
@ -Notation 없이 데코레이터를 사용하는 경우 단순히 함수로 호출하면 올바른 교차 유형을 얻을 수 있지만 사용할 수 없기 때문에 클래스 자체 내부에서 유형 검사 기능을 잃게 됩니다. 인터페이스 속임수가 더 이상 없고 더 보기 흉해 보입니다. 예:

let Test2Comp = Component({
    html: "<div> Some Text 2 </div>",
    selector: "app-test2"
}) (
class Test2 extends HTMLElement {
    test = "test test"
    constructor() {
        super()
        console.log("inner;     test:", this.test)
        console.log("inner;     html:", this.html)     // no
        console.log("inner; selector:", this.selector) // no
    }
})

interface Test2 extends HTMLElement, ComponentInterface {} //no
window.customElements.define(Test2Comp.prototype.selector, Test2Comp)

const test2 = new Test2Comp();
console.log("outer;     test:", test2.test)
console.log("outer;     html:", test2.html)
console.log("outer; selector:", test2.selector)

이러한 접근 방식에 대해 어떻게 말합니까? 아름답지는 않지만 해결 방법으로 작동합니다.

이 문제에 진전이 있습니까? 이것은 매우 다양한 가능성을 열어주는 매우 강력한 기능처럼 보입니다. 데코레이터가 아직 실험 단계이기 때문에 이 문제는 현재 대부분 부실하다고 가정합니다.

@andy-ms @ahejlsberg @sandersn에 대한 공식 성명을 낸다면 정말 좋을 것입니다. 🙏

데코레이터가 완료될 때까지 여기서 아무 것도 하지 않을 것입니다.

@DanielRosenwasser - 여기서 "완료"란 무엇을 의미합니까? TC39의 3단계에 해당합니까?

그들이 그렇게 멀리 갈 줄 몰랐어요! 그들은 언제 3단계에 이르렀습니까? 최근인가요?

그들은 아직 하지 않았다; 나는 그들이 1월 TC39 회의에서 다시 2단계에서 3단계로 발전할 것이라고 믿습니다.

의제 에 대한 자세한 내용을 확인할 수 있습니다.

맞습니다(1월에 진급할 예정인지 확인할 수는 없지만). 나는 단지 그들이 거기에 도착 했을 때 3단계가 자격이 되는지 묻고 있었습니다.

내 생각에 데코레이터 제안은 여전히 ​​심각한 문제가 많아서 1월에 3단계로 넘어가면 문제가 되는 클래스 필드 제안과 globalThis 제안처럼 다시 실수를 하게 될 것이다.

@hax 자세히 설명해 주시겠습니까?
나는 이것을 정말로 원하고 슬프게도 문제에 대한 의사 소통의 부족을 발견하고 불행히도 문제에 대해 듣지 못했습니다.

@AllNamesRTaken 데코레이터 제안 문제 목록을 확인하세요. 😆 예를 들어 export before/after 데코레이터 인수는 3단계 차단입니다.

API 재설계와 같은 몇 가지 제안된 변경 사항도 있습니다. 이는 제안이 3단계에서 안정적이지 않다는 것을 의미한다고 생각합니다.

그리고 문제가 되는 클래스 필드 제안과도 관련이 있습니다. 클래스 필드가 3단계에 이르렀지만 문제가 너무 많습니다. 내가 걱정하는 큰 문제는 많은 문제를 데코레이터(예: protected )에게 맡기고 두 제안 모두에 좋지 않다는 것입니다.

참고로 저는 TC39 대리인이 아니며 일부 TC39 대리인은 많은 문제의 현재 상태에 대한 내 의견에 결코 동의하지 않습니다. (특히 나는 현재 TC39 프로세스가 많은 논란의 여지가 있는 문제에서 큰 실패를 겪고 있다는 강한 의견을 가지고 있습니다. 일부 문제를 데코레이터에게 연기하는 것은 문제를 실제로 해결하지 못하고 데코레이터 제안을 더 취약하게 만듭니다.)

나는 그런 것들이 파악되고 제안이 괜찮을 것이라고 생각하지만, 여기서 제안의 상태에 대해 논의하지 않는 것이 좋습니다.

충분한 확신이 있는 3단계 또는 4단계가 아마도 새로운 제안을 구현하고 이 문제를 살펴볼 수 있는 단계라고 생각합니다.

감사합니다 다니엘! 3단계는 일반적으로 4에 대한 강한 확신을 의미하므로 1월 회의에 대해 손가락이 교차했습니다.

그리고 여기에서 데코레이터 토론을 시작해주셔서 감사합니다. 이 기능으로 인해 분노와 자전거 발산의 수준이 기괴합니다. 나는 그런 것을 본 적이 없다 😂

기록을 위해 같은 것에 대한 기능 요청이 있었습니다: https://github.com/Microsoft/TypeScript/issues/8545

짜증나게 충분히 TypeScript는 JavaScript에서 컴파일할 때 이 기능을 어느 정도 지원합니다(https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#better-handling-for-namespace-patterns-in -js 파일):

// javascript via typescript
var obj = {};
obj.value = 1;
console.log(obj.value);

TypeScript 코드 자체의 경우에도 함수(!)(https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#properties-declarations-on-functions)에 관해서 만 :

function readImage(path: string, callback: (err: any, image: Image) => void) {
    // ...
}

readImage.sync = (path: string) => {
    const contents = fs.readFileSync(path);
    return decodeImageSync(contents);
}

@DanielRosenwasser @arackaf 3단계로 넘어가는 제안에 대해 말씀해 주시겠습니까? 데코레이터를 사용할 때 클래스에 프로토타입 기능을 추가하는 라이브러리를 구축하려고 합니다.

그들은 최신 TC39 회의에서 진척되지 않았습니다. 그들은 다음 회의에서 다시 승진할 수 있습니다. 그러나 그것은 불분명합니다. 이 시점에서 제안에 대해 많은 이야기가 있습니다.

여기 관심 있는 사람들 은 제안 자체를 추적하는 것이 좋습니다. 그러면 스레드를 보고 있는 사람들과 TS 유지 관리자를 위해 소음을 줄일 수 있습니다.

이것에 대한 업데이트가 있습니까?

해결 방법(각도 :)

import { Type } from '@angular/core';

export function ExtendsWithFakes<F1>(): Type<F1>;
export function ExtendsWithFakes<F1, F2>(): Type<F1 & F2>;
export function ExtendsWithFakes<F1, F2, F3>(): Type<F1 & F2 & F3>;
export function ExtendsWithFakes<F1, F2, F3, F4>(): Type<F1 & F2 & F3 & F4>;
export function ExtendsWithFakes<F1, F2, F3, F4, F5>(): Type<F1 & F2 & F3 & F4 & F5>;
export function ExtendsWithFakes<RealT, F1>(realTypeForExtend?: Type<RealT>): Type<RealT & F1>;
export function ExtendsWithFakes<RealT, F1, F2>(realTypeForExtend?: Type<RealT>): Type<RealT & F1 & F2>;
export function ExtendsWithFakes<RealT, F1, F2, F3>(realTypeForExtend?: Type<RealT>): Type<RealT & F1 & F2 & F3>;
export function ExtendsWithFakes<RealT, F1, F2, F3, F4>(
    realTypeForExtend?: Type<RealT>
): Type<RealT & F1 & F2 & F3 & F4>;
export function ExtendsWithFakes<RealT, F1, F2, F3, F4, F5>(
    realTypeForExtend?: Type<RealT>
): Type<RealT & F1 & F2 & F3 & F4 & F5> {
    if (realTypeForExtend) {
        return realTypeForExtend as Type<any>;
    } else {
        return class {} as Type<any>;
    }
}

interface IFake {
    fake(): string;
}

function UseFake() {
    return (target: Type<any>) => {
        target.prototype.fake = () => 'hello fake';
    };
}

class A {
    a() {}
}

class B {
    b() {}
}

@UseFake()
class C extends ExtendsWithFakes<A, IFake, B>(A) {
    c() {
        this.fake();
        this.a();
        this.b(); // failed at runtime
    }
}

이 "그동안" 쉬운 솔루션에 대해 어떻게 생각하십니까?
https://stackoverflow.com/a/55520697/1053872

Mobx-state-tree는 cast() 함수와 유사한 접근 방식을 사용합니다. 기분이 좋지는 않지만... 너무 귀찮게 하지도 않습니다. 더 좋은 것이 나올 때마다 꺼내기가 쉽습니다.

나는 이것의 라인에 따라 무언가를 할 수 있기를 원합니다 ❤️
이것이 바로 데코레이터가 가져야 할 힘이 아닐까요?

class B<C = any> {}

function ChangeType<T>(to : T) : (from : any) => T;
function InsertType<T>(from : T) : B<T>;

@ChangeType(B)
class A {}

// A === B

// or

<strong i="7">@InsertType</strong>
class G {}

// G === B<G>

const g = new G(); // g : B<G>

A === B // equals true

const a : B = new A();  // valid
const b = new B();

typeof a === typeof b // valid

데코레이팅된 클래스 속성을 입력하는 해결 방법을 만드는 데 상당한 시간을 할애했습니다. 이 스레드의 시나리오에 대한 실행 가능한 솔루션이 될 것이라고 생각하지 않지만 일부 부분은 유용할 수 있습니다. 관심 있으신 분들은 미디엄에서 제 글을 확인해주세요.

이 문제에 대한 업데이트가 있습니까?

이걸로 어떻게 해요?

이 문제의 결과는 무엇이며 현재 어떻게 작동합니까?

mixin-class를 사용하여 해당 효과를 얻을 수 있습니다.
https://mariusschulz.com/blog/mixin-classes-in-typescript

@Bnaya 는 지금 우리가 원하는 것이 완전히 아닙니다. ;).
데코레이터를 사용하면 구식 Java를 사용하는 것처럼 사용하지 않을 클래스를 만들지 않도록 할 수 있습니다. 데코레이터는 클래스가 핵심 기능을 계속 수행하고 추가로 일반화된 기능을 구성할 수 있는 매우 깨끗하고 깔끔한 구성 아키텍처를 허용합니다. 예, mixins는 할 수 있지만 반창고입니다.

데코레이터 제안이 지난 몇 달 동안 크게 변경되었습니다. TS 팀이 곧 호환되지 않을 현재 구현에 시간을 투자할 가능성은 매우 낮습니다.

다음 리소스를 시청하는 것이 좋습니다.

데코레이터 제안: https://github.com/tc39/proposal-decorators
TypeScript 로드맵: https://github.com/microsoft/TypeScript/wiki/Roadmap

@Bnaya 는 지금 우리가 원하는 것이 완전히 아닙니다. ;).
데코레이터를 사용하면 구식 Java를 사용하는 것처럼 사용하지 않을 클래스를 만들지 않도록 할 수 있습니다. 데코레이터는 클래스가 핵심 기능을 계속 수행하고 추가로 일반화된 기능을 구성할 수 있는 매우 깨끗하고 깔끔한 구성 아키텍처를 허용합니다. 예, mixins는 할 수 있지만 반창고입니다.

믹싱이 아니라 클래스입니다.
그 나쁜 카피-재료 믹스인이 아닙니다.
파이프라인 연산자가 도착하면 구문도 합리적입니다.

mixin-class를 사용하여 해당 효과를 얻을 수 있습니다.

클래스 팩토리 믹스인은 TypeScript에서 고통스러울 수 있습니다. 그렇지 않은 경우에도 믹스인으로 변환하기 위해 함수에서 클래스를 래핑해야 하므로 매우 상용구적입니다. 제3자 클래스를 가져오는 경우 간단히 할 수 없는 경우가 있습니다.

다음은 훨씬 더 좋고 간단하고 깨끗하며 가져온 타사 클래스와 함께 작동합니다. 레거시 스타일 데코레이터를 변환하는 것 외에는 변환 없이 일반 JavaScript에서 제대로 작동하지만 class es는 완전히 기본 class es로 유지됩니다.

class One {
    one = 1
    foo() { console.log('foo', this.one) }
}

class Two {
    two = 2
    bar() { console.log('bar', this.two) }
}

class Three extends Two {
    three = 3
    baz() { console.log('baz', this.three, this.two) }
}

@with(Three, One)
class FooBar {
    yeah() { console.log('yeah', this.one, this.two, this.three) }
}

let f = new FooBar()

console.log(f.one, f.two, f.three)
console.log(' ---- call methods:')

f.foo()
f.bar()
f.baz()
f.yeah()

그리고 Chrome의 출력은 다음과 같습니다.

1 2 3
 ---- call methods:
foo 1
bar 2
baz 3 2
yeah 1 2 3

이것은 모든 상용구 없이 클래스 팩토리 믹스인이 하는 일을 완전히 제공합니다. 클래스 주변의 함수 래퍼는 더 이상 필요하지 않습니다.

그러나 알다시피 데코레이터는 정의된 클래스의 유형을 변경할 수 없습니다. 😢

따라서 당분간은 다음 작업을 수행할 수 있습니다. 단, 보호된 구성원은 상속할 수 없다는 점만 유의하십시오.

// `multiple` is similar to `@with`, same implementation, but not a decorator:
class FooBar extends multiple(Three, One) {
    yeah() { console.log('yeah', this.one, this.two, this.three) }
}

보호된 멤버를 잃는 문제는 multiple 구현의 다음 두 가지 예에서 설명됩니다(유형에 관한 한 하지만 간결함을 위해 런타임 구현은 생략됨).

• 결합된 클래스의 모든 속성이 공용이기 때문에 오류가 없는 예제입니다 .
• 매핑된 유형이 보호된 멤버를 무시하기 때문에 오류가 있는 예 (맨 아래에 있음), 이 경우 Two.prototype.two 를 상속할 수 없게 만듭니다.

보호된 멤버를 포함하여 유형을 매핑하는 방법을 정말 원합니다.

클래스를 함수로 호출할 수 있는 데코레이터가 있기 때문에 이것은 나에게 정말 유용할 것입니다.

이것은 작동합니다:

export const MyClass = withFnConstructor(class MyClass {});

이것은 작동하지 않습니다:

<strong i="10">@withFnConstructor</strong>
export class MyClass {}

이 기능이 나올 때 청소하기 어렵지 않은 해결 방법은 선언 병합 및 사용자 지정 유형 정의 파일을 사용하여 수행할 수 있습니다.

이미 이것을 가지고:

// ClassModifier.ts
export interface Mod {
  // ...
}
// The decorator
export function ClassModifier<Args extends any[], T>(target: new(...args: Args) => T): new(...args: Args) => T & Mod {
  // ...
}

// MyClass.ts
<strong i="9">@ClassModifier</strong>
export MyClass {
  // ...
}

다음 파일을 추가합니다(기능이 나오면 제거할 파일).

// MyClass.d.ts
import { MyClass } from './MyClass';
import { Mod } from './ClassModifier';

declare module './MyClass' {
  export interface MyClass extends Mod {}
}

또 다른 가능한 해결 방법

declare class Extras { x: number };
this.Extras = Object;

class X extends Extras {
   constructor() {  
      super(); 
      // a modification to object properties that ts will not pick up
      Object.defineProperty(this, 'x', {value: 3});
   }
}

const a = new X()
a.x // 3

2015년에 시작했고 아직 보류 중입니다. 더 많은 관련 문제와 이 https://medium.com/p/caf24aabcb59/responses/show 와 같은 기사가 있습니다.

누군가가 이것에 대해 밝힐 수 있습니까? 아직 내부 논의도 고려 중인가?

tl;dr - 이 기능은 TC39에서 막혔습니다. 이것에 대해 TS 사람들을 전혀 비난할 수 없습니다. 표준이 될 때까지 구현하지 않을 것입니다.

그러나 이것은 Microsoft입니다. 그들은 그것을 구현한 다음 표준 사람들에게 말할 수 있습니다. "사람들이 이미 우리 버전을 사용하고 있습니다." :trollface:

여기서 문제는 TypeScript가 데코레이터를 구현한 이후로 데코레이터 제안이 _상당히_ 변경되었다는 것입니다(이전 버전과 호환되지 않는 방식으로). 일부 사람들은 TypeScript의 현재 데코레이터 동작과 의미 체계에 의존하고 있기 때문에 새 데코레이터가 완성되고 구현될 때 이는 고통스러운 상황으로 이어질 것입니다. TypeScript 팀이 이 문제에 대한 조치를 피하고 싶어할 것이라고 강력하게 의심합니다. 그렇게 하면 현재의 비표준 데코레이터를 더 많이 사용하게 되어 궁극적으로 새로운 데코레이터 구현으로의 전환이 훨씬 더 고통스러울 것이기 때문입니다. 본질적으로, 나는 개인적으로 이것이 일어나는 것을 보지 못합니다.

덧붙여서, 나는 최근에 꽤 견고한 해결 방법을 제공할 기능에 대한 제안인 #36348을 만들었습니다. 자유롭게 살펴보고/피드백을 제공/야만 합니다. 🙂

tl;dr - 이 기능은 TC39에서 막혔습니다. 이것에 대해 TS 사람들을 전혀 비난할 수 없습니다. 표준이 될 때까지 구현하지 않을 것입니다.

이러한 사실을 감안할 때 개발 팀이 빠른 설명과 상태 업데이트를 작성하고 TC39가 이를 필요한 단계로 이동할 때까지 이 대화를 잠그는 것이 현명할 수 있습니다.

이 글을 읽고 있는 누군가가 이 문제에 무게를 두고 있습니까?

사실, 거의 모든 데코레이터와 관련된 대화가 공중에 떠 있습니다. 예: https://github.com/Microsoft/TypeScript/issues/2607

데코레이터의 미래에 대한 명확성을 얻는 것은 기여자에게 필요한 기능을 구현하도록 요청하는 것이더라도 도움이 될 것입니다. 명확한 지도 없이 데코레이터의 미래는 흐릿하다

TypeScript 팀이 데코레이터 제안에 대한 적극적인 역할을 맡을 수 있다면 좋겠습니다. 저도 돕고 싶지만 아직 언어 개발 분야에서 일하지 않았기 때문에 어떻게 하면 가장 좋을지 잘 모르겠습니다 :-/

전체 팀과 TypeScript를 프로젝트로 말할 수는 없지만 데코레이터 구현이 TypeScript 구현에서 이미 한 번 분기된 방식을 고려할 때 해결되고 확인될 때까지 새로운 데코레이터 작업을 수행할 가능성은 거의 없습니다.

이 제안은 여전히 ​​활발히 개발 중이며 이번 주에 TC39에 올라왔습니다. https://github.com/tc39/proposal-decorators/issues/305

@orta 이 경우 클래스 데코레이터에 대한 문서를 업데이트해야 한다고 생각합니다. 그것은 말한다

클래스 데코레이터가 값을 반환하면 클래스 선언이 제공된 생성자 함수로 바뀝니다.

또한 문서의 다음 예제는 Greeter 인스턴스 유형에 newProperty 속성이 있음을 암시하는 것으로 보입니다. 이는 사실이 아닙니다.

function classDecorator<T extends {new(...args:any[]):{}}>(constructor:T) {
    return class extends constructor {
        newProperty = "new property";
        hello = "override";
    }
}

<strong i="13">@classDecorator</strong>
class Greeter {
    property = "property";
    hello: string;
    constructor(m: string) {
        this.hello = m;
    }
}

console.log(new Greeter("world"));

반환된 클래스의 인터페이스가 원래 인터페이스를 대체하지 않을 것이라는 점을 문서에 추가할 가치가 있다고 생각합니다.

흥미롭게도 TypeScript의 여러 이전 버전을 테스트했지만 해당 코드 샘플이 작동하는 경우를 찾을 수 없었습니다( 예: 3.3.3 ). 예, 동의합니다.

나는 https://github.com/microsoft/TypeScript-Website/issues/443 을 만들었습니다 - 누군가가 classDecorator에 명시적 교차 유형을 갖도록 만드는 방법을 알고 있다면 해당 문제에 대해 의견을 말하십시오.

위에 나열된 문서의 문제로 인해 혼란이 발생했기 때문에 여기에서 마무리했습니다. 데코레이터에서 반환된 값의 형식 서명이 TS 컴파일러에서 인식되면 좋겠지만 더 큰 변경 사항 대신 문서를 명확하게 해야 한다는 데 동의합니다.

기록을 위해 이것은 @orta 의 PR에서 관련 문서 형식으로 시도한 것의 단순화된 버전입니다.

interface HasNewProperty {
  newProperty: string;
}

function classDecorator<T extends { new (...args: any[]): {} }>(
  constructor: T
) {
  return class extends constructor implements HasNewProperty {
    newProperty = "new property";
    hello = "override";
  };
}

<strong i="8">@classDecorator</strong>
class Greeter {
  property = "property";
  hello: string;
  constructor(m: string) {
    this.hello = m;
  }
}

console.log(new Greeter("world"));

// Alas, this line makes the compiler angry because it doesn't know
// that Greeter now implements HasNewProperty
console.log(new Greeter("world").newProperty);