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_プロパティを導入できると便利です（たとえば、ゲッターに関連付けられたセッターを生成するヘルパー、またはそれらの線に沿ったもの）

connectのreact-reduxタイピングはコンポーネントを受け取り、その小道具にreduxを介して受信した接続された小道具が含まれていない変更されたコンポーネントを返しますが、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アプリをtypescriptに変換しようとしていて、これを打っています）。

@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

これらのletステートメントのスコープ内にあるFooは、デコレーターによって変更されています。 元の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:
         }

しかし、私は、コンパイラーが変更されたクラスの正しい型定義を出力するようにするのに十分な知識がありません。 私は次のテストを行っています：

テスト/ケース/適合性/デコレータ/クラス/デコレータOnClass10.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();

テスト/ベースライン/ローカル/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を提出して、問題を1か所で追跡しました。

この問題に関するすべてのコメントを読みましたが、デコレータの署名は、ラップされたクラスで何ができるかを実際には示していないという考えがあります。

これを考えてみましょう：

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.

実装に関しては、これにより、装飾されたクラスの1つの合成シンボルが導入されます。 また、元のクラス名はクラス本体スコープにのみバインドされます。

@HerringtonDarkholmeそれは、望ましい表現力のほとんどを提供する、うまく実用的なアプローチになると思います。 いい案！

いつか絶対に見たい

私はよくAngular2または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が一級市民として扱われるAngular2エコシステムでは非常に苛立たしいものです。 それでも、デコレータを使用してプロパティを追加しようとすると、TypeScriptコンパイラはノーと言います。 Angular2チームがこの問題にある程度の関心を示すと思いました。

@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. これらは型推論でうまく機能します-ミックスイン関数の戻り値を入力する必要はありません
4. これらは静的分析、特に定義へのジャンプでうまく機能します- loggerの実装にジャンプすると、インターフェースではなく、mixin_implementation_に移動します。

@justinfagnaniこれについてはミックスインも考えていなかったので、ありがとうございます。 今夜Loggableミックスインを作成して、ロガーの添付ファイルの構文を少し良くします。 extends Mixin(SuperClass)ルートは、TS 2.2のリリース以来、これまでミックスインを使用してきた方法であるため、私の好みです。

私はミックスインよりもデコレータ構文のアイデアを好みますが、それでもこの特定の問題に対してある程度の解決策が得られることを願っています。 私の意見では、デコレータを使用して定型文のないミックスインを作成できることは、コードをよりクリーンにするための大きな恩恵になるでしょう。

@zajrikは提案が役に立ったことをうれしく思います、私は願っています

ミックスインがデコレータよりもボイラープレートを持っていることを私はまだよく理解していません。 構文上の重みはほぼ同じです。

クラスミックスイン：

class LoggableFoo extends Loggable(Foo) {}

vsデコレータ：

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

私の意見では、ミックスインはその意図についてはるかに明確です。スーパークラスを生成し、スーパークラスはクラスのメンバーを定義するので、ミックスインはおそらくメンバーも定義しています。

デコレータは、メンバーを定義している、または定義していないとは思えないほど多くのことに使用されます。 単にクラスを何かに登録するか、メタデータをそれに関連付けることができます。

公平を期すために、 @ zajrikが望んでいるのは次のとおりです。

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

これは、わずかではあるが、ボイラープレートが少ないことは間違いありません。

そうは言っても、私はミックスインソリューションが大好きです。 私はミックスインが物であることを忘れ続けています。

気になるのが現在のクラスにプロパティを追加することだけである場合、ミックスインは基本的に1つの大きな煩わしさを持つデコレータと同等です...クラスにまだスーパークラスがない場合は、それらを使用するために空のスーパークラスを作成する必要があります。 また、構文は一般的に重いようです。 また、パラメトリックミックスインがサポートされているかどうかも明確ではありません（ extends Mixin(Class, { ... })が許可されています）。

理由のリストにある@justinfagnani 、ポイント2〜4は、実際にはTypeScriptの欠陥であり、ミックスインの利点ではありません。 JSの世界には適用されません。

OPの問題に対するミックスインベースのソリューションには、プロトタイプチェーンに2つのクラスを追加する必要があり、そのうちの1つは役に立たないことは誰もが明確にすべきだと思います。 これは、ミックスインとデコレータのセマンティックの違いを反映していますが、ミックスインは親クラスチェーンをインターセプトする機会を提供します。 しかし、95％の確率で、これは人々がやりたいことではなく、このクラスを飾りたいと思っています。 ミックスインの用途は限られていますが、デコレータや高次クラスの代わりにミックスインを宣伝することは意味的に不適切だと思います。

ミックスインは基本的にデコレータと同等ですが、1つの大きな問題があります...クラスにスーパークラスがまだない場合は、それらを使用するために空のスーパークラスを作成する必要があります

これは必ずしも真実ではありません：

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

class Foo extends Mixin() {}

また、構文は一般的に重いようです。

これがどうなっているのかわからないので、意見を異にする必要があります。

また、パラメトリックミックスインがサポートされているかどうかも明確ではありません（Mixin（Class、{...}）を拡張できます）。

彼らはとてもそうです。 ミックスインは単なる関数です。

理由のリストでは、ポイント2〜4は、実際にはTypeScriptの欠陥であり、ミックスインの利点ではありません。 JSの世界には適用されません。

これはTypeScriptの問題であるため、ここで適用されます。 JSの世界では、デコレータは実際にはまだ存在していません。

OPの問題に対するミックスインベースのソリューションには、プロトタイプチェーンに2つのクラスを追加する必要があり、そのうちの1つは役に立たないことは誰もが明確にすべきだと思います。

どこで2つ手に入るのかわかりません。 パッチを適用しない限り、デコレータと同じように1つです。 そして、どのプロトタイプが役に立たないのでしょうか？ ミックスインアプリケーションはおそらくプロパティ/メソッドを追加しますが、それは役に立たないわけではありません。

これは、ミックスインとデコレータのセマンティックの違いを反映していますが、ミックスインは親クラスチェーンをインターセプトする機会を提供します。 しかし、95％の確率で、これは人々がやりたいことではなく、このクラスを飾りたいと思っています。

これが本当かどうかはわかりません。 通常、クラスを定義するときは、スーパークラスメソッドをオーバーライドする機能を備えた、継承階層の最下位にあることを期待します。 デコレータは、 super()で動作しないなど、多くの問題があるクラスにパッチを適用するか、拡張する必要があります。その場合、装飾されたクラスには拡張をオーバーライドする機能がありません。 これは、パフォーマンス/デバッグトレースのためにクラスの定義されたすべてのメソッドをオーバーライドするデコレータのように、場合によっては便利ですが、通常の継承モデルからはほど遠いものです。

ミックスインの用途は限られていますが、デコレータや高次クラスの代わりにミックスインを宣伝することは意味的に不適切だと思います。

開発者がプロ​​トタイプチェーンにメンバーを追加したい場合、ミックスインは正確に意味的に適切です。 誰かがミックスインにデコレータを使用したいと思っている場合は常に、クラスミックスインを使用すると、デコレータに実際に期待しているセマンティクス、スーパーコールを使用した作業プロパティによる柔軟性、およびもちろん、彼らは今働いています。

Mixinは、ユースケースに直接対応する場合、ほとんど不適切ではありません。

開発者がプロ​​トタイプチェーンにメンバーを追加したい場合

それがまさに私のポイントです。OPはプロトタイプチェーンに何も追加したくないのです。 彼はただ1つのクラスを変更したいだけで、ほとんどの場合、デコレータを使用する場合、Object以外の親クラスさえありません。 また、何らかの理由Mixin(Object)はTypeScriptで機能しないため、ダミーの空のクラスを追加する必要があります。 これで、不要なときに2つのプロトタイプチェーン（オブジェクトを含まない）ができました。 さらに、プロトタイプチェーンに新しいクラスを追加するには、取るに足らないコストがかかります。

構文については、 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

@nevirうん、私はすでにTypeScript 2.2でデフォルトのObjectパラメータでミックスインを使用するという@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あなたはビットを選んでいますが、私は全体像について話しているのです。 このスレッドの私のコメントをすべて確認してください。要点は個々の問題ではなく、同時に発生する各問題にあります。 継承ベースのアプローチの問題をうまく説明したと思います-たくさんのコードの重複。

明確にするために、これは私にとって「クリーンなコード」についてではありません。 問題は実用性の1つです。 @fooを関数適用と同じように扱う場合は、型システムに大幅な変更を加える必要はありません。 型情報をその戻り型から関数の引数に導入しようとするワームの缶を開けると、同時に型推論やTypeScript型システムのさまざまなコーナーで見つかった他のすべての魔法の獣と相互作用します。これは、現在のオーバーロードとほぼ同じように、新機能の大きな障害になります。

@TomMariusこのスレッドでの最初のコメントは、関連性のないクリーンなコードに関するものです。 次のコメントは、サンプルコードを提供したこのオンラインサービスの概念についてです。 最初の段落から4番目の段落までの主な不満は、 MyService extends Service<MyService>を使用するとエラーが発生しやすいことです。 これに対処する方法の例を示してみました。

もう一度見てみましたが、その例では、デコレートされたクラスのメンバーがデコレータを認識する必要がある理由を示すものは実際には何もわかりません。 標準の継承では実現できない、ユーザーに提供するこれらの新しいプロパティについてはどうでしょうか。 私はリフレクションを使ったことがないので、それをざっと見ただけで、お詫びします。

@masaeedu継承でそれを達成することはできますが、継承によって私/私のユーザーはコードを大量に複製する必要があるので、別の方法が必要です-そして私はそうしますが、型システムは現実を正しく反映できません。

重要なのは、 serviceが<T>(target: T) => T & IServiceとして宣言されている正しいタイプの<strong i="7">@service</strong> class X { }は、 Xではなく、 X & IServiceです。 問題は、実際には、意味的には正しくない場合でも、クラス内でも当てはまるということです。

この問題が引き起こすもう1つの大きな問題は、それぞれに制約がある一連のデコレータがある場合、型システムはターゲットが常に元のクラスであり、装飾されたクラスではないと見なすため、制約が役に立たないことです。

継承でそれを達成することはできますが、継承によって私/私のユーザーはコードを大量に複製する必要があるので、別の方法が必要です。

これは私が理解していない部分です。 ユーザーは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 ""; }
}

どちらの場合も、$＃$ 7 $＃$のタイプとしてthisのリターンタイプをserviceDecorator 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に実装されているため、非常に重要な重要なブリックの1つだと思います。 この問題を実装できれば、公式リリースまで実験的な状態を失うことはありません。 しかし、それはの「実験的」です。

@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がこれを反映していると便利です。

タイプスクリプトが回避策を課すことなくこれを反映することが望まれます。 他にある場合
デコレータが実行できることをモデル化できない場合は、少なくともこれがあればいいでしょう
シナリオは、何らかの形または形式でサポートされていました。

このスレッドは、デコレータが何をすべきか、どのように使用されるべきか、どのように使用されるべきでないかなどについての意見でいっぱいです。

これは、デコレータが実際に行うことです。

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は単純に素晴らしく、私はそれが大好きです。 しかし、これは単に壊れている数少ない（唯一の？）部分の1つのように思えます、そして私はそれが修正されるのを見るのを楽しみにしています:)

@arackafデコレータが実際に何をするかはよく理解されており、TypeScriptのemitがすでにデコレータをサポートしているタイプを気にしないと仮定します。 この問題の全体的な議論は、装飾されたクラスが型システムでどのように提示されるべきかについてです。

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はデコレータによって完全に異なるものに再割り当てされるため、他の人には無効です。

これを実装するのは明らかに難しいでしょう。 このスレッドの先頭にリストされているような一般的なケースで、インターフェイスのマージなどの回避策がこのようなトリッキーなエッジケースのフォールバックである場合、いくつかの合理的なサブセットが可能ですか？

@arackaf

ただし、Fooはデコレータによって完全に異なるものに変更されます

そもそもFooが何であるかについての正確な定義はありません。 私たちの全体的な論点は、 Fooのメンバーがアクセスできるかどうか（したがって、パブリックAPIの一部として戻ることができるかどうか）であることに注意してください。デコレータはthisからメンバーを紹介しました。 Fooとは、デコレータが返すものによって定義され、デコレータが返すものは、 Fooとは何かによって定義されます。 それらは不可分に接合されています。

これを実装するのは非常に難しいと確信しています

機能がどのように機能するかについての確固たる提案さえない場合、実装の複雑さについて話すのはまだ時期尚早です。 申し訳ありませんが、「このような一連のデコレータをこのようなクラスに適用すると、 thisどうなるか」について、具体的なメカニズムを提案してくれる人が本当に必要です。 次に、さまざまなTypeScriptの概念をさまざまな部分にプラグインして、何が意味をなすかを確認できます。 そうして初めて、実装の複雑さについて議論することが理にかなっています。

上に貼り付けた現在のデコレータ出力は仕様に準拠していませんか？ 私はそれが私が見たものからだと思いました。

そうだとすれば、Fooはあらゆる段階でかなり正確な意味を持っています。 TSでは、最後のデコレータが返すものに基づいてthis （Fooメソッド内およびFooのインスタンス）を使用できるようになると思います。TSでは、デコレータの場合、必要に応じて途中で型注釈を追加する必要があります。関数は十分に分析できません。

@arackaf 「道のり」はありません。 特定の不変コードスニペットの最終的なタイプthisのみに関心があります。 デコレータ関数f1...fnで装飾されたクラスXのメンバーに対して、 thisのタイプがどうあるべきかを少なくとも大まかに説明する必要があります。 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の型と互換性があるという制限はありません。

あなたがこれで作り出すことができる不条理はいくつもあります。 thisのタイプによって決定されるcの結果として、 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()がエラーになることについて不平を言っています。

ここには2つのFooがあります。 あなたが言う時

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()元のFoo内は、型エラーではありません。これは、以前は識別子Fooにバインドされていた（現在は到達不能な）クラスに有効です。

これは特異で楽しい雑学ですが、TSが変化するクラスデコレータを処理できない理由がわかりません。

@arackafあなたは質問に答えていません。 具体的には、 thisのタイプは何ですか？ 「 thisはFooであり、Fooはthisです」と無限に循環的に答えることはできません。 thisにはどのようなメンバーがいますか？ hello(): void以外のメンバーがいる場合、それらを決定するためにどのロジックが使用されていますか？

「元のFoo内のthis.foo()はタイプエラーではありません」と言う場合でも、次の質問に答える必要があります。タイプエラーではないようなthisの構造タイプは何ですか。 this.foo()実行しますか？

また、元のクラスは「到達不能」ではありません。 そのコードスニペットで定義されたすべての関数は、実行時にアクティブに実行され、すべて問題なく機能します。 私が提供した遊び場のリンクを実行し、コンソールを見てください。 デコレータは、 helloメソッドが装飾されたクラスのhelloメソッドに委任する新しいクラスを返します。次に、装飾されたクラスのfooメソッドに委任します。

これは特異で楽しい雑学ですが、TSが変化するクラスデコレータを処理できない理由がわかりません。

型システムには「トリビア」はありません。 ユースケースがニッチすぎるため、TSC-1234の「いたずらっ子、それはできません」というタイプのエラーは発生しません。 機能が原因で完全に正常なコードが驚くべき方法で壊れている場合は、その機能を再考する必要があります。

ユースケースがニッチすぎるため、TSC-1234の「いたずらっ子、それはできません」というタイプのエラーは発生しません。

これは、デコレータによってクラス定義に追加されたメソッドを使用しようとしたときに得られるものとまったく同じです。 現在、クラスに定義を追加するか、インターフェイスのマージ、 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（）はTypeエラーになるはずです。

また、 hello() { return this.foo(); }はTypeErrorではありません-なぜそうなるのでしょうか？ そのクラス定義に到達できなくなったからといって、どういうわけかそのメソッドが無効になるわけではありません。

TypeScriptがこれらのエッジケースのいずれかを完璧にすることは期待していません。 いつものように、あちこちに型注釈を追加しなければならないことはかなり理解できるでしょう。 しかし、これらの例のいずれも、 @loggerがFooのバインド先を根本的に変更できない理由を示していません。

loggerが新しいクラスを返す関数である場合、それがFooが現在参照しているものです。

私はこれが何であるか、そしてどこであるかについてのすべての質問に答えました。
問題の単純な事実は、 thisの意味があなたがどこにいるかに基づいて変わるということです。

これは本当にイライラします。 いいでしょう、それは変わります、それはFooです、それは静的バインディングなどです、などなど。型署名とは何ですか？ thisにはどのようなメンバーがいますか？ あなたは太陽の下ですべてについて話しているのですが、私があなたから必要としているのは、 thisがhelloの中にあるものの単純な型署名だけです。

new LoggableFoo().hello()は、Greeterを介して入力された、他の方法では到達できないメソッドを呼び出すvoidメソッドをたまたま呼び出します。

これは到達不能と同じではありません。 到達可能なすべてのメソッドは、到達可能なパスを割り引くと「到達不可能」になります。

行った場合：

しかし、これは文字通り私がしたことです。 これはまさに私のコードスニペットであり、再度貼り付けて、前に作成した例の説明を付けています。 クレイジーなピルを服用していないことを確認するために、差分チェッカーを実行しました。唯一の違いは、削除したコメントです。

また、 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が生成するものとは異なります。

それで、なぜあなたは私と議論さえしているのですか？ 「タイプエラーである新しいFoo（）。fooはバグであり、簡単に修正できることに同意します。this.fooを返すことに同意しません。タイプエラーであることがバグです」。 同様に、あなたの例では、タイプエラーであるnew Foo().x()はバグですが、タイプエラーであるthis.x()はバグではないことに同意します。

このページの上部にあるスニペットに2つのコメントがあることがわかりますか？

        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のバージョンが2つある場合は、両方をサポートします。

@arackaf np、あなたの忍耐にも感謝します。 私の例は、それがどのように壊れているかを示すために遊び場で調理できるものを投稿しているだけなので、最も明確ではありませんでした。 体系的に考えるのは難しいです。

唯一の賢明な解決策は、Foo（Fooの内部）が元のFooの型共用体、および最後のデコレータが返すものをサポートすることだと思います。

素晴らしいです、それで私たちは今それの詳細に取り掛かっています。 これが間違っている場合は訂正してください。ただし、「ユニオン」と言う場合は、両方のタイプメンバーが含まれている必要があります。つまり、 A & Bである必要があります。 したがって、 thisをtypeof(new OriginalClass()) & typeof(new (decorators(OriginalClass)))にします。ここで、 decoratorsは、すべてのデコレータの合成型アノテーションです。 平易な英語では、 thisを、すべてのデコレータを通過する「元のクラス」のインスタンス化されたタイプと「元のクラス」のインスタンス化されたタイプの共通部分にします。

これには2つの問題があります。 1つは、私の例のように、存在しないメンバーにアクセスできるようにすることです。 デコレータに多数のメンバーを追加することもできますが、クラスでthis.newMethod()を使用してそれらにアクセスしようとすると、実行時に吐き出されます。 newMethodは、デコレータ関数から返されたクラスにのみ追加され、元のクラスのメンバーはそれにアクセスできません（特にreturn class extends OriginalClass { newMethod() { } }パターンを使用しない限り）。

もう1つの問題は、「元のクラス」が明確に定義された概念ではないことです。 thisから装飾されたメンバーにアクセスできる場合は、それらをreturnステートメントの一部として使用することもできるため、「元のクラス」のパブリックAPIの一部である可能性があります。 私はここでちょっと手を振っていて、具体的な例を考えるには少し燃え尽きすぎていますが、それについてよく考えれば、無意味な例を思いつくことができると思います。 たぶん、 thisからアクセスしたものを返さないメンバー、または少なくともthis.something()を返した結果として戻りタイプが推測されないメンバーを分離する方法を見つけることで、これを回避できます。

@masaeeduええ、私はあなたの返事の前に和集合/交差点について自分自身を訂正しました。 TSを初めて使用する人にとっては直感に反します。

残りの部分を理解しました。 正直なところ、デコレータは通常、完全に異なるタイプを返すことはありません。通常、渡されたタイプを拡張するだけなので、交差点はほとんどの場合安全に「機能」します。

あなたが話しているランタイムエラーはまれであり、意図的に悪い開発決定の結果だと思います。 これを本当に気にする必要があるかどうかはわかりませんが、それが本当に問題である場合は、最後に返されたデコレータを使用するだけで、まともな2位になると思います（つまり、クラスはTypeErrorを次のように見ることができます）それ自体が定義する方法を使用しようとしています-理想的ではありませんが、デコレータの動作に支払う価値のある価格です）。

しかし、実際には、デコレータが正しく機能することを犠牲にして、あなたが考えているランタイムエラーを防ぐ価値はないと思います。 さらに、不注意またはばかげている場合、TSでランタイムエラーを生成するのは非常に簡単です。

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

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

あなたの2番目の異議について

returnステートメントの一部として使用することもできるため、「元のクラス」のパブリックAPIの一部である可能性があります。

恐れ入りますが、問題はありません。 デコレータを介してクラスに追加されたものはすべて、絶対に一級市民になりたいです。 潜在的な問題が何であるか興味があります。

もう1つの良いオプションは、これを部分的にのみ実装することだと思います。

現在、クラスは定義されたとおりに常に型指定されています。 したがって、Foo内では、これはデコレータに関係なく、fooが定義されている方法に基づいています。 デコレータのユースケースのいくつかの有用なサブセット（つまり、最も一般的なもの）について、それを「ただ」拡張することは、非常に大きな改善になるでしょう。

デコレータが元のクラスを拡張するものを返す場合にのみ、クラスの拡張を（クラス内のthisの観点から）許可するとどうなりますか？

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

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

それを正しく機能させ、デコレータによって追加された何とか何でも一流のサポートを提供します。 また、まったく新しいクラス（Greeterなど）を返すなどのクレイジーなことを行うユースケースでは、現在の動作を続行し、デコレータが実行していることを無視します。

ところで、あなたが何を選んだかに関係なく、私はそれをどのように注釈しますか？ これに現在注釈を付けることはできますか？ 私は試した

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でも損益分岐点になります。

これを機能させるには、あらゆる種類のフープやゆがみを飛び越える必要があります。一般的なケースでは無意味であるため、型システムはあらゆる段階で戦います。 さらに重要なことに、一度実装すると、他の複雑な（しかし健全な）概念を実装しようとするときはいつでも、型システムのこの無意味なコーナーをアクロバット的に操作する必要があります。

重要だと思うこの1つのユースケースがあるからといって（そして、このスレッドで、既存の型システムで必要なものを適切に表現するための代替方法を示すために何度か試しました）、それが唯一の正しいことを意味するわけではありませんやるべきことは、どんな犠牲を払ってもあなたの提案したアプローチと一緒に前進することです。 デコレータ関数の戻り型を含め、任意のインターフェイスをクラスにマージできるため、デコレータを使用方法で使用することを主張した場合、どこにでもアクセスできなくなるわけではありません。

@arackaf this：

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(){ }
    }
}

関係ありません。 いずれにせよ、多くの人が本当に求めているユースケースは、必要な注釈によって、どんなに不便であっても、 function cがクラスCを取ることをTypeScriptに伝えることができることです。 C & {blah(): void}を持つクラスを返します。

それが、今日私たちの多くがデコレータを積極的に使用していることです。 私たちは本当に、この振る舞いの有用なサブセットを型システムに統合したいと思っています。

デコレータが、型システムでは追跡できない奇妙なことを実行できることは簡単にわかります。 罰金！ しかし、それに注釈を付ける方法が必要です

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

有効です。 cに新しい型注釈構文が必要かどうか、またはこれを実現するために既存の型注釈構文をcで使用できるかどうかはわかりませんが、一般的な使用法を修正するだけです。ケース（および元のクラスに影響を与えずにエッジをそのままにしておく）は、TSユーザーにとって大きな恩恵になります。

@justinfagnani fyi this

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

を生成します

タイプ 'typeof（匿名クラス）'はタイプ 'T＆（new（）=> {blah（）：void;}）'に割り当てることができません。
タイプ 'typeof（匿名クラス）'はタイプ 'T'に割り当てることができません。

TSプレイグラウンドで。 いくつかのオプションが間違って設定されているかどうかわかりません。

スーパークラスを作成するのではなく、宣言されたクラスをサブクラスで解決しようとしている問題は何ですか？

デコレータを使おうとしているだけです。 私はJSで1年以上それらを喜んで使用しています-私は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として使用する必要があるようです。これは、デコレータとして非常に混乱するためです。

私はJSで1年以上それらを楽しく使用しています

ええと...あなたは本当にしていません。 JSにはデコレータがありません。 あなたはおそらく、特定の廃止された以前の提案を使用していましたが、それはたまたまBabelとTypeScriptでわずかに異なって実装されています。 他の会場では、デコレータが標準化プロセスを継続することを主張していますが、進捗は遅く、まだ確実ではないと思います。 多くの人が、それらを追加するべきではない、または単に注釈にするべきではないと主張しているので、セマンティクスはまだ空中にある可能性があります。

デコレータに対する不満の1つは、クラスの形状を変更できるため、静的に推論するのが難しいということです。少なくともデコレータの能力を制限するためのいくつかの提案が話し合われていますが、それは以前のことだと思います。最新の提案は仕様言語を取得しました。 私は個人的に、行儀の良いデコレータはクラスの形状を変更してはならないので、静的分析の目的では無視できると主張しています。 標準のJSには、関数の実装が何をしているのかを分析に伝えるための型システムがないことを忘れないでください。

• TSが追いつくのを待ち望んでいます。

ここでは、TypeScriptがどのように遅れているのかわかりません。 少なくとも、何の後ろに？ デコレータは機能します。 クラスが希望どおりに動作する別の型付きJSはありますか？

デコレータは現在ステージ2であり、ほぼすべてのJSフレームワークで使用されています。

@connectの場合、react-reduxのダウンロード数は月に約250万回です。 別の方法で実装したため、デザインがどういうわけか「間違っている」と聞くのは非常に傲慢です。

デコレータによって導入されたメソッドを使用しようとすると、TypeScriptで型エラーが発生し、インターフェイスのマージ、追加されたメソッドの注釈の手動追加、またはデコレータを使用してクラスを変更しないなどの回避策が必要になります（デコレータは使用しないでください）。

デコレータがクラスの形状を変更していることをTSコンパイラに手動で丹念に通知する方法は本当にありませんか？ たぶんこれはクレイジーですが、TSは新しいデコレータを出荷することはできませんでした使用できるタイプ

c：デコレータ

そして、そのタイプのデコレータがクラスに適用されている場合（そしてその場合のみ）、TSはクラスがInput＆{blah（）}型であると見なしますか？

文字通り、誰もがデコレータを使用できないことを知っています。 ほとんどの人は、ボーカルグループがデコレータを嫌うことも知っています。 この投稿は、TSがどういうわけか、デコレータがクラス定義を変更していることを型システムに理解させる方法についてです。 それは多くの人にとって大きな恩恵となるでしょう。

正確に言うと、型システムが前者と後者を区別できないように処理するために、TypeScriptが上記の例のa、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は1日に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によって与えられ、上記の2番目のコメントで複製された正確なユースケースは、コードベースで非常に一般的であり、その外観から、他の多くの人も同様です。 私たちは文字通り次のようなものを使用します

<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の主張に応えていました。

他のオプションがたまたま存在するという事実にもかかわらず、私は私と他の多くの人がたまたま好む構文を示しているだけでした。

この場合、はい、クラスを取り込んで、装飾されたクラス内で使用される新しいメソッドを使用して新しいクラスを吐き出す人気のあるnpmライブラリを知りません。 これは、私や他の人が私たち自身のコードで、私たち自身のミックスインを実装するために頻繁に行うことですが、npmの例は実際にはありません。

しかし、これが一般的なユースケースであることに異論はありませんね。

@arackafいいえ、 @connectによって導入されたthisのメンバーにアクセスしていないためではありません。 実際、私はこの正確なスニペットをかなり確信しています：

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

今日のTypeScriptでは問題なくコンパイルされます。 貼り付けたスニペットは、要求している機能とは何の関係もありません。

@ masaeedu-ごめんなさい-私は自分が間違っていることに気づき、そのコメントを削除しました。 しかし、あなたがあなたの時間を無駄にするのを防ぐのに十分な速さではありません:(

@arackafパターンがどれほど一般的かはわかりません。個人的には、自分で使用したことも、使用するライブラリを使用したこともありません。 Angular 2をしばらく使っていたので、人生でデコレータを使ったことがないわけではありません。 これが、デコレータで紹介されたデコレータのメンバーにアクセスできないことが問題となるライブラリを使用する具体的な例を求めていた理由です。

クラスのメンバーがthisの何かを期待する場合は常に、クラスの本体またはクラスのextends句に要件を満たすものが存在する必要があります。 これは、デコレータを使用した場合でも、常に機能している方法です。 クラスが依存する機能を追加するデコレータがある場合、クラスはデコレータが返すものを拡張する必要があり、その逆ではありません。 それは常識です。

なぜこれが常識なのかわかりません。 これは現在のコードベースのコードです。 クラスのプロトタイプにメソッドを追加するデコレータがあります。 TypeScriptがエラーになります。 当時、私はこの宣言をそこに投げました。 インターフェイスのマージを使用することもできます。

しかし、何も使用しないとよいでしょう。 TypeScriptに、「このデコレータは、適用されるクラスにこのメソッドを追加します。クラス内のthisにもアクセスを許可します」と伝えることができれば本当に素晴らしいでしょう。

このスレッドの他の多くの人も同様にデコレータを使用しているように見えるので、これが機能しないことは常識ではないかもしれないと考えていただければ幸いです。

@arackafええ、あなたはexport class SearchVm extends (@mappable({...}) class extends SearchVmBase {})をしているはずです。 マッピング可能性に依存するのはSearchVmであり、その逆ではありません。

エクスポートクラスSearchVmextends（@mappable（{...}）クラスextends SearchVmBase {}）

このスレッドの要点は、そのような定型文を避けることです。 デコレータは、そのようなことをしなければならないよりもはるかに優れたDXを提供します。 それよりも、私が持っているようなコードを書くことを選んだのには理由があります。

このスレッドへのコメントを読んだら、他の多くの人がより単純なデコレータ構文を使用しようとしていることを確信して、私たちが「すべき」ことや「常識」などを再考することを願っています。

あなたが望むものは、特にデコレータとは何の関係もありません。 あなたの問題は、「ちょっとTypeScript、あなたが何も知らないこの構造に何かが起こっている、それについてすべてあなたに話させてください」と言うためのTypeScriptのメカニズムが現在あまりにも制限されているということです。 現在、インターフェイスのマージしかありませんが、関数がインターフェイスのマージを引数に適用できるようにする必要があります。これは、デコレータとは特に関係ありません。

現在、インターフェイスのマージしかありませんが、関数がインターフェイスのマージを引数に適用できるようにする必要があります。これは、デコレータとは特に関係ありません。

Ok。 けっこうだ。 別の号を開いてほしいですか、それともこの号の名前を変更したいですか？

@arackaf唯一の「ボイラープレート」は、私がclass { }を持っていたという事実です。これは、 a）使用するデコレータの数に関係なく、固定された7文字です。b）デコレータが（まだ）できないという事実の結果です。 ）任意のクラスを返す式に適用されます。c）私はあなたの利益のためにデコレータを特に使用したかったので。 この代替の定式化：

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

あなたが最初にやっていることよりも冗長ではありません。

Ok。 けっこうだ。 別の号を開いてほしいですか、それともこの号の名前を変更したいですか？

別の問題が良いでしょう。

あなたが最初にやっていることよりも冗長ではありません

これ以上冗長ではありませんが、多くの人がその構文を単に嫌っているという事実を考慮していただきたいと思います。 良くも悪くも、多くの人がDXデコレータが提供するものを好みます。

別の問題が良いでしょう。

明日入力し、コンテキストとしてこれにリンクします。

これを介して作業を支援していただきありがとうございます:)

私が入るかもしれないなら、 @ masaeedu私はこの声明に同意しません：

あなたが望むものは、特にデコレータとは何の関係もありません。 あなたの問題は、「ちょっとTypeScript、あなたが何も知らないこの構造に何かが起こっている、それについてすべてあなたに話させてください」と言うためのTypeScriptのメカニズムが現在あまりにも制限されているということです。 現在、インターフェイスのマージしかありませんが、関数がインターフェイスのマージを引数に適用できるようにする必要があります。これは、デコレータとは特に関係ありません。

確かに、TypeScriptは、クラスデコレータの戻り型を調べて、変更されたクラスがどの型であるかを判断できます。 「引数にマージするインターフェースを適用する」必要はありません。 ですから、私が見ているように、それは完全にデコレータと関係があります。

また、接続されたコンポーネントがもはや小道具を必要としないことをTypeScriptが知らない場合は、ReactとTypeScriptでReduxを使用することをやめさせた1つの側面です。

@codeandcatsそれはうまく機能しますか？ https://github.com/Zalastax/openschedule/blob/335ee3834122da7f65ba35f89d8fd737309fc4fb/src/components/week-selection/index.tsx https://github.com/Zalastax/openschedule/blob/335ee3834122da7f65ba35f89d8fd737 .tsx

@codeandcatsスレッドが始まって以来、私はこれと輪になっていて、本当にもうそれをすることができません。 前の議論を注意深く見て、実際に私が@arackafに反対していたことを理解してみてください。

<strong i="8">@bar</strong> class Foo { }を実行する場合、 Fooのタイプはbarのリターンタイプである必要があることに同意します。 Foo thisが何らかの形で影響を受けることに同意しません。 connectを使用することは、ここでの論点とはまったく関係ありません。 connectは、装飾されたコンポーネントがプロトタイプに追加するメンバーを認識して使用することを期待していないためです。

@masaeeduに不満を感じていることは理解できますが、過去48時間にわたって私が議論をフォローしていないという意見を積極的に表明していないという理由だけで、私が議論をフォローしていないと思い込まないでください。私に見下しの仲間を惜しまないでください。

私が理解しているように、デコレートされたクラスの内部では、デコレータによってそれ自体に加えられた突然変異については知らないはずですが、外部では知っている必要があります。 私はそれに同意しません。 @arackafがクラス内で変更されたバージョンを確認する必要があると考えるという事実は、私のコメントのポイントを超えています。

いずれにせよ、TypeScriptは、デコレータ関数によって返された型をクラスの信頼できる情報源として使用できます。 したがって、これはデコレータの問題であり、あなたが提案するようないくつかの新しい奇妙な引数の突然変異機能ではありません。これは、正直なところ、ストローマンの試みのように聞こえます。

@Zalastaxは、デコレータとしてではなく、関数としてデコレータ関数を使用しています。 複数のデコレータを適用する必要がある場合は、それらをネストする必要があります。これは、技術的にはもはや冗長ではありませんが、構文的には快適ではありません。私が何を意味するか知っていますか？

軽蔑など

ノイズ。

@arackafがクラス内で変更されたバージョンを確認する必要があると考えるという事実は、私のコメントのポイントを超えています。

それはあなたが応答している段落の中心点なので、あなたが何か他のことについて話しているなら、それは無関係です。 @arackafが望んでいるのは、大まかに言って、関数の引数にマージするインターフェースです。 これは、デコレータに依存しない機能によってより適切に対処されます。 あなたが望むのは（明らかに私が望むものと同じです）、TypeScriptのバグを修正することです。 <strong i="12">@foo</strong> class Foo { }はFooに対してconst Foo = foo(class { })と同じ型署名になりません。

私が理解しているように、デコレートされたクラスの内部では、デコレータによってそれ自体に加えられた突然変異については知らないはずですが、外部では知っている必要があります。 私はそれに同意しません

私たちが同意していることについて話すことにしたが、その前に「私はこの声明に同意しません」と言った場合、あなたはただ時間を無駄にしているだけです。

この塩でフライドポテトをもらえますか？

ああ、なるほど、あなたがあなたの仲間をひいきにするとき、それは素晴らしいです、しかし人々があなたをそれに引き上げるならば、それは騒音です。

@arackafが提案したものを実装するために、なぜ「引数の突然変異」の概念が必要なのかわかりません。

@arackafに同意するかどうかに関係なく、どちらの方法でも、TypeScriptは、私の謙虚な意見では、デコレータの結果から実際の型を単純に推測できます。

あなたが軽蔑されていると感じた場合はお詫びします。 意図はあなたをに連れて行くことでした
実際、誰もが許される可能性のある巨大なとりとめのないスレッド
スキミング。 あなたが気づいていないのはまだかなり明らかなので、私はこれを支持します
詳細の誤解に基づいて私と「意見が合わない」
私の立場。

たとえば、インターフェイスが関数にマージされる理由についての質問
議論はアダムの問題を解決します関連するものを見ることによって最もよく答えられます
Adamとの話し合いで、彼はすでにインターフェイスのマージを使用していると述べています。
しかし、各宣言サイトでこれを行わなければならないのは面倒です。

私はこれのすべての技術的側面が打ち負かされたと思います。 私
スレッドが対人関係の争いに支配されることを望まないので、これは
私の最後の投稿になります。

確かに、デコレータには2つのバグがあります。returnタイプが尊重されないことと、クラスの内部で追加されたメンバーが尊重されないことです（クラス内の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

/ ping

誰かがこれに対する解決策を探しているなら、私が思いついた1つの回避策は以下のとおりです。

ネストされたオブジェクトが必要なため、これは最善の解決策ではありませんが、デコレータのプロパティをクラスインスタンス上でフラットにするだけでなく、オブジェクト内に配置する必要があるため、うまく機能します。

これは、Angular5モーダルに使用しているものです。

カスタム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();
    }
}

：/うん、しかし、タイプはデコレータから切り離されており、確かにそれらの2つを使用することはできません.. :(クラスがメソッドを実装しない場合はエラーが発生します.. :(私はそこにないと思います現時点でこのパターンでタイプを正しくする方法です

ええ、これが可能であれば、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"});

@AllNamesRTaken

私はあなたの意見に同意しますが、あなたはそのように同じことを達成することができます：

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が完成するのを待ってください。そうすれば、誰もが同意する形式でそれらを取得できる可能性が高くなります。

@Kukkimonsuta
私が要求しているのは純粋にタイプに関するものであり、機能に関するものではないため、私はあなたに強く反対します。 したがって、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ミックスインは私がこれらの機能を始めた方法であり、私の実装も実際にはあなたが説明するように機能します：

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ユーザーが使用する必要があります。通常の関数として。 ほこりはほとんど落ち着きましたが、それはプロジェクトの新規参入者にとって継続的な混乱の原因です！

*まあ、「確執」は強い言葉かもしれません

私はこれを長い間見てきましたが、それが到着するまで、他の人が私の小さなハックから利益を得て、上位互換性のある方法でこの動作を実現できることを願っています。 これが、超基本的なScalaスタイルのケースクラス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など？

私はMaterialUIを使用していますが、TypeScriptがwithStylesのデコレータ構文をサポートしていないことを認識しなければなりませんでした： https ：//material-ui.com/guides/typescript/#decorating -components

次のTypeScriptリリースでその制限を修正してください。 クラスデコレータは、今のところ私にはかなり役に立たないようです。

Morphism Jsのメンテナとして、これはこの種のライブラリの大きな制限です。 関数デコレータの利用者が関数のターゲットタイプを指定する必要がないようにしたいと思いますhttps://github.com/nobrainr/morphism#--toclassobject-decoratorそうでなければ、HOFの代わりにデコレータを使用すると少し役に立たないように聞こえます😕
これに取り組む計画はありますか？ この機能を実現するのに役立つ方法はありますか？ 前もって感謝します！

@bikeshedderのMaterialUIの例は、クラスミックスインのユースケースであり、ミックスインから適切なタイプを取得できます。 それ以外の：

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です。 多くのutilライブラリは、 recompose 、 Rx.pipeなどのようなものを提供しますが、ライブラリをインストールしたくない場合は、もちろん、独自の単純なパイプ関数を作成できます。

これは、デコレータを使用しないよりも読みやすいと思います。

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

私がこれを使用するもう1つの理由は、デコレータの仕様が発表されて適切にサポートされると、このパターンを簡単に見つけて置き換えたり、grepしたりできることです。

@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しかし、マテリアル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からのチェックは機能しています。
@なしでデコレータを使用する場合-表記法は単に関数として呼び出すだけで、正しい交差型を取得します-タイプは使用できませんが、クラス自体の内部でタイプチェックする機能は失われます。インターフェイスのトリックはもうあり、見た目はもっと醜いです。 例えば：

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-ここで「finalized」とはどういう意味ですか？ TC39のステージ3は適格ですか？

私は彼らがそこまで到達したことに気づいていませんでした！ 彼らはいつステージ3に到達しましたか？ それは最近ですか？

彼らはまだしていません。 1月のTC39ミーティングで、彼らは再びステージ2からステージ3に進む準備ができていると思います。

詳細については、議題を監視することができます。

正解です（1月に昇進するかどうかは確認できませんが）。 私は彼らがそこに着いたときにステージ3が資格を得るかどうかだけを尋ねていました。

私の意見では、デコレータの提案にはまだ多くの深刻な問題があるため、1月にステージ3に進むと、問題のあるクラスフィールドの提案やglobalThisの提案と同じように再び間違いを犯します。

@hax詳しく教えていただけますか？
私は本当にこれを望んでいて、悲しいことに問題についてのコミュニケーションの欠如を見つけ、残念ながら問題について聞いたことがありません。

@AllNamesRTakenデコレータ提案の問題リストを確認してください。 😆たとえば、デコレータ引数の前後のexportは、ステージ3のブロッカーです。

また、APIの再設計など、提案された変更もいくつかあります。これは、提案がステージ3で安定していないことを意味すると思います。

また、問題のあるクラスフィールドの提案にも関連しています。 クラスフィールドはステージ3に到達していますが、問題が多すぎます。 私が懸念している大きな問題は、デコレータ（たとえば、保護されている）に多くの問題を残していることです。これは、両方の提案にとって悪いことです。

私はTC39の代表者ではないことに注意してください。また、一部のTC39の代表者は、多くの問題の現在の状況についての私のコメントに同意しません。 （特に、現在のTC39プロセスでは、多くの物議を醸す問題で大きな失敗があると強く思います。一部の問題をデコレータに延期しても、実際には問題が解決されません。デコレータの提案をより脆弱にするだけです。）

それらは理解され、提案はうまくいくと思いますが、ここでは提案の状態については議論しなかったほうがいいと思います。

十分な自信を持ったステージ3またはステージ4は、おそらく新しい提案を実装する場所だと思います。そうすれば、この問題を検討することができます。

ダニエルありがとう！ ステージ3は通常、4に対する強い自信を意味するため、1月の会議では指が交差しました。

そして、ここでデコレータの議論を始めてくれてありがとう。 この機能が引き起こした怒りと自転車の脱落のレベルは奇妙です。 私はそのようなものを見たことがありません😂

記録のために、同じことについての機能要求がありました： https ：//github.com/Microsoft/TypeScript/issues/8545

厄介なことに、JavaScriptからコンパイルする場合、TypeScriptはこの機能をある程度サポートします（https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#better-handling-for-namespace-patterns-in -js-files）：

// 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メンテナの騒音を抑えることができます。

これに関する更新はありますか？

回避策（角度：）） https://stackblitz.com/edit/iw-ts-extends-with-fakes?file=src%2Fapp%2Fextends-with-fakes.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

装飾されたクラスプロパティを入力するための回避策を作成するのにかなりの時間を費やしました。 このスレッドのシナリオに対する実行可能な解決策になるとは思いませんが、その一部が役立つ場合があります。 興味があれば、Mediumの私の投稿をチェックしてください。

この問題に関する更新はありますか？

これをどうやってやってるの？

この問題の結果、現在どのように機能していますか？

ミックスインクラスを使用してその効果を得ることができます
https://mariusschulz.com/blog/mixin-classes-in-typescript

@Bnayaは、私たちが今望んでいるものではありません;）。
デコレータを使用すると、古い学校のJavaのように使用する予定のないクラスを作成しないようにすることができます。 デコレータを使用すると、クラスが引き続きコア機能を実行し、さらに一般化された機能を構成できる、非常にクリーンで整然とした構成アーキテクチャが可能になります。 ええ、ミックスインはそれを行うことができますが、それはバンドエイドです。

デコレータの提案は過去数か月で大幅に変更されました。TSチームが、すぐに互換性がなくなる現在の実装にいつでも投資する可能性はほとんどありません™。

次のリソースをご覧になることをお勧めします。

デコレータの提案： https ：//github.com/tc39/proposal-decorators
TypeScriptロードマップ： https ：//github.com/microsoft/TypeScript/wiki/Roadmap

@Bnayaは、私たちが今望んでいるものではありません;）。
デコレータを使用すると、古い学校のJavaのように使用する予定のないクラスを作成しないようにすることができます。 デコレータを使用すると、クラスが引き続きコア機能を実行し、さらに一般化された機能を構成できる、非常にクリーンで整然とした構成アーキテクチャが可能になります。 ええ、ミックスインはそれを行うことができますが、それはバンドエイドです。

その混合ではなく、クラス。
それは悪いコピーのものではありません
パイプライン演算子が到着すると、構文も合理的になります

ミックスインクラスを使用してその効果を得ることができます

クラスファクトリのミックスインは、TypeScriptでは苦痛になる可能性があります。 そうでない場合でも、クラスを関数でラップしてミックスインに変換する必要があるため、非常に定型的です。サードパーティのクラスをインポートする場合は、これを簡単に実行できない場合があります。

以下は、はるかに優れており、単純で、クリーンであり、インポートされたサードパーティクラスで機能します。 レガシースタイルのデコレータをトランスパイルする以外のトランスパイルなしでプレーン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実装の次の2つの例で示されています（タイプに関する限り、実行時の実装は簡潔にするために省略されています）。

• 結合されたクラスのすべてのプロパティがパブリックであるため、エラーのない例。
• エラーのある例（一番下）。マップされた型は保護されたメンバーを無視するため、この場合は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の人々を責めることはできません。 標準になるまで実装しません。

しかし、これはマイクロソフトです。彼らはそれを実装して、標準の人々に言うことができます-「人々はすでに私たちのバージョンを使用しています」：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);