Typescript: अनुरोध: क्लास डेकोरेटर म्यूटेशन

विधियों के लिए भी उपयोगी होगा:

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

एसिंक डेकोरेटर को रिटर्न प्रकार को Promise<any> में बदलना चाहिए।

@ गेलन , यह वही है जो हमें यहां चाहिए! यह मिश्रण को काम करने के लिए स्वाभाविक बना देगा।

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 के लिए प्रतिक्रिया-रिडक्स टाइपिंग एक घटक लेता है और एक संशोधित घटक देता है जिसके प्रोप में रेडक्स के माध्यम से प्राप्त कनेक्टेड प्रोप शामिल नहीं होता है, लेकिन ऐसा लगता है कि टीएस उनकी 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;

जाहिर है नामकरण बेकार है और मुझे नहीं पता कि क्या इस तरह की चीज काम करेगी (मैं सिर्फ एक बैबेल ऐप को टाइपस्क्रिप्ट में बदलने की कोशिश कर रहा हूं और इसे मार रहा हूं)।

@joyt क्या आप समस्या का खेल का मैदान पुनर्निर्माण प्रदान कर सकते हैं? मैं प्रतिक्रिया-रेडक्स का उपयोग नहीं करता, लेकिन जैसा कि मैंने पहले उल्लेख किया है, मुझे लगता है कि किसी भी प्रकार के आकार के लिए आप जो भी एक्सटेंशन चाहते हैं उसे इंटरफ़ेस विलय का उपयोग करके घोषित किया जा सकता है।

@masaeedu यहाँ चलती भागों का एक बुनियादी टूटना है ..

मूल रूप से डेकोरेटर रिएक्ट कंपोनेंट को प्रॉप्स का एक गुच्छा प्रदान करता है, इसलिए डेकोरेटर का सामान्य प्रकार डेकोरेटेड कंपोनेंट का सबसेट होता है, सुपरसेट नहीं।

सुनिश्चित नहीं है कि यह सहायक है, लेकिन आपको खेलने के प्रकार दिखाने के लिए एक गैर-चलाने योग्य नमूना एक साथ रखने का प्रयास किया।

// 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 या अन्य नमूना प्रतिक्रिया/रेडक्स/टाइपस्क्रिप्ट प्रोजेक्ट को नीचे खींच लें।

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:
         }

लेकिन मैं संकलक आउटपुट को उत्परिवर्तित वर्ग की सही प्रकार की परिभाषा बनाने के लिए पर्याप्त जानकार नहीं हूं। मेरे पास निम्न परीक्षण है:

परीक्षण/मामले/अनुरूपता/सज्जाकार/वर्ग/सज्जाकार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();

यह परीक्षण/आधारभूत/स्थानीय/सज्जाकारOnClass10.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

इस सुविधा के लिए एक केस स्टडी के रूप में रिएक्ट-रेडक्स के 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 मुझे लगता है कि यह एक अच्छी तरह से व्यावहारिक दृष्टिकोण होगा जो वांछित अभिव्यक्ति प्रदान करेगा। महान विचार!

मैं निश्चित रूप से इसे किसी दिन देखना चाहता हूं

मैं अक्सर कोणीय 2 या ऑरेलिया के लिए एक वर्ग लिखता हूं, जो इस तरह दिखता है:

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

जावास्क्रिप्ट में पूरी तरह से संभव है, यह स्पष्ट रूप से समस्या नहीं है, लेकिन टाइपस्क्रिप्ट में मुझे asyncTask डेकोरेटर की आवश्यकता है ताकि सजाए गए तरीके के प्रकार को () => Promise<void> से AsyncTask<() => Promise<void>> में बदला जा सके।

बहुत यकीन है कि यह अभी संभव नहीं है और शायद इस मुद्दे की छत्रछाया में आता है?

@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 सज्जाकारों के साथ काम करने में असमर्थ था। मुझे उम्मीद है कि इस पर जल्द ही ध्यान दिया जाएगा। मैं

यह एंगुलर 2 इकोसिस्टम में बहुत परेशान करने वाला है जहां डेकोरेटर और टाइपस्क्रिप्ट को प्रथम श्रेणी के नागरिक के रूप में माना जाता है। फिर भी जिस मिनट आप एक डेकोरेटर के साथ एक संपत्ति जोड़ने का प्रयास करते हैं, टाइपस्क्रिप्ट कंपाइलर नहीं कहता है। मैंने सोचा होगा कि एंगुलर 2 टीम इस मुद्दे में कुछ दिलचस्पी दिखाएगी।

@zajrik आप टीएस 2.2 के बाद से उचित टाइपिंग के साथ समर्थित क्लास मिक्सिन के साथ जो चाहते हैं उसे पूरा कर सकते हैं:

अपने लॉग करने योग्य मिश्रण को इस प्रकार परिभाषित करें:

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);

आप _can_ एक डेकोरेटर के रूप में एक क्लास मिक्सिन का भी उपयोग करते हैं, लेकिन इसमें कुछ अलग शब्दार्थ हैं, मुख्य रूप से आपकी कक्षा को उप-वर्ग की अनुमति देने के बजाय, आपकी कक्षा को उप-वर्गीकृत करता है।

सज्जाकार, IMO पर क्लास मिक्सिन के कई फायदे हैं:

1. वे एक नया सुपरक्लास बनाते हैं, ताकि जिस वर्ग में आप उन्हें लागू करते हैं उसमें उन्हें ओवरराइड करने के लिए एक बदलाव हो
2. वे टाइपस्क्रिप्ट से किसी भी अतिरिक्त सुविधाओं के बिना, अभी चेक टाइप करते हैं
3. वे प्रकार के अनुमान के साथ अच्छी तरह से काम करते हैं - आपको मिक्सिन फ़ंक्शन का रिटर्न मान टाइप करने की आवश्यकता नहीं है
4. वे स्थिर विश्लेषण के साथ अच्छी तरह से काम करते हैं, विशेष रूप से जम्प-टू-डेफिनिशन - logger के कार्यान्वयन के लिए कूदना आपको मिश्रित _कार्यान्वयन_ पर ले जाता है, इंटरफ़ेस पर नहीं।

@justinfagnani मैंने इसके लिए मिश्रण भी नहीं माना था इसलिए धन्यवाद। मैं आगे बढ़ूंगा और अपने लॉगर अटैचमेंट सिंटैक्स को थोड़ा अच्छा बनाने के लिए आज रात एक Loggable मिक्सिन लिखूंगा। 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 { }

जो निर्विवाद रूप से, यदि कभी इतना थोड़ा, कम बॉयलरप्लेट है।

उस ने कहा, मुझे मिक्सिन सॉल्यूशन बहुत पसंद है। मैं भूलता रहता हूं कि मिश्रण एक चीज है।

यदि आप सभी के बारे में परवाह करते हैं तो वर्तमान वर्ग में गुण जोड़ रहे हैं तो मिश्रण मूल रूप से एक महत्वपूर्ण परेशानी के साथ सजावटी के बराबर होते हैं ... इसके अलावा वाक्यविन्यास सामान्य रूप से भारी लगता है। यह भी स्पष्ट नहीं है कि क्या पैरामीट्रिक मिश्रण समर्थित हैं ( extends Mixin(Class, { ... }) की अनुमति है)।

@justinfagnani आपके कारणों की सूची में, अंक 2-4 वास्तव में टाइपस्क्रिप्ट में कमियां हैं न कि मिक्सिन के फायदे। वे जेएस दुनिया में लागू नहीं होते हैं।

मुझे लगता है कि हम सभी को स्पष्ट होना चाहिए कि ओपी समस्या के मिश्रण आधारित समाधान में प्रोटोटाइप श्रृंखला में दो वर्ग जोड़ना शामिल होगा, जिनमें से एक बेकार है। यह मिक्सिंस बनाम डेकोरेटर्स के सिमेंटिक अंतर को दर्शाता है, हालांकि मिक्सिंस आपको पैरेंट क्लास चेन को इंटरसेप्ट करने का मौका देते हैं। हालाँकि, 95% समय ऐसा नहीं है जो लोग करना चाहते हैं, वे इस वर्ग को सजाना चाहते हैं। जबकि मिक्सिन के अपने सीमित उपयोग होते हैं, मुझे लगता है कि उन्हें सज्जाकारों और उच्च क्रम वर्गों के विकल्प के रूप में प्रचारित करना शब्दार्थ रूप से अनुचित है।

मिक्सिंस मूल रूप से एक महत्वपूर्ण झुंझलाहट के साथ सज्जाकारों के बराबर होते हैं ... यदि आपकी कक्षा में पहले से कोई सुपरक्लास नहीं है, तो आपको उनका उपयोग करने के लिए एक खाली सुपरक्लास बनाने की आवश्यकता है

यह जरूरी नहीं कि सच हो:

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

class Foo extends Mixin() {}

इसके अलावा वाक्यविन्यास सामान्य रूप से भारी लगता है।

मैं नहीं देखता कि ऐसा कैसे होता है, इसलिए हमें असहमत होना पड़ेगा।

यह भी स्पष्ट नहीं है कि क्या पैरामीट्रिक मिश्रण समर्थित हैं (विस्तारित मिक्सिन (कक्षा, {...}) की अनुमति है)।

वे बहुत हैं। मिक्सिन सिर्फ कार्य हैं।

आपके कारणों की सूची में, अंक 2-4 वास्तव में टाइपस्क्रिप्ट में कमियां हैं न कि मिक्सिन के फायदे। वे जेएस दुनिया में लागू नहीं होते हैं।

यह एक टाइपस्क्रिप्ट समस्या है, इसलिए वे यहां आवेदन करते हैं। जेएस में विश्व सज्जाकार वास्तव में अभी तक मौजूद नहीं हैं।

मुझे लगता है कि हम सभी को स्पष्ट होना चाहिए कि ओपी समस्या के मिश्रण आधारित समाधान में प्रोटोटाइप श्रृंखला में दो वर्ग जोड़ना शामिल होगा, जिनमें से एक बेकार है।

मैं स्पष्ट नहीं हूं कि आपको दो कहां मिलते हैं। यह एक है, जैसे डेकोरेटर कर सकता है, जब तक कि यह पैचिंग न हो। और कौन सा प्रोटोटाइप बेकार है? मिश्रण आवेदन संभावित रूप से एक संपत्ति/विधि जोड़ता है, यह बेकार नहीं है।

यह मिक्सिंस बनाम डेकोरेटर्स के सिमेंटिक अंतर को दर्शाता है, हालांकि मिक्सिंस आपको पैरेंट क्लास चेन को इंटरसेप्ट करने का मौका देते हैं। हालाँकि, 95% समय ऐसा नहीं है जो लोग करना चाहते हैं, वे इस वर्ग को सजाना चाहते हैं।

मुझे यकीन नहीं है कि यह सच है। आम तौर पर जब आप किसी वर्ग को परिभाषित करते हैं तो आप उम्मीद करते हैं कि यह सुपरक्लास विधियों को ओवरराइड करने की क्षमता के साथ विरासत पदानुक्रम के निचले भाग में होगा। सज्जाकारों को या तो वर्ग को पैच करना पड़ता है, जिसमें कई समस्याएं हैं, जिसमें super() के साथ काम नहीं करना शामिल है, या इसे विस्तारित करना है, इस स्थिति में सजाए गए वर्ग में एक्सटेंशन को ओवरराइड करने की क्षमता नहीं है। यह कुछ मामलों में उपयोगी हो सकता है, जैसे डेकोरेटर जो प्रदर्शन/डिबगिंग ट्रेसिंग के लिए कक्षा की प्रत्येक परिभाषित विधि को ओवरराइड करता है, लेकिन यह सामान्य विरासत मॉडल से बहुत दूर है।

जबकि मिक्सिन के अपने सीमित उपयोग होते हैं, मुझे लगता है कि उन्हें सज्जाकारों और उच्च क्रम वर्गों के विकल्प के रूप में प्रचारित करना शब्दार्थ रूप से अनुचित है।

जब कोई डेवलपर प्रोटोटाइप श्रृंखला में सदस्यों को जोड़ना चाहता है, तो मिश्रण बिल्कुल शब्दार्थ रूप से उपयुक्त होते हैं। हर मामले में मैंने देखा है कि कोई व्यक्ति मिक्सिन के लिए डेकोरेटर का उपयोग करना चाहता है, क्लास मिक्सिन का उपयोग करके एक ही कार्य को पूरा किया जाएगा, शब्दार्थ के साथ कि वे वास्तव में डेकोरेटर से उम्मीद कर रहे हैं, सुपर कॉल के साथ काम करने वाली संपत्ति के कारण अधिक लचीलापन, और के बेशक वे अब काम करते हैं।

जब वे सीधे उपयोग के मामले को संबोधित करते हैं तो मिक्सिन शायद ही अनुपयुक्त होते हैं।

जब कोई डेवलपर प्रोटोटाइप श्रृंखला में सदस्यों को जोड़ना चाहता है

ठीक यही मेरी बात है, ओपी प्रोटोटाइप श्रृंखला में कुछ भी नहीं जोड़ना चाहता है। वह सिर्फ एक वर्ग को बदलना चाहता है, और अधिकतर जब लोग सजावटी का उपयोग करते हैं तो उनके पास ऑब्जेक्ट के अलावा कोई मूल वर्ग भी नहीं होता है। और किसी कारण से Mixin(Object) टाइपस्क्रिप्ट में काम नहीं करता है इसलिए आपको एक डमी खाली वर्ग जोड़ना होगा। तो अब आपके पास 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 हाँ, मैंने पहले से ही टाइपस्क्रिप्ट 2.2 के साथ डिफ़ॉल्ट Object पैरामीटर के साथ मिक्सिन का उपयोग करने के @justinfagnani के सुझाव की कोशिश की और tsc कोड को अस्वीकार कर देता है।

@ohjames यह अभी भी काम करता है, आपको डिफ़ॉल्ट मामले में प्रोटोटाइप के बारे में सावधान रहना होगा (देखें कि अक्सर पूछे जाने वाले प्रश्न प्रविष्टि)।

हालांकि, null पारित होने पर tslib.__extend के व्यवहार पर भरोसा करना आम तौर पर आसान होता है

इस मुद्दे को अगले पुनरावृत्ति चरण में केंद्रित करने की कोई योजना है? इतने सारे पुस्तकालयों में इस सुविधा के लाभ अत्यधिक उच्च हैं।

मैं बस इस मुद्दे में भाग गया - यह मुझे बहुत सारे अनावश्यक कोड लिखने के लिए मजबूर करता है। इस मुद्दे को हल करना किसी भी डेकोरेटर-आधारित ढांचे/पुस्तकालय के लिए एक बड़ी मदद होगी।

@TomMarius जैसा कि मैंने पहले उल्लेख किया है, डेकोरेटर फ़ंक्शंस में लिपटे वर्ग पहले से ही ठीक से टाइप करते हैं, आप केवल @ सिंटैक्स चीनी का उपयोग नहीं कर सकते हैं। करने के बजाय:

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

आपको बस इतना करना है:

const Foo = loggable(class { });

आप उनमें कक्षा लपेटने से पहले सजावटी कार्यों का एक समूह भी बना सकते हैं। सिंटैक्स चीनी को ठीक से काम करने के दौरान मूल्यवान है, ऐसा नहीं लगता कि यह इतना बड़ा दर्द बिंदु होना चाहिए जैसे चीजें हैं।

@masaeedu वास्तव में मुद्दा बाहरी नहीं बल्कि आंतरिक प्रकार का समर्थन है। गुणों का उपयोग करने में सक्षम होने के कारण सजावटी संकलन त्रुटियों के बिना कक्षा में ही जोड़ता है, कम से कम मेरे लिए वांछित परिणाम है। आपके द्वारा प्रदान किया गया उदाहरण केवल Foo लॉग करने योग्य प्रकार देगा, लेकिन इस प्रकार को वर्ग परिभाषा के लिए वहन नहीं करेगा।

@zajrik एक डेकोरेटर मूल वर्ग से एक नया वर्ग लौटाता है, तब भी जब आप अंतर्निहित @ सिंटैक्स का उपयोग करते हैं। जाहिर है जेएस शुद्धता को लागू नहीं करता है, इसलिए आप अपने द्वारा पारित मूल वर्ग को बदलने के लिए स्वतंत्र हैं, लेकिन यह सजावटी अवधारणा के मुहावरेदार उपयोग के साथ असंगत है। यदि आप कार्यक्षमता को कसकर जोड़ रहे हैं जिसे आप सजावटी के माध्यम से कक्षा आंतरिक में जोड़ रहे हैं, तो वे आंतरिक गुण भी हो सकते हैं।

क्या आप मुझे आंतरिक रूप से उपभोग करने वाले एपीआई के लिए उपयोग के मामले का एक उदाहरण दे सकते हैं जिसे बाद में डेकोरेटर्स के माध्यम से जोड़ा जाता है?

ऊपर दिया गया लकड़हारा उदाहरण सजाए गए वर्ग के आंतरिक भाग में हेरफेर करने में सक्षम होने के लिए एक सामान्य _want_ का एक अच्छा उदाहरण है। (और वर्ग सजावट के साथ अन्य भाषाओं से आने वाले लोगों से परिचित है; जैसे कि पायथन )

उस ने कहा, @justinfagnani का वर्ग मिश्रण सुझाव उस मामले के लिए एक अच्छा विकल्प लगता है

यदि आप किसी वर्ग के आंतरिक भाग को परिभाषित करने में सक्षम होना चाहते हैं, तो ऐसा करने का संरचित तरीका वर्ग को पैच करना या एक नए उपवर्ग को परिभाषित करना नहीं है, दोनों टाइपस्क्रिप्ट के लिए कक्षा के संदर्भ में तर्क करना कठिन होगा स्वयं, लेकिन या तो केवल कक्षा में ही चीजों को परिभाषित करने के लिए, या एक नया सुपरक्लास बनाने के लिए जिसमें आवश्यक गुण हों, जिसके बारे में टाइपस्क्रिप्ट तर्क कर सकता है।

सज्जाकारों को वास्तव में किसी वर्ग के आकार को इस तरह नहीं बदलना चाहिए जो कक्षा या अधिकांश उपभोक्ताओं को दिखाई दे। @masaeedu यहीं पर है।

जबकि आप जो कह रहे हैं वह सच है, टाइपस्क्रिप्ट स्वच्छ कोडिंग प्रथाओं को लागू करने के लिए नहीं है, बल्कि जावास्क्रिप्ट कोड को सही ढंग से टाइप करने के लिए है, और यह इस मामले में विफल रहता है।

@masaeedu @zajrik ने क्या कहा। मेरे पास एक सजावटी है जो "ऑनलाइन सेवा" घोषित करता है जो कक्षा में उपयोग की जाने वाली कक्षा में गुणों का समूह जोड़ता है। मेटाडेटा और बाधा प्रवर्तन (यदि आप बिना कोड दोहराव के प्रयास करते हैं) के कारण इंटरफ़ेस को उप-वर्गीकरण या कार्यान्वित करना एक विकल्प नहीं है।

@TomMarius मेरा कहना है कि यह सही ढंग से जाँच कर रहा है। जब आप किसी क्लास में डेकोरेटर फ़ंक्शन लागू करते हैं, तो क्लास किसी भी तरह से नहीं बदली जाती है। मूल वर्ग के कुछ परिवर्तन के माध्यम से एक नया वर्ग उत्पन्न होता है, और केवल इस नए वर्ग को डेकोरेटर फ़ंक्शन द्वारा पेश किए गए एपीआई का समर्थन करने की गारंटी है।

मुझे नहीं पता कि "गायब मेटाडेटा और बाधा प्रवर्तन" का क्या अर्थ है (शायद एक ठोस उदाहरण मदद करेगा), लेकिन यदि आपकी कक्षा स्पष्ट रूप से डेकोरेटर द्वारा पेश किए गए एपीआई पर निर्भर करती है, तो इसे सीधे मिक्सिन पैटर्न के माध्यम से उपवर्ग करना चाहिए @justinfagnani ने दिखाया , या इसे कंस्ट्रक्टर या कुछ और के माध्यम से इंजेक्ट करें। सज्जाकारों की उपयोगिता यह है कि वे उन वर्गों को अनुमति देते हैं जो उन वर्गों का उपभोग करने वाले कोड के लाभ के लिए संशोधन के लिए बंद हैं। यदि आप स्वयं कक्षा को परिभाषित करने के लिए स्वतंत्र हैं, तो बस extends का उपयोग करें।

@masaeedu यदि आप किसी प्रकार का विकास कर रहे हैं, मान लीजिए, एक आरपीसी लाइब्रेरी, और आप उपयोगकर्ता को केवल एसिंक्रोनस विधियों को लिखने के लिए मजबूर करना चाहते हैं, विरासत-आधारित दृष्टिकोण आपको कोड डुप्लिकेट करने के लिए मजबूर करता है (या मुझे सही तरीका नहीं मिला है , हो सकता है - मुझे खुशी होगी अगर आपने मुझे बताया कि अगर आप जानते हैं कि कैसे)।

वंशानुक्रम आधारित दृष्टिकोण
परिभाषा: 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(); } }

आप इनहेरिटेंस-आधारित दृष्टिकोण उदाहरण में कोड दोहराव को स्पष्ट रूप से देख सकते हैं। यह मेरे और मेरे उपयोगकर्ताओं के साथ कई बार हुआ है कि जब वे कक्षा को कॉपी-पेस्ट करते हैं या टाइप पैरामीटर के रूप में "किसी भी" का उपयोग करना शुरू करते हैं तो वे टाइप पैरामीटर को बदलना भूल गए हैं और लाइब्रेरी ने उनके लिए काम करना बंद कर दिया है; डेकोरेटर-आधारित दृष्टिकोण बहुत अधिक डेवलपर के अनुकूल है।

उसके बाद विरासत-आधारित दृष्टिकोण के साथ एक और समस्या है: प्रतिबिंब मेटाडेटा अब गायब है, इसलिए आपको कोड को और भी डुप्लिकेट करना होगा क्योंकि आपको किसी भी तरह से service डेकोरेटर को पेश करना होगा। उपयोग अब है: <strong i="22">@service</strong> export default class MyService extends Service<MyService> { async foo() { return this.someMethod(); } } , और यह सिर्फ सादा अमित्र है, न कि केवल थोड़ी सी असुविधा।

आप सच हैं कि वर्ग को परिभाषित करने के बाद शब्दार्थ रूप से संशोधन किया जाता है, हालांकि, अघोषित वर्ग को तत्काल करने का कोई तरीका नहीं है, इसलिए कक्षा के उत्परिवर्तन का ठीक से समर्थन न करने का कोई कारण नहीं है, इसके अलावा यह कभी-कभी अशुद्ध कोड की अनुमति देता है (लेकिन कभी-कभी अच्छे अच्छे के लिए)। याद रखें कि जावास्क्रिप्ट अभी भी प्रोटोटाइप पर आधारित है, क्लास सिंटैक्स इसे कवर करने के लिए सिर्फ एक चीनी है। प्रोटोटाइप परिवर्तनशील है और इसे डेकोरेटर द्वारा म्यूट किया जा सकता है, और इसे सही ढंग से टाइप किया जाना चाहिए।

जब आप किसी क्लास में डेकोरेटर फ़ंक्शन लागू करते हैं, तो क्लास किसी भी तरह से नहीं बदली जाती है।

सच नहीं है, जब आप किसी क्लास में डेकोरेटर फंक्शन लागू करते हैं, तो क्लास को किसी भी तरह से बदला जा सकता है। चाहे आप इसे पसंद करें या न करें।

@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 आपकी टिप्पणी ने "उपयोगकर्ता को केवल एसिंक्रोनस विधियों को लिखने के लिए मजबूर करने" के साथ एक समस्या का उल्लेख किया है, यही वह समस्या है जिसे मैंने अपनी टिप्पणी में संबोधित करने का प्रयास किया था। यह लागू करना कि उपयोगकर्ता ने आपके द्वारा अपेक्षित अनुबंध का पालन किया है, जहां भी उपयोगकर्ता का कोड लाइब्रेरी में वापस भेजा जाना चाहिए, और इस बारे में चर्चा से कोई लेना-देना नहीं है कि क्या सजावटी को क्लास इंटर्नल में प्रस्तुत प्रकार-आकार को बदलना चाहिए। उपयोगकर्ता के कोड को एपीआई प्रदान करने की ऑर्थोगोनल समस्या को मानक विरासत या संरचना दृष्टिकोण के साथ हल किया जा सकता है।

@ohjames केवल डेकोरेटर लगाने से वर्ग नहीं बदला जाता है। जेएस शुद्धता को लागू नहीं करता है, इसलिए स्पष्ट रूप से आपके कोड में कहीं भी कोई भी बयान कुछ और संशोधित कर सकता है, लेकिन यह इस सुविधा चर्चा के लिए अप्रासंगिक है। एक बार सुविधा लागू होने के बाद भी, टाइपस्क्रिप्ट आपको कार्य निकायों के भीतर मनमाने संरचनात्मक परिवर्तनों को ट्रैक करने में मदद नहीं करेगा।

@masaeedu आप बिट्स उठा रहे हैं, लेकिन मैं बड़ी तस्वीर के बारे में बात कर रहा हूं। कृपया इस धागे में मेरी सभी टिप्पणियों की समीक्षा करें - मुद्दा व्यक्तिगत मुद्दों में नहीं है बल्कि प्रत्येक मुद्दे में एक ही समय में हो रहा है। मुझे लगता है कि मैंने विरासत-आधारित दृष्टिकोण के साथ समस्या को अच्छी तरह समझाया - बहुत सारे और बहुत सारे कोड डुप्लिकेशन।

स्पष्टता के लिए, यह मेरे लिए "क्लीन कोड" के बारे में नहीं है। समस्या व्यावहारिकता में से एक है; यदि आप @foo को फ़ंक्शन एप्लिकेशन के समान मानते हैं तो आपको टाइप सिस्टम में बड़े पैमाने पर बदलाव की आवश्यकता नहीं है। यदि आप किसी फ़ंक्शन के तर्क को उसके रिटर्न प्रकार से टाइप जानकारी को पेश करने की कोशिश करने के कीड़े के डिब्बे खोलते हैं, जबकि साथ ही टाइप इंट्रेंस और टाइपस्क्रिप्ट टाइप सिस्टम के विभिन्न कोनों में पाए जाने वाले अन्य सभी जादुई जानवरों के साथ बातचीत करते हैं, मुझे लगता है यह नई सुविधाओं के लिए उसी तरह एक बड़ी बाधा बन जाएगा जिस तरह से अब ओवरलोडिंग है।

@TomMarius इस सूत्र में आपकी पहली टिप्पणी स्वच्छ कोड के बारे में है, जो प्रासंगिक नहीं है। अगली टिप्पणी इस ऑनलाइन सेवा अवधारणा के बारे में है जिसके लिए आपने उदाहरण कोड प्रदान किया है। प्राथमिक शिकायत, पहले पैराग्राफ से चौथे तक, इस बारे में है कि MyService extends Service<MyService> का उपयोग करने में त्रुटि कैसे होती है। मैंने एक उदाहरण दिखाने की कोशिश की कि आप इससे कैसे निपट सकते हैं।

मैंने इसे फिर से देखा है, और मैं वास्तव में उस उदाहरण में कुछ भी नहीं देख सकता जो यह दर्शाता है कि सजाए गए वर्ग के सदस्यों को सजावटी के बारे में पता होना चाहिए। इन नई संपत्तियों के बारे में क्या है जो आप उपयोगकर्ता को प्रदान करते हैं जिन्हें मानक विरासत के साथ पूरा नहीं किया जा सकता है? मैंने प्रतिबिंब के साथ काम नहीं किया है, इसलिए मैंने उस पर स्किम्ड किया, मेरी माफ़ी।

@masaeedu मैं इसे विरासत के साथ पूरा कर सकता हूं, लेकिन विरासत मुझे/मेरे उपयोगकर्ताओं को बड़े पैमाने पर डुप्लिकेट कोड के लिए मजबूर करती है, इसलिए मैं एक और तरीका चाहता हूं - और मैं करता हूं, लेकिन टाइप सिस्टम वास्तविकता को सही ढंग से प्रतिबिंबित करने में सक्षम नहीं है।

मुद्दा यह है कि सही प्रकार का <strong i="7">@service</strong> class X { } जहां service को <T>(target: T) => T & IService के रूप में घोषित किया गया है, वह 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 । हालाँकि बहुत सारे मामले ऐसे थे जिन्हें कार्यान्वयन बहुत पहले किया गया था। मुझे लगता है कि विशेष रूप से सज्जाकार उन महत्वपूर्ण ईंटों में से एक हैं जो वास्तव में महत्वपूर्ण थे क्योंकि वे पहले से ही इतने ढांचे में उपयोग किए गए थे और एक बहुत ही सरल संस्करण पहले से ही बेबेल/टीएस में लागू किया गया है। यदि इस मुद्दे को लागू किया जा सकता है तो यह आधिकारिक रिलीज तक अपनी प्रयोगात्मक स्थिति नहीं खोएगा। लेकिन यह "प्रयोगात्मक" के लिए है।

@pietschy हां, टाइप चेकिंग के साथ @ सिंटैक्स चीनी को ठीक से काम करना अच्छा होगा। फिलहाल आप समान रूप से समान संक्षिप्तता प्राप्त करने के लिए फ़ंक्शन संरचना का उपयोग कर सकते हैं:

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

const MyComponent = decorator(class {
});

पिछली चर्चा इस बारे में है कि क्या किसी प्रकार का उलटा टाइपिंग करना एक अच्छा विचार है, जहां डेकोरेटर के रिटर्न प्रकार को this के प्रकार के रूप में कक्षा के सदस्यों को प्रस्तुत किया जाता है।

हाय @masaeedu , हाँ, मैं चर्चा के संदर्भ को समझ गया, इसलिए // do stuff with undo context, component methods etc । चियर्स

वास्तव में मिक्सिन को आसान बनाने की आवश्यकता है।

टाइपस्क्रिप्ट (जावास्क्रिप्ट) एकाधिक वंशानुक्रम का समर्थन नहीं करता है, इसलिए हमें मिक्सिन्स या ट्रैट्स का उपयोग करना चाहिए।
और अब यह मुझे बहुत समय बर्बाद कर रहा है, खासकर जब मैं कुछ पुनर्निर्माण करता हूं।
और मुझे हर जगह इसके "खाली कार्यान्वयन" के साथ एक इंटरफ़ेस को कॉपी और पेस्ट करना होगा। (#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());

इसलिए यदि सज्जाकारों द्वारा परिभाषित विधियां पहले से मौजूद हैं और वैध रूप से कॉल की जा सकती हैं तो यह अच्छा होगा यदि टाइपस्क्रिप्ट इसे प्रतिबिंबित करे।

इच्छा यह है कि टाइपस्क्रिप्ट बिना वर्कअराउंड लगाए इसे प्रतिबिंबित करे। अगर अन्य हैं
चीजें जो डेकोरेटर कर सकते हैं जिन्हें मॉडलिंग नहीं किया जा सकता है तो यह कम से कम अच्छा होगा यदि यह
परिदृश्य को किसी आकार या रूप में समर्थित किया गया था।

यह धागा इस बात पर राय से भरा है कि सज्जाकारों को क्या करना चाहिए , उनका उपयोग कैसे किया जाना चाहिए , उनका उपयोग कैसे नहीं किया जाना चाहिए, आदि विज्ञापन मतली ।

यह वही है जो सज्जाकार वास्तव में करते हैं:

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 के साथ, प्रत्येक के पास एक पूरी नई कक्षा वापस करने का विकल्प होता है।

मैं समझता हूं कि टाइप सिस्टम को समर्थन और स्वीकार करने के लिए यह बहुत मुश्किल हो सकता है, और मैं समझता हूं कि इसका समर्थन करने में बहुत समय लग सकता है, लेकिन क्या हम सभी इस बात से सहमत नहीं हो सकते हैं कि ऊपर के मूल कोड नमूने से वर्तमान व्यवहार ने इसे शुरू किया धागा, बस गलत है?

कोई फर्क नहीं पड़ता कि डेकोरेटर्स या मिक्सिन्स या फंक्शनल कंपोजिशन आदि आदि पर किसी भी डेवलपर की राय क्या है, यह एक बहुत ही स्पष्ट बग प्रतीत होता है।

क्या मैं विनम्रता से पूछ सकता हूं कि क्या यह भविष्य में रिलीज के लिए पाइपलाइन में है?

टाइपस्क्रिप्ट बस अद्भुत है और मुझे यह पसंद है; हालांकि यह कुछ (केवल?) टुकड़ों में से एक जैसा लगता है जो बस टूटा हुआ है, और मैं इसे ठीक करने के लिए उत्सुक हूं :)

@arackaf यह अच्छी तरह से समझा जाता है कि सजावटी वास्तव में क्या करते हैं, और यह मानते हुए कि आप टाइपस्क्रिप्ट के उत्सर्जन के प्रकारों की परवाह नहीं करते हैं जो पहले से ही सजावटी का समर्थन करते हैं। इस अंक में पूरी बहस इस बात को लेकर है कि सजाए गए वर्गों को टाइप सिस्टम में कैसे प्रस्तुत किया जाए।

मैं सहमत हूं कि 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"; }
}

आप केवल "मुश्किल" होने के नाते समस्या को दूर नहीं कर सकते हैं, किसी को वास्तव में यह प्रस्तावित करने की आवश्यकता है कि यह कैसे काम करना चाहिए।

कोई त्रुटि नहीं - आप लॉगर को एक वर्ग पास कर रहे हैं जो ग्रीटर के अनुरूप है; हालांकि फू को डेकोरेटर द्वारा पूरी तरह से कुछ अलग करने के लिए उत्परिवर्तित किया जाता है, जो अब ग्रीटर का विस्तार नहीं करता है। तो यह लॉगर डेकोरेटर के लिए फू को ग्रीटर के रूप में मानने के लिए मान्य होना चाहिए, लेकिन किसी और के लिए अमान्य है, क्योंकि फू को डेकोरेटर द्वारा पूरी तरह से अलग करने के लिए पुन: असाइन किया गया है।

मुझे यकीन है कि इसे लागू करना बेहद मुश्किल होगा। क्या इस धागे के शीर्ष पर सूचीबद्ध सामान्य मामलों के लिए कुछ उचित उपसमुच्चय संभव है, इस तरह के मुश्किल किनारे के मामलों के लिए इंटरफेस विलय जैसे वर्कअराउंड विलय के साथ?

@अराकाफ

हालांकि फू को डेकोरेटर द्वारा पूरी तरह से कुछ अलग करने के लिए उत्परिवर्तित किया जाता है

पहली जगह में Foo क्या है इसकी कोई सटीक परिभाषा नहीं है। याद रखें कि हमारा पूरा विवाद यह है कि क्या Foo के सदस्यों को एक्सेस करने में सक्षम होना चाहिए (और इसलिए सार्वजनिक एपीआई के हिस्से के रूप में वापस आते हैं), डेकोरेटर ने सदस्यों को this से पेश किया। Foo को डेकोरेटर क्या लौटाता है, और डेकोरेटर क्या रिटर्न करता है, यह परिभाषित करता है कि Foo क्या है। वे अविभाज्य रूप से विभाजित हैं।

मुझे यकीन है कि इसे लागू करना बेहद मुश्किल होगा

कार्यान्वयन जटिलता के बारे में बात करना अभी भी समय से पहले है, जब हमारे पास इस बात का कोई ठोस प्रस्ताव भी नहीं है कि इस सुविधा को कैसे काम करना चाहिए। इस पर जोर देने के लिए खेद है, लेकिन हमें वास्तव में किसी ऐसे व्यक्ति की आवश्यकता है जो " this का क्या होता है जब मैं इस तरह के वर्ग के लिए सजावटी के इस तरह के अनुक्रम को लागू करता हूं" के लिए एक ठोस तंत्र का प्रस्ताव देता हूं। फिर हम विभिन्न टाइपस्क्रिप्ट अवधारणाओं को अलग-अलग भागों में जोड़ सकते हैं और देख सकते हैं कि जो सामने आता है वह समझ में आता है या नहीं। तभी कार्यान्वयन की जटिलता पर चर्चा करना समझ में आता है।

क्या वर्तमान डेकोरेटर आउटपुट जिसे मैंने ऊपर चिपकाया है वह विशिष्ट अनुरूप नहीं है? मैंने मान लिया कि यह मैंने जो देखा है उससे था।

यह मानते हुए, फू का हर कदम पर काफी सटीक अर्थ है। मैं उम्मीद करता हूं कि टीएस मुझे अंतिम डेकोरेटर के रिटर्न के आधार पर this (फू विधियों के अंदर और फू के उदाहरणों पर) का उपयोग करने की अनुमति देगा, टीएस ने मुझे आवश्यकतानुसार टाइप एनोटेशन जोड़ने के लिए मजबूर किया है यदि डेकोरेटर फ़ंक्शन पर्याप्त रूप से विश्लेषण योग्य नहीं हैं।

@arackaf कोई "रास्ते के कदम" नहीं हैं; हम किसी दिए गए अपरिवर्तनीय कोड स्निपेट के लिए केवल अंतिम प्रकार के this से चिंतित हैं। आपको कम से कम एक उच्च स्तर पर वर्णन करने की आवश्यकता है कि आप किस प्रकार की अपेक्षा करते हैं this एक वर्ग के सदस्यों के लिए X डेकोरेटर कार्यों से सजाए गए f1...fn के संदर्भ में होना चाहिए। X और f1...fn के प्रकार के हस्ताक्षर। आपके पास इस प्रक्रिया में जितने चाहें उतने चरण हो सकते हैं। अब तक, कोई भी ऐसा नहीं कर रहा है। मैं अनुमान लगा रहा हूं कि लोगों का मतलब है कि डेकोरेटर के रिटर्न प्रकार को this के प्रकार के रूप में प्रस्तुत किया जाना चाहिए, लेकिन सभी के लिए मुझे पता है कि मैं पूरी तरह से निशान से बाहर हो सकता हूं।

यदि आपका प्रस्ताव यांत्रिक रूप से प्रकारों को प्रतिबिंबित करने के लिए है कि ट्रांसपिल्ड आउटपुट में मूल्यों के साथ क्या हो रहा है, तो आप जो प्रस्तावित कर रहे हैं उसके बजाय मैं जो प्रस्तावित कर रहा हूं उसके साथ समाप्त होता है: यानी new Foo().hello() ठीक है, लेकिन this.hello() नहीं है। उस उदाहरण में किसी भी बिंदु पर आप जिस मूल वर्ग को सजा रहे हैं वह hello विधि प्राप्त नहीं करता है। केवल __decorate([addMethod], Foo) (जो तब Foo को सौंपा गया है) के परिणाम में hello विधि है।

मैं अनुमान लगा रहा हूं कि लोगों का मतलब है कि डेकोरेटर के रिटर्न प्रकार को इस प्रकार के रूप में प्रस्तुत किया जाना चाहिए

ओह, क्षमा करें, हाँ, यह सही है। ठीक है कि। पूर्ण विराम। क्योंकि यही सज्जाकार करते हैं। यदि लाइन में अंतिम डेकोरेटर कुछ पूरी तरह से नया वर्ग लौटाता है, तो वह वही है जो फू है।

दूसरे शब्दों में:

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

फू दुनिया में जो कुछ भी है c कहता है वह है। यदि c एक ऐसा फ़ंक्शन है जो any लौटाता है, तो मुझे नहीं पता - शायद मूल Foo पर वापस आ जाए? यह एक उचित, पिछड़े संगत दृष्टिकोण की तरह लगता है।

लेकिन अगर c कुछ नया प्रकार X $ लौटाता है, तो मैं पूरी तरह से फू से इसका सम्मान करने की अपेक्षा करता हूं।

क्या मैं कुछ भूल रहा हूँ?

आगे स्पष्ट करते हुए, यदि

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 टाइपिंग की परिपत्रता के बारे में अपनी आपत्ति को निलंबित करता हूं, जो कि 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()

टाइपिंग या रनटाइम मूल्यांकन के मामले में कोड के साथ कोई समस्या नहीं है। मैं नया फू ()। हैलो () कह सकता हूं, जो आंतरिक रूप से सजाए गए वर्ग के हैलो को कॉल करेगा, जो सजाए गए वर्ग के बार को कॉल करेगा

लेकिन यह कहना एक त्रुटि होनी चाहिए

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

चूंकि फू की हैलो विधि अब लकड़हारा रिटर्न की कक्षा के अनुसार शून्य हो जाती है।

ज़रूर - लेकिन मैंने कहा कि new Foo().foo() . का आह्वान करना एक त्रुटि थी

@arackaf लेकिन इससे कोई फर्क नहीं पड़ता। मैंने new Foo().foo() आह्वान नहीं किया। मैंने this.foo() आह्वान किया, और मुझे एक प्रकार की त्रुटि मिली, भले ही मेरा कोड रनटाइम पर ठीक काम करता है।

लेकिन let s : string = new Foo().hello() . कहने में त्रुटि होनी चाहिए

फिर, यह अप्रासंगिक है। मैं यह नहीं कह रहा हूं कि Foo.prototype.hello () => string चाहिए (मैं मानता हूं कि यह () => void होना चाहिए)। मैं वैध आमंत्रण this.bar() त्रुटिपूर्ण होने के बारे में शिकायत कर रहा हूं, क्योंकि आपने शल्य चिकित्सा द्वारा एक प्रकार का प्रत्यारोपण किया है जहां इसे प्रत्यारोपण करना बेमानी है।

यहाँ दो फू हैं। जब आप कहें

class Foo { 
}

फू कक्षा के भीतर एक अपरिवर्तनीय बंधन है, और कक्षा के बाहर एक परिवर्तनीय बंधन है। तो यह पूरी तरह से काम करता है जैसा कि आप एक jsbin में सत्यापित कर सकते हैं

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

let F = Foo;

Foo = null;

new F().hello();

उपरोक्त आपका उदाहरण समान कार्य करता है; बाहरी बाध्यकारी उत्परिवर्तित होने से पहले यह मूल वर्ग के संदर्भ को कैप्चर करता है। मुझे अब भी समझ नहीं आ रहा है कि आप क्या चला रहे हैं।

this.foo(); पूरी तरह से मान्य है, और मुझे एक प्रकार की त्रुटि की उम्मीद नहीं होगी (यदि मुझे किसी संदर्भ की आवश्यकता है तो मैं टीएस लोगों को भी दोष नहीं दूंगा, क्योंकि मुझे यकीन है कि इसका पता लगाना कठिन होगा)

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 ।

यह एक अजीबोगरीब, मजेदार सामान्य ज्ञान है, लेकिन मुझे नहीं लगता कि यह टीएस को उत्परिवर्तित वर्ग सज्जाकारों को संभालने से क्यों रोकना चाहिए।

@arackaf आप सवाल का जवाब नहीं दे रहे हैं। विशेष रूप से this का प्रकार क्या है? आप अंतहीन रूप से उत्तर नहीं दे सकते " this is Foo और Foo is this "। this में कौन से सदस्य हैं? यदि इसमें hello(): void के अलावा कोई सदस्य है, तो उन्हें निर्धारित करने के लिए किस तर्क का उपयोग किया जा रहा है?

जब आप कहते हैं " this.foo() मूल फू के भीतर एक प्रकार की त्रुटि नहीं है", तो आपको अभी भी इस प्रश्न का उत्तर देने की आवश्यकता है: this का संरचनात्मक प्रकार क्या है जैसे कि यह एक प्रकार की त्रुटि नहीं है this.foo() करो?

साथ ही, मूल वर्ग "पहुंच योग्य" नहीं है। उस कोड स्निपेट में परिभाषित प्रत्येक फ़ंक्शन को रनटाइम पर सक्रिय रूप से प्रयोग किया जाता है, और यह सब बिना किसी रोक-टोक के काम करता है। कृपया मेरे द्वारा प्रदान किया गया खेल का मैदान लिंक चलाएं और कंसोल को देखें। डेकोरेटर एक नया वर्ग देता है जिसमें hello विधि डेकोरेटेड क्लास की hello विधि को दर्शाती है, जो बदले में सजाए गए वर्ग की foo विधि को दर्शाती है।

यह एक अजीबोगरीब, मजेदार सामान्य ज्ञान है, लेकिन मुझे नहीं लगता कि यह टीएस को उत्परिवर्तित वर्ग सज्जाकारों को संभालने से क्यों रोकना चाहिए।

टाइप सिस्टम में कोई "ट्रिविया" नहीं है। आपको 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() कहते हैं - क्लास मूल फू को इंगित कर रहा है, और टाइपस्क्रिप्ट के परिप्रेक्ष्य से इसकी पहुंच hello(): string तक होगी क्योंकि क्लास को टाइप किया गया है (ग्रीटर को बढ़ाता है)। रनटाइम पर आप मूल फू के उदाहरण को तुरंत चालू कर देंगे।

new LoggableFoo().hello() एक शून्य विधि को कॉल करने के लिए होता है जो एक ऐसी विधि को कॉल करने के लिए होता है जो अन्यथा पहुंच योग्य नहीं है, ग्रीटर के माध्यम से टाइप किया जाता है।

अगर आपने किया होता

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

तो फू अब एक वर्ग है जिसमें केवल हैलो (): शून्य और नया फू ()। फू () एक प्रकार की त्रुटि होनी चाहिए।

और, फिर से, hello() { return this.foo(); } एक TypeError नहीं है - ऐसा क्यों होगा? सिर्फ इसलिए कि वह वर्ग परिभाषा अब उपलब्ध नहीं है, किसी भी तरह से उस विधि को अमान्य नहीं बनाता है।

मुझे उम्मीद नहीं है कि टाइपस्क्रिप्ट इनमें से किसी भी किनारे के मामलों को सही करेगा; हमेशा की तरह यहां और वहां टाइप एनोटेशन जोड़ना काफी समझ में आता है। लेकिन इनमें से कोई भी उदाहरण यह नहीं दिखाता है कि @logger मूल रूप से उस चीज़ को क्यों नहीं बदल सकता है जिसके लिए Foo बाध्य है।

यदि logger एक ऐसा फ़ंक्शन है जो एक नया वर्ग देता है, तो फू अब संदर्भित करता है।

मैंने हर सवाल का जवाब दिया है कि यह क्या है और कहां है।
इस मामले का साधारण तथ्य यह है कि आप जहां हैं, उसके आधार पर this का अर्थ बदल जाता है।

यह वास्तव में निराशाजनक है। ठीक है, यह बदलता है, यह Foo है, यह एक स्थिर बंधन है, इत्यादि इत्यादि। हस्ताक्षर प्रकार क्या है? this में कौन से सदस्य हैं? आप सूरज के नीचे सब कुछ के बारे में बात कर रहे हैं, जब मुझे आपसे केवल एक साधारण प्रकार का हस्ताक्षर चाहिए जो this के अंदर है hello ।

new LoggableFoo().hello() एक शून्य विधि को कॉल करने के लिए होता है जो एक ऐसी विधि को कॉल करने के लिए होता है जो अन्यथा पहुंच योग्य नहीं है, ग्रीटर के माध्यम से टाइप किया जाता है।

यह अगम्य के समान नहीं है। प्रत्येक पहुंच योग्य विधि "अन्यथा पहुंच योग्य नहीं है" जब आप उन पथों को छूट देते हैं जिनके माध्यम से यह पहुंच योग्य है।

यदि आपने किया था:

लेकिन यह सचमुच मैंने किया है। ठीक यही मेरा कोड स्निपेट है, जिसे मैंने आपके लिए बनाए गए उदाहरण की व्याख्या के साथ फिर से चिपकाया है। मैंने यह सुनिश्चित करने के लिए एक अलग चेकर के माध्यम से भी इसे चलाया कि मैं पागल गोलियां नहीं ले रहा था, और केवल अंतर ही आपके द्वारा हटाई गई टिप्पणी है।

और, फिर से, hello() { return this.foo(); } एक TypeError नहीं है - ऐसा क्यों होगा?

क्योंकि आप (और यहां अन्य) चाहते हैं कि this का प्रकार डेकोरेटर का तत्काल वापसी प्रकार हो, जो { hello(): void } है ( foo सदस्य की अनुपस्थिति पर ध्यान दें)। यदि आप चाहते हैं कि Foo के सदस्य this को डेकोरेटर के रिटर्न प्रकार के रूप में देख सकें, तो this के अंदर hello का प्रकार { 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 के अंदर यह एक सी # अनाम प्रकार के समकक्ष को संदर्भित करेगा-एक पूरी तरह से वास्तविक प्रकार, जो अन्यथा मान्य है, वास्तव में सीधे संदर्भित करने में सक्षम नहीं है। ऊपर वर्णित त्रुटियों और गैर-त्रुटियों को प्राप्त करना अजीब लगेगा, लेकिन फिर से, यह ठीक इसी तरह काम करता है। सज्जाकार हमें इस तरह के अजीबोगरीब काम करने की जबरदस्त ताकत देते हैं।

मुझे लगता है कि आपको उपरोक्त फू के अंदर कुछ अलग होने में कुछ अजीबता मिलती है, यह उन उदाहरणों में है जो बाद में फू अंततः (सज्जाकारों के चलने के बाद) से बनाए जाते हैं?

नहीं, मुझे इसमें कोई विचित्रता नहीं लगती, क्योंकि ठीक यही मैं 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 सदस्यों की एक व्यापक सूची नहीं निकाल सकता, या प्रस्ताव के तहत इस तरह की सूची का निर्माण कैसे किया जाएगा।

इसे दूसरे तरीके से रखने के लिए, (मूल) फू के अंदर टाइप सिग्नेचर फू की तुलना में अलग होंगे/सज्जाकारों के चलने के बाद उत्पन्न होते हैं।

तो तुम मुझसे बहस भी क्यों कर रहे हो? मैंने कहा: "मैं मानता हूं कि new Foo().foo टाइप एरर होने के कारण एक बग है, और उस पर आसानी से तय हो गया है। मैं इस बात से सहमत नहीं हूं कि इसे लौटाएं। टाइप एरर होना एक बग है"। समान रूप से, आपके उदाहरण में, मैं सहमत हूं कि new Foo().x() एक प्रकार की त्रुटि होना एक बग है, लेकिन this.x() एक प्रकार की त्रुटि होना नहीं है।

आप देखते हैं कि इस पृष्ठ के शीर्ष पर स्निपेट में दो टिप्पणियां कैसे हैं?

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

^ वह वही है जो मुझे समस्याग्रस्त लगता है। या तो आप सहमत हैं कि डेकोरेटर का रिटर्न प्रकार this पर प्रस्तुत नहीं किया जाना चाहिए, और केवल new Foo() पर, इस मामले में हम दोनों कुछ भी नहीं के बारे में बहस कर रहे हैं। या आप सहमत नहीं हैं और उस सुविधा को भी चाहते हैं, ऐसे में आपकी पिछली टिप्पणी में स्निपेट अप्रासंगिक है।

मैं अंत में आपकी बात समझ गया। आपके ग्रीटिंग कोड से इसे प्राप्त करना मेरे लिए बहुत कठिन था, लेकिन मैं अभी ट्रैक कर रहा हूं; इतने धैर्यवान होने के लिए धन्यवाद।

मैं कहूंगा कि एकमात्र समझदार समाधान फू (फू के अंदर ) प्रकार संघ का समर्थन करने के लिए होगा - डीआरपी मेरा मतलब चौराहे - मूल फू का है, और जो भी अंतिम सजावटी लौटाता है। आपको अपने अभिवादन जैसे पागल उदाहरणों के लिए मूल Foo का समर्थन करना होगा, और आपको निश्चित रूप से अंतिम डेकोरेटर का समर्थन करने की आवश्यकता है क्योंकि यह डेकोरेटर्स का उपयोग करने का पूरा बिंदु है (उपरोक्त कई टिप्पणियों के अनुसार)।

तो हाँ, मेरे सबसे हालिया उदाहरण से, Foo x, y, z, a, b, c के अंदर सभी काम करेंगे। यदि a के दो संस्करण थे, तो दोनों का समर्थन करें।

@arackaf np, आपके धैर्य के लिए भी धन्यवाद। मेरे उदाहरण सबसे स्पष्ट नहीं हैं क्योंकि मैं खेल के मैदान में जो कुछ भी पका सकता हूं उसे पोस्ट कर रहा हूं जो दर्शाता है कि यह कैसे टूटा हुआ है। मेरे लिए इसके बारे में व्यवस्थित रूप से सोचना कठिन है।

मैं कहूंगा कि मूल फू के प्रकार संघ का समर्थन करने के लिए फू (फू के अंदर) के लिए एकमात्र समझदार समाधान होगा, और जो भी अंतिम सजावटी लौटता है।

ठीक है बहुत बढ़िया, तो अब हम इसकी बारीकियों में जा रहे हैं। अगर मुझे यह गलत लग रहा है तो मुझे सुधारें, लेकिन जब आप "संघ" कहते हैं तो आपका मतलब है कि इसमें दोनों प्रकार के सदस्य होने चाहिए, यानी यह A & B होना चाहिए। इसलिए हम चाहते हैं कि this typeof(new OriginalClass()) & typeof(new (decorators(OriginalClass))) हो, जहां decorators सभी डेकोरेटर्स का कंपोज्ड टाइप सिग्नेचर है। सादे अंग्रेजी में, हम चाहते हैं कि this "मूल वर्ग" के तात्कालिक प्रकार का प्रतिच्छेदन हो और "मूल वर्ग" का तात्कालिक प्रकार सभी सज्जाकारों से होकर गुजरा।

इसमें दो समस्याएं हैं। एक यह है कि मेरे उदाहरण जैसे मामलों में, यह आपको गैर-मौजूद सदस्यों तक पहुंचने की अनुमति देता है। मैं डेकोरेटर में सदस्यों का एक समूह जोड़ सकता था, लेकिन अगर मैंने this.newMethod() का उपयोग करके उन्हें अपनी कक्षा में एक्सेस करने का प्रयास किया, तो यह रनटाइम पर ही उल्टी हो जाएगा। newMethod को केवल डेकोरेटर फ़ंक्शन से लौटाए गए वर्ग में जोड़ा जाता है, मूल वर्ग के सदस्यों के पास इसकी कोई पहुंच नहीं होती है (जब तक कि मैं विशेष रूप से return class extends OriginalClass { newMethod() { } } पैटर्न का उपयोग नहीं करता)।

दूसरी समस्या यह है कि "मूल वर्ग" एक अच्छी तरह से परिभाषित अवधारणा नहीं है। अगर मैं सजाए गए सदस्यों को this से एक्सेस कर सकता हूं, तो मैं उन्हें रिटर्न स्टेटमेंट के हिस्से के रूप में भी इस्तेमाल कर सकता हूं, और इसलिए वे "मूल वर्ग" के सार्वजनिक एपीआई का हिस्सा हो सकते हैं। मैं यहाँ एक तरह से हाथ हिला रहा हूँ, और ठोस उदाहरणों के बारे में सोचने के लिए मैं थोड़ा बहुत जल गया हूँ, लेकिन मुझे लगता है कि अगर हम इसके बारे में कठिन सोचते हैं तो हम निरर्थक उदाहरणों के साथ आ सकते हैं। हो सकता है कि आप उन सदस्यों को अलग करने का कोई तरीका ढूंढकर इस पर काम कर सकें जो this से एक्सेस की गई चीज़ों को वापस नहीं करते हैं या कम से कम जिसके लिए this.something() लौटने के परिणामस्वरूप रिटर्न प्रकार का अनुमान नहीं लगाया जाता है

@masaeedu हाँ, मैंने आपके उत्तर से पहले संघ/चौराहे की बात पर खुद को सही किया। यह TS के लिए नए व्यक्ति के लिए प्रति-सहज ज्ञान युक्त है।

बाकी समझ में आ गया। ईमानदारी से सज्जाकार आमतौर पर एक पूरी तरह से अलग प्रकार नहीं लौटाएंगे, वे आम तौर पर केवल उस प्रकार को बढ़ाएंगे जो पारित किया गया था, इसलिए चौराहे की चीज ज्यादातर समय सुरक्षित रूप से "बस काम करेगी"।

मैं कहूंगा कि आप जिस रनटाइम त्रुटियों के बारे में बात करते हैं वह दुर्लभ होगी, और कुछ उद्देश्यपूर्ण खराब विकास निर्णयों का नतीजा होगा। मुझे यकीन नहीं है कि आपको वास्तव में इस बारे में परवाह करने की ज़रूरत है, लेकिन अगर यह वास्तव में एक समस्या है, तो मैं कहूंगा कि आखिरी सजावटी जो लौटाया गया है वह एक सभ्य दूसरा स्थान होगा (इसलिए हाँ, एक वर्ग एक TypeError देख सकता है एक ऐसी विधि का उपयोग करने की कोशिश करना जो स्वयं परिभाषित हो - आदर्श नहीं, लेकिन फिर भी काम करने वाले सज्जाकारों के लिए भुगतान करने के लिए एक सार्थक कीमत)।

लेकिन वास्तव में, मुझे लगता है कि आप जिस रनटाइम त्रुटियों के बारे में सोच रहे हैं, वे निश्चित रूप से सही ढंग से काम करने वाले सजावटी की कीमत पर रोकने लायक नहीं हैं। इसके अलावा, यदि आप लापरवाह या मूर्ख हैं, तो TS में रनटाइम त्रुटियाँ उत्पन्न करना काफी आसान है।

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

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

आपकी दूसरी आपत्ति के संबंध में

मैं उन्हें रिटर्न स्टेटमेंट के हिस्से के रूप में भी इस्तेमाल कर सकता हूं, और इसलिए वे "मूल वर्ग" के सार्वजनिक एपीआई का हिस्सा हो सकते हैं

मुझे डर है कि मुझे इसमें कोई समस्या नहीं दिख रही है। मैं चाहता हूं कि एक डेकोरेटर के माध्यम से कक्षा में कुछ भी जोड़ा जाए ताकि वह प्रथम श्रेणी का नागरिक हो। मैं उत्सुक हूं कि वहां संभावित समस्याएं क्या होंगी।

मुझे लगता है कि एक अन्य अच्छा विकल्प केवल इसे आंशिक रूप से लागू करना होगा।

वर्तमान में, कक्षाएं हमेशा परिभाषित के अनुसार टाइप की जाती हैं। तो फू के अंदर, यह डेकोरेटर्स की परवाह किए बिना फू को परिभाषित करने पर आधारित है। डेकोरेटर उपयोग मामलों (यानी सबसे आम वाले) के कुछ उपयोगी सबसेट के लिए यह "बस" विस्तार करने के लिए एक बड़ा, बड़ा सुधार होगा।

क्या होगा यदि आप कक्षा को विस्तारित करने की अनुमति देते हैं (कक्षा के अंदर this के परिप्रेक्ष्य से) यदि और केवल तभी सजावटी कुछ देता है जो मूल को बढ़ाता है, यानी के लिए

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

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

क्या यह सिर्फ काम करता है, और ब्लाह को प्रथम श्रेणी का समर्थन प्रदान करता है और डेकोरेटर द्वारा जोड़ा गया कुछ भी। और उपयोग के मामलों के लिए जो पागल चीजें करते हैं जैसे एक पूरी नई कक्षा (जैसे आपका अभिवादन), बस वर्तमान व्यवहार जारी रखें, और सजावटकर्ता क्या कर रहा है उसे अनदेखा करें।

बीटीडब्ल्यू, आप जो भी चुनते हैं, मैं उसकी व्याख्या कैसे करूंगा? क्या इसे वर्तमान में एनोटेट किया जा सकता है? मैंने कोशिश की

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

साथ ही उस विषय पर कई भिन्नताएं, लेकिन टाइपस्क्रिप्ट में से कोई भी नहीं था :)

@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 के साथ भी टूट जाएंगी।

आपको यह काम करने के लिए सभी प्रकार के हुप्स और गर्भपात से कूदना होगा, और टाइप सिस्टम आपको हर कदम पर लड़ेगा, क्योंकि आप जो कर रहे हैं वह सामान्य मामले में बेमानी है। इससे भी महत्वपूर्ण बात यह है कि एक बार जब आप इसे लागू कर लेते हैं, तो जब भी वे किसी अन्य जटिल (लेकिन ध्वनि) अवधारणा को लागू करने की कोशिश कर रहे होते हैं, तो हर किसी को टाइप सिस्टम के इस निरर्थक कोने के चारों ओर कलाबाजी से पैंतरेबाज़ी करनी होगी।

सिर्फ इसलिए कि आपके पास यह एक उपयोग का मामला है जो आपको लगता है कि महत्वपूर्ण है (और मैंने इस धागे में कई बार कोशिश की है कि आप मौजूदा प्रकार की प्रणाली में जो चाहते हैं उसे व्यक्त करने के वैकल्पिक तरीकों को प्रदर्शित करें), इसका मतलब यह नहीं है कि केवल सही चीज करने के लिए किसी भी कीमत पर अपने सुझाए गए दृष्टिकोण के साथ आगे बढ़ना है। आप अपनी कक्षा में मनमाने ढंग से इंटरफेस को मर्ज कर सकते हैं, जिसमें रिटर्न प्रकार के डेकोरेटर फ़ंक्शंस शामिल हैं, इसलिए ऐसा नहीं है कि यदि आप डेकोरेटर्स का उपयोग करने के तरीके का उपयोग करने पर जोर देते हैं तो आपके लिए कहीं भी पहुंचना असंभव नहीं है।

@अराकफ यह:

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

विस्तार खंड में ठीक काम करना चाहिए:

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 में, और एक वर्ग देता है जिसकी संरचना C & {blah(): void} है।

यही कारण है कि हम में से कई आज के लिए सज्जाकारों का सक्रिय रूप से उपयोग कर रहे हैं। हम वास्तव में, वास्तव में इस व्यवहार के एक उपयोगी सबसेट को टाइप सिस्टम में एकीकृत करना चाहते हैं।

यह आसानी से प्रदर्शित किया जाता है कि सज्जाकार विचित्र चीजें कर सकते हैं जो कि टाइप सिस्टम को ट्रैक करना असंभव होगा। जुर्माना! लेकिन उस पर टिप्पणी करने का कोई तरीका होना चाहिए

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

यह सही है। मुझे नहीं पता कि इसे c के लिए नए प्रकार के एनोटेशन सिंटैक्स की आवश्यकता होगी, या यदि मौजूदा प्रकार एनोटेशन सिंटैक्स को इसे पूरा करने के लिए c पर सेवा में दबाया जा सकता है, लेकिन सामान्य उपयोग को ठीक करना मामला (और किनारों को छोड़कर, मूल वर्ग पर कोई प्रभाव नहीं पड़ता) टीएस उपयोगकर्ताओं के लिए एक बड़ा वरदान होगा।

@justinfagnani फी दिस

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

का उत्पादन

टाइप करें 'टाइपोफ (बेनामी वर्ग)' 'टी और (नया () => {ब्लाह(): शून्य;})' टाइप करने के लिए असाइन करने योग्य नहीं है।
टाइप 'टाइपोफ (बेनामी वर्ग)' 'टी' टाइप करने के लिए असाइन करने योग्य नहीं है।

टीएस खेल के मैदान में। सुनिश्चित नहीं है कि मेरे पास कुछ विकल्प गलत हैं।

इसके लिए सुपरक्लास बनाने के बजाय, घोषित वर्ग के उपवर्गों द्वारा आप किस समस्या को हल करने का प्रयास कर रहे हैं?

मैं केवल सज्जाकार का उपयोग करने की कोशिश कर रहा हूँ। मैं खुशी-खुशी उन्हें एक साल से अधिक समय से JS में उपयोग कर रहा हूं - मैं बस TS को पकड़ने के लिए उत्सुक हूं। और मैं निश्चित रूप से उपवर्ग से शादी नहीं कर रहा हूँ। कभी-कभी सजावटी गुण या विधियों को जोड़ने के लिए मूल वर्ग के प्रोटोटाइप को बदल देता है। किसी भी तरह से, लक्ष्य टाइपस्क्रिप्ट को यह बताना है कि

<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 क्या वास्तव में कोई प्रतिबंधित उपयोग के मामले नहीं हैं जिनमें पूर्व को काम करने के लिए बनाया जा सकता है?

सटीक होने के लिए: क्या कोई एनोटेशन नहीं है टाइपस्क्रिप्ट हमें ऊपर दिए गए उदाहरण से a , b , और c में जोड़ने के लिए कह सकता है ताकि टाइप सिस्टम पूर्व का इलाज कर सके बाद वाले से अप्रभेद्य रूप से?

यह टाइपस्क्रिप्ट के लिए एक हत्यारा उन्नति होगी।

@arackaf क्षमा करें, आपको टाइप पैरामीटर को कन्स्ट्रक्टर प्रकार का संदर्भ देना है, उदाहरण प्रकार नहीं:

यह सही है:

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

मैं केवल सज्जाकार का उपयोग करने की कोशिश कर रहा हूँ।

यह वास्तव में कोई समस्या नहीं है जिसे आप हल करने का प्रयास कर रहे हैं, और यह एक तनातनी है। यह प्रश्न जैसा है: "उस हथौड़े से क्या करने की कोशिश कर रहे हैं?" ए: "बस हथौड़ा का प्रयोग करें"।

क्या आपके मन में कोई वास्तविक मामला है जहां इच्छित विस्तार के साथ एक नया सुपरक्लास उत्पन्न करना काम नहीं करता है? क्योंकि टाइपस्क्रिप्ट अब इसका समर्थन करता है, और जैसा कि मैंने कहा, उस मामले में कक्षा के अंदर से वर्ग के प्रकार के बारे में तर्क करना बहुत आसान है।

मैंने Mobx के @observer एनोटेशन को देखा और ऐसा लगता है कि यह वर्ग के आकार को नहीं बदलता है (और क्लास डेकोरेटर के बजाय आसानी से एक विधि डेकोरेटर हो सकता है क्योंकि यह केवल render() लपेटता है)।

@connect वास्तव में डेकोरेटर्स को ठीक से टाइप करने की जटिलताओं का एक बड़ा उदाहरण है, क्योंकि @connect सजाए गए वर्ग के उप-वर्ग को वापस नहीं लौटाता है, लेकिन एक पूरी तरह से नया वर्ग जो सजाए गए वर्ग को लपेटता है, फिर भी स्टैटिक्स को कॉपी किया जाता है, इसलिए परिणाम इंस्टेंस-साइड इंटरफ़ेस को फेंक देता है और स्थिर पक्ष को संरक्षित करता है जिसे TS ज्यादातर मामलों में जांच भी नहीं करता है। ऐसा लगता है कि @connect वास्तव में एक डेकोरेटर नहीं होना चाहिए और कनेक्ट को केवल एचओसी के रूप में उपयोग किया जाना चाहिए, क्योंकि एक सजावटी के रूप में, यह बहुत भ्रमित है।

मैं खुशी-खुशी उन्हें एक साल से अधिक समय से JS में उपयोग कर रहा हूं

अच्छा ... आपने वास्तव में नहीं किया है। JS में डेकोरेटर नहीं हैं। आप संभवतः एक विशेष निष्क्रिय पिछले प्रस्ताव का उपयोग कर रहे हैं, जो कि बैबेल और टाइपस्क्रिप्ट में थोड़ा अलग तरीके से लागू किया जाता है। अन्य स्थानों में मैं डेकोरेटर के लिए मानकीकरण प्रक्रिया के साथ जारी रखने के लिए बहस कर रहा हूं, लेकिन प्रगति धीमी हो गई है और मुझे नहीं लगता कि वे अभी तक निश्चित हैं। कई लोगों का तर्क है कि उन्हें जोड़ा नहीं जाना चाहिए, या केवल एनोटेशन होना चाहिए, इसलिए शब्दार्थ अभी भी हवा में हो सकते हैं।

सज्जाकारों के खिलाफ शिकायतों में से एक यह है कि वे वर्ग के आकार को बदल सकते हैं, जिससे सांख्यिकीय रूप से तर्क करना मुश्किल हो जाता है, और कुछ प्रस्तावों पर कम से कम सज्जाकारों की क्षमता को सीमित करने के बारे में बात की गई है, हालांकि मुझे लगता है कि यह पहले था सबसे हालिया प्रस्ताव को विशिष्ट भाषा मिली। मैं व्यक्तिगत रूप से तर्क देता हूं कि अच्छी तरह से व्यवहार करने वाले सज्जाकार वर्ग के आकार को बदलते हैं, ताकि स्थैतिक विश्लेषण के प्रयोजनों के लिए उन्हें अनदेखा किया जा सके। याद रखें कि मानक जेएस में एक प्रकार की प्रणाली नहीं है जो विश्लेषण को बताए कि फ़ंक्शन कार्यान्वयन क्या कर रहा है।

• मैं बस टीएस को पकड़ने के लिए उत्सुक हूं।

मैं नहीं देखता कि टाइपस्क्रिप्ट यहाँ किसी भी तरह से कैसे पीछे है। कम से कम पीछे क्या? सज्जाकार काम करते हैं। क्या कोई अन्य टाइप किया गया जेएस है जहां कक्षाएं आपके इच्छित तरीके से व्यवहार करती हैं?

डेकोरेटर अब स्टेज 2 हैं, और लगभग हर JS फ्रेमवर्क में उपयोग किए जाते हैं।

जहां तक @connect का सवाल है, तो प्रतिक्रिया-रेडक्स प्रति माह लगभग 2.5 मिलियन डाउनलोड पर बैठा है; यह सुनना अविश्वसनीय रूप से अभिमानी है कि डिजाइन किसी तरह "गलत" है क्योंकि आपने इसे अलग तरह से लागू किया होगा।

डेकोरेटर द्वारा शुरू की गई विधियों का उपयोग करने के वर्तमान प्रयासों के परिणामस्वरूप टाइपस्क्रिप्ट में टाइप त्रुटियां होती हैं, इंटरफ़ेस मर्जिंग जैसे वर्कअराउंड की आवश्यकता होती है, मैन्युअल रूप से जोड़े गए तरीकों के लिए एनोटेशन जोड़ना, या कक्षाओं को म्यूट करने के लिए डेकोरेटर्स का उपयोग नहीं करना (जैसे कि किसी को भी बताया जाना चाहिए कि हम बस कर सकते हैं सज्जाकार का उपयोग न करें)।

क्या वास्तव में, वास्तव में मैन्युअल रूप से, श्रमसाध्य रूप से टीएस कंपाइलर को सूचित करने का कोई तरीका नहीं है कि एक डेकोरेटर कक्षाओं के आकार को बदल रहा है? शायद यह पागल है, लेकिन टीएस सिर्फ एक नया डेकोरेटर नहीं भेज सकाटाइप करें जिसका हम उपयोग कर सकते हैं

चलो सी: डेकोरेटर

और IF (और केवल अगर) उस प्रकार के सज्जाकार एक वर्ग पर लागू होते हैं, तो TS उस वर्ग को इनपुट और {blah() } प्रकार का मानेगा?

वस्तुतः हर कोई जानता है कि हम सज्जाकारों का उपयोग नहीं कर सकते। अधिकांश यह भी जानते हैं कि एक मुखर समूह सज्जाकारों को नापसंद करता है। यह पोस्ट इस बारे में है कि टीएस संभवतः कैसे हो सकता है, किसी तरह यह समझने के लिए कि एक डेकोरेटर एक वर्ग परिभाषा को बदल रहा है। यह बहुत से लोगों के लिए एक बड़ा वरदान होगा।

सटीक होने के लिए: क्या कोई एनोटेशन नहीं है टाइपस्क्रिप्ट हमें उपरोक्त आपके उदाहरण से ए, बी, और सी में जोड़ने के लिए कह सकता है ताकि टाइप सिस्टम पूर्व को बाद वाले से अलग-अलग व्यवहार कर सके?

हां, 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)))) कर सकते हैं।

डेकोरेटर द्वारा शुरू की गई विधियों का उपयोग करने के वर्तमान प्रयासों के परिणामस्वरूप टाइपस्क्रिप्ट में टाइप त्रुटियां होती हैं, इंटरफ़ेस मर्जिंग जैसे वर्कअराउंड की आवश्यकता होती है, मैन्युअल रूप से जोड़े गए तरीकों के लिए एनोटेशन जोड़ना, या कक्षाओं को म्यूट करने के लिए डेकोरेटर्स का उपयोग नहीं करना (जैसे कि किसी को भी बताया जाना चाहिए कि हम बस कर सकते हैं सज्जाकार का उपयोग न करें)।

आपने उस वर्ग को सजाने के विकल्प का उल्लेख नहीं किया है जिसे आप लिख रहे हैं जब यह डेकोरेटर द्वारा पेश किए गए सदस्यों के लिए अज्ञेयवादी है, और जब यह नहीं है तो इसे एक सजाया हुआ वर्ग का विस्तार करना है। इस प्रकार मैं कम से कम सज्जाकारों का उपयोग करूंगा।

क्या आप मुझे उस पुस्तकालय से एक कोड स्निपेट दे सकते हैं जिसका आप अभी उपयोग कर रहे हैं जहां यह एक दर्द बिंदु है?

क्षमा करें - मैंने आपकी पिछली टिप्पणी का पालन नहीं किया, लेकिन इससे पहले की आपकी टिप्पणी, इंटरफ़ेस विलय के साथ, ठीक इसी तरह से मैं इसके आसपास काम कर रहा हूं।

वर्तमान में मेरे डेकोरेटर को एक प्रकार का निर्यात करने की भी आवश्यकता है, और मैं इंटरफ़ेस मर्जिंग का उपयोग ठीक वैसे ही करता हूं जैसा आपने दिखाया था, टीएस को यह इंगित करने के लिए कि डेकोरेटर द्वारा नए सदस्य जोड़े जा रहे हैं। यह इस अतिरिक्त बॉयलरप्लेट को खोदने की क्षमता है जिसके लिए बहुत से लोग उत्सुक हैं।

@arackaf शायद आप वास्तव में जो चाहते हैं वह फ़ंक्शन तर्कों के प्रासंगिक टाइपिंग के साथ बातचीत करने के लिए विलय की घोषणा का एक तरीका है।

ज़रूर। मैं एक वर्ग पर एक सजावटी का उपयोग करने की क्षमता चाहता हूं, और अवधारणात्मक रूप से, मैंने सजावटी को परिभाषित करने के तरीके के आधार पर, कुछ इंटरफ़ेस विलय करने के लिए, जिसके परिणामस्वरूप मेरी सजाए गए वर्ग में अतिरिक्त सदस्य जोड़े गए हैं।

मुझे नहीं पता कि ऐसा होने के लिए मैं अपने सजावटी को एनोटेट करने के बारे में कैसे जाउंगा, लेकिन मैं वास्तव में पसंद नहीं कर रहा हूं - भविष्य के टीएस संस्करण ने मुझे प्रभावित करने के लिए किसी भी वाक्यविन्यास ने मुझे अविश्वसनीय रूप से खुश कर दिया :)

डेकोरेटर अब स्टेज 2 हैं, और लगभग हर JS फ्रेमवर्क में उपयोग किए जाते हैं।

और वे अभी स्टेज 2 पर हैं और बेहद धीमी गति से आगे बढ़ रहे हैं। मैं बुरी तरह से चाहता हूं कि सज्जाकार हों, और मैं यह पता लगाने की कोशिश कर रहा हूं कि मैं उन्हें कैसे आगे बढ़ने में मदद कर सकता हूं, लेकिन वे अभी भी निश्चित नहीं हैं। मैं अब भी ऐसे लोगों के बारे में जानता हूं जो इस प्रक्रिया पर प्रभाव डाल सकते हैं जो उन पर आपत्ति जताते हैं, या चाहते हैं कि वे एनोटेशन तक ही सीमित रहें, हालांकि मुझे नहीं लगता कि वे हस्तक्षेप करेंगे। वर्तमान कंपाइलर डेकोरेटर कार्यान्वयन के बारे में मेरी बात जेएस स्टैंड नहीं है।

जहां तक @connect React -redux की बात है, प्रति माह लगभग 2.5 मिलियन डाउनलोड हो रहे हैं; यह सुनना अविश्वसनीय रूप से अभिमानी है कि डिजाइन किसी तरह "गलत" है क्योंकि आपने इसे अलग तरह से लागू किया होगा।

कृपया मुझे अहंकारी कहने जैसे व्यक्तिगत हमलों से बचना चाहिए।

1. मैंने व्यक्तिगत रूप से आप पर हमला नहीं किया, इसलिए व्यक्तिगत रूप से मुझ पर हमला न करें।
2. यह आपके तर्क में बिल्कुल भी मदद नहीं करता है।
3. किसी परियोजना की लोकप्रियता को उसे तकनीकी आलोचना से अलग नहीं करना चाहिए।
4. क्या हम उसी के बारे में बात कर रहे हैं? रेडक्स-कनेक्ट-डेकोरेटर के एक दिन में 4 डाउनलोड होते हैं। प्रतिक्रिया-रेडक्स का connect() फ़ंक्शन एक एचओसी जैसा दिखता है, जैसा मैंने सुझाव दिया था।
5. मुझे लगता है कि मेरी राय है कि अच्छी तरह से व्यवहार करने वाले सज्जाकारों को एक वर्ग के सार्वजनिक आकार को नहीं बदलना चाहिए, और निश्चित रूप से इसे एक असंबंधित वर्ग के साथ बदलना चाहिए, काफी उचित है, और जेएस समुदाय के आसपास पर्याप्त समझौता होगा। यह अभिमानी से बहुत दूर है, भले ही आप असहमत हों।

डेकोरेटर द्वारा शुरू की गई विधियों का उपयोग करने के वर्तमान प्रयासों के परिणामस्वरूप टाइपस्क्रिप्ट में टाइप त्रुटियां होती हैं, इंटरफ़ेस मर्जिंग जैसे वर्कअराउंड की आवश्यकता होती है, मैन्युअल रूप से जोड़े गए तरीकों के लिए एनोटेशन जोड़ना, या कक्षाओं को म्यूट करने के लिए डेकोरेटर्स का उपयोग नहीं करना (जैसे कि किसी को भी बताया जाना चाहिए कि हम बस कर सकते हैं सज्जाकार का उपयोग न करें)।

ऐसा नहीं है कि हम सिर्फ डेकोरेटर्स का उपयोग न करने का सुझाव दे रहे हैं, मेरा मानना ​​है कि @masaeedu कह रहे हैं कि एक प्रोटोटाइप को टाइप-सेफ तरीके से संशोधित करने के उद्देश्य से, हमारे पास मौजूदा तंत्र हैं: इनहेरिटेंस और मिक्सिन एप्लिकेशन। मैं यह पूछने की कोशिश कर रहा था कि आपका d उदाहरण मिक्सिन के रूप में उपयोग करने के लिए उपयुक्त क्यों नहीं था, और आपने यह कहने के अलावा कोई जवाब नहीं दिया कि आप सिर्फ डेकोरेटर का उपयोग करना चाहते हैं।

मुझे लगता है कि यह ठीक है, लेकिन ऐसा लगता है कि बातचीत को काफी गंभीर रूप से सीमित कर दिया गया है, इसलिए मैं फिर से झुकूंगा।

@justinfagnani मैं बात कर रहा था

import {connect} from 'react-redux'

connect केवल एक फ़ंक्शन है जो एक वर्ग (घटक) में लेता है और एक अलग थूकता है, जैसा कि आपने ऊपर कहा था।

वर्तमान में, बैबेल और टाइपस्क्रिप्ट दोनों में मेरे पास इस तरह 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.

मैंने स्पष्ट रूप से आपके प्रश्न का उत्तर केवल इसलिए नहीं दिया क्योंकि मुझे लगा कि मैं डेकोरेटर्स का उपयोग करने का कारण स्पष्ट था, लेकिन मैं इसे स्पष्ट रूप से बताऊंगा: मैं एर्गोनॉमिक्स और सिंटैक्स डेकोरेटर प्रदान करना पसंद करता हूं। यह पूरा, पूरा धागा टीएस को यह बताने की कुछ क्षमता प्राप्त करने की कोशिश करने के बारे में है कि हमारे सजावटी वर्ग को प्रश्न में कैसे बदल रहे हैं, इसलिए हमें इंटरफ़ेस विलय जैसे बॉयलरप्लेट की आवश्यकता नहीं है।

जैसा कि ओपी ने कहा था कि जब, हम बस चाहते हैं

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'

सिर्फ काम करने के लिए। तथ्य यह है कि इस विशिष्ट वाक्य रचना के लिए अन्य विकल्प मौजूद हैं, दोनों स्पष्ट और सारहीन हैं। तथ्य यह है कि जेएस/टीएस समुदाय में कई लोग इस विशेष वाक्य रचना को नापसंद करते हैं, यह भी स्पष्ट और सारहीन है।

अगर टीएस हमें इस वाक्य रचना को काम करने के लिए कोई रास्ता दे सकता है, हालांकि प्रतिबंधित है, तो यह भाषा और समुदाय के लिए एक बड़ा लाभ होगा।

@arackaf आपने यह उल्लेख करने की उपेक्षा की कि कैसे connect का उपयोग करने से $# this पर अतिरिक्त सदस्यों तक पहुंचने की आवश्यकता होती है। AFAICT, आपका घटक कार्यान्वयन पूरी तरह से अज्ञेयवादी होना चाहिए जो connect करता है, यह केवल अपने props और state का उपयोग करता है। तो उस अर्थ में जिस तरह से connect को डिज़ाइन किया गया है वह @justinfagnani के डेकोरेटर्स के उपयोग से अधिक सहमत है।

ज़रूरी नहीं। विचार करना

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

फिर बाद में

<Foo />

यह मान्य होना चाहिए - प्रॉप्सशैप प्रॉप्स Redux स्टोर से आ रहे हैं, लेकिन टाइपस्क्रिप्ट को यह पता नहीं है, क्योंकि यह फू की मूल परिभाषा से दूर जा रहा है, इसलिए मुझे लापता प्रॉप्स के लिए त्रुटियां मिल रही हैं, और इसे any के रूप में डालने की आवश्यकता है

लेकिन स्पष्ट होने के लिए, मूल रूप से ओपी द्वारा दिए गए सटीक उपयोग का मामला, और यहां ऊपर मेरी दूसरी टिप्पणी में डुप्लिकेट किया गया है, हमारे कोड बेस में बेहद आम है, और इसके दिखने से, कई अन्य भी। हम शाब्दिक रूप से चीजों का उपयोग करते हैं:

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

और टाइपस्क्रिप्ट को संतुष्ट करने के लिए कुछ इंटरफ़ेस विलय जोड़ना होगा। उस इंटरफ़ेस को डेकोरेटर परिभाषा में पारदर्शी रूप से विलय करने का एक तरीका होना अद्भुत होगा।

हम इसके साथ मंडलियों में जाते रहते हैं। हम सहमत हैं कि Foo का प्रकार connect का रिटर्न प्रकार होना चाहिए। हम इस पर पूरी तरह सहमत हैं।

जहां हम भिन्न हैं, क्या Foo के अंदर के सदस्यों को यह दिखावा करने की आवश्यकता है कि this डेकोरेटर रिटर्न प्रकार और "मूल फू" का किसी प्रकार का पुनरावर्ती समामेलन है, जिसका अर्थ है। आपने इसके लिए उपयोग के मामले का प्रदर्शन नहीं किया है।

जहां हम भिन्न हैं, क्या फू के अंदर के सदस्यों को यह दिखावा करने की आवश्यकता है कि यह डेकोरेटर रिटर्न प्रकार और "मूल फू" का किसी प्रकार का पुनरावर्ती समामेलन है, जिसका अर्थ है। आपने इसके लिए उपयोग के मामले का प्रदर्शन नहीं किया है।

मेरे पास है। ऊपर मेरी टिप्पणी देखें, और उस मामले के लिए ओपी का मूल कोड। यह एक अत्यंत सामान्य उपयोग का मामला है।

कृपया मुझे दिखाएं कि connect प्रोटोटाइप में क्या जोड़ता है कि यह आपसे घटक के अंदर पहुंचने की अपेक्षा करता है। यदि उत्तर "कुछ नहीं" है, तो कृपया connect फिर से न लाएं, क्योंकि यह पूरी तरह से अप्रासंगिक है।

@masaeedu काफी मेला, और मैं सहमत हूं। मैं ज्यादातर @justinfagnani के दावे का जवाब दे रहा था कि कैसे सज्जाकारों को मूल वर्ग को संशोधित नहीं करना चाहिए, connect को खराब तरीके से डिजाइन किया गया था, आदि आदि।

मैं केवल सिंटैक्स I का प्रदर्शन कर रहा था और कई अन्य लोग पसंद करते हैं, इस तथ्य के बावजूद कि अन्य विकल्प मौजूद हैं।

इस मामले के लिए, हाँ, मुझे लोकप्रिय एनपीएम पुस्तकालयों के बारे में पता नहीं है जो कक्षा लेते हैं, और नई विधियों के साथ एक नई कक्षा को वापस थूकते हैं, जिसका उपयोग सजाए गए वर्ग के अंदर किया जाएगा। यह ऐसा कुछ है जो मैं और अन्य अक्सर अपने स्वयं के मिश्रणों को लागू करने के लिए अपने कोड में करते हैं, लेकिन मेरे पास वास्तव में एनपीएम पर कोई उदाहरण नहीं है।

लेकिन यह वास्तव में विवाद में नहीं है कि यह एक सामान्य उपयोग का मामला है, है ना?

@arackaf नहीं, ऐसा इसलिए नहीं है क्योंकि आप this पर किसी भी सदस्य तक नहीं पहुंच रहे हैं जो @connect द्वारा पेश किए गए हैं। वास्तव में मुझे पूरा यकीन है कि यह सटीक स्निपेट:

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

आज टाइपस्क्रिप्ट में बिना किसी समस्या के संकलन करेगा। आपके द्वारा चिपकाए गए स्निपेट का उस सुविधा से कोई लेना-देना नहीं है जिसका आप अनुरोध कर रहे हैं।

@masaeedu - क्षमा करें - मुझे एहसास हुआ कि मैं गलत था और उस टिप्पणी को हटा दिया। हालांकि आपको अपना समय बर्बाद करने से रोकने के लिए पर्याप्त तेज़ नहीं है :(

@arackaf मुझे नहीं पता कि यह कितना सामान्य पैटर्न है, और मैंने व्यक्तिगत रूप से इसे न तो स्वयं उपयोग किया है और न ही इसका उपयोग करने वाले किसी भी पुस्तकालय का उपयोग किया है। मैंने थोड़ी देर के लिए एंगुलर 2 का इस्तेमाल किया, इसलिए ऐसा नहीं है कि मैंने अपने जीवन में कभी भी डेकोरेटर्स का इस्तेमाल नहीं किया है। यही कारण है कि मैं एक पुस्तकालय का उपयोग करने के विशिष्ट उदाहरण मांग रहा था जहां डेकोरेटर में डेकोरेटर द्वारा पेश किए गए सदस्यों तक पहुंचने में असमर्थता एक दर्द बिंदु है।

प्रत्येक मामले में जहां एक वर्ग के सदस्य this से कुछ की अपेक्षा करते हैं, कक्षा के शरीर में या कक्षा के extends खंड में कुछ ऐसा होना चाहिए जो आवश्यकता को पूरा करता हो। सज्जाकारों के साथ भी इसने हमेशा काम किया है। यदि आपके पास एक डेकोरेटर है जो कुछ कार्यक्षमता जोड़ता है जो एक वर्ग पर निर्भर करता है, तो कक्षा को जो कुछ भी डेकोरेटर लौटाता है, उसका विस्तार करना चाहिए, न कि दूसरी तरफ। यह सिर्फ सामान्य ज्ञान है।

मुझे यकीन नहीं है कि यह सामान्य ज्ञान क्यों है। यह वर्तमान में हमारे कोड बेस से कोड है। हमारे पास एक डेकोरेटर है जो एक वर्ग के प्रोटोटाइप में एक विधि जोड़ता है। टाइपस्क्रिप्ट त्रुटियाँ बाहर। उस समय मैंने इस घोषणा को वहीं पर फेंक दिया था। मैं इंटरफ़ेस विलय का उपयोग कर सकता था।

लेकिन अच्छा होगा कि कुछ भी इस्तेमाल न करें। टाइपस्क्रिप्ट को यह बताने में सक्षम होना वास्तव में अच्छा होगा कि "यह डेकोरेटर यहां इस विधि को किसी भी वर्ग में लागू करता है - कक्षा के अंदर this को भी इसे एक्सेस करने की अनुमति दें"

इस धागे में कई अन्य लोग समान रूप से डेकोरेटर का उपयोग करते प्रतीत होते हैं, इसलिए मुझे आशा है कि आप इस पर विचार करेंगे कि यह सामान्य ज्ञान नहीं हो सकता है कि यह काम नहीं करना चाहिए।

@arackaf हाँ, तो आपको export class SearchVm extends (@mappable({...}) class extends SearchVmBase {}) करना चाहिए। यह SearchVm है जो मैपेबिलिटी पर निर्भर करता है, न कि दूसरी तरफ।

निर्यात वर्ग SearchVm बढ़ाता है (@mappable({...}) वर्ग SearchVmBase {} बढ़ाता है)

इस धागे का पूरा बिंदु इस तरह बॉयलरप्लेट से बचना है। सज्जाकार इस तरह के काम करने की तुलना में बहुत अधिक, अधिक अच्छे डीएक्स प्रदान करते हैं। इसके बजाय हमारे पास कोड लिखने का एक कारण है, जैसा कि मेरे पास है।

यदि आप इस धागे की टिप्पणियों के माध्यम से पढ़ते हैं, तो मुझे आशा है कि आप आश्वस्त होंगे कि कई अन्य लोग सरल डेकोरेटर सिंटैक्स का उपयोग करने की कोशिश कर रहे हैं, और इसलिए पुनर्विचार करें कि हमें क्या करना चाहिए, या "सामान्य ज्ञान" क्या है।

आप जो चाहते हैं उसका विशेष रूप से सज्जाकारों से कोई लेना-देना नहीं है। आपकी समस्या यह है कि टाइपस्क्रिप्ट का तंत्र "हे टाइपस्क्रिप्ट, इस संरचना में सामान हो रहा है जिसके बारे में आप कुछ भी नहीं जानते हैं, मैं आपको इसके बारे में सब कुछ बता दूं", वर्तमान में बहुत सीमित है। अभी हमारे पास केवल इंटरफ़ेस मर्जिंग है, लेकिन आप चाहते हैं कि फ़ंक्शंस इंटरफ़ेस मर्जिंग को उनके तर्कों पर लागू करने में सक्षम हों, जो कि किसी भी तरह से डेकोरेटर से विशेष रूप से संबंधित नहीं है।

अभी हमारे पास केवल इंटरफ़ेस मर्जिंग है, लेकिन आप चाहते हैं कि फ़ंक्शंस इंटरफ़ेस मर्जिंग को उनके तर्कों पर लागू करने में सक्षम हों, जो कि किसी भी तरह से डेकोरेटर से विशेष रूप से संबंधित नहीं है।

ठीक। काफी उचित। क्या आप चाहते हैं कि मैं एक अलग मुद्दा खोलूं, या आप इसका नाम बदलना चाहते हैं, आदि?

@arackaf एकमात्र "बॉयलरप्लेट" यह तथ्य है कि मेरे पास class { } था, जो कि a) एक निश्चित 7 वर्ण हैं, चाहे आप कितने सज्जाकार का उपयोग करें b) इस तथ्य का परिणाम है कि सज्जाकार नहीं कर सकते (अभी तक ) मनमाने ढंग से वर्ग-वापसी अभिव्यक्तियों पर लागू हो, और सी) क्योंकि मैं विशेष रूप से आपके लाभ के लिए सजावटी का उपयोग करना चाहता था। यह वैकल्पिक सूत्रीकरण:

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

मूल रूप से आप जो कर रहे हैं उससे अधिक क्रियात्मक नहीं है।

ठीक। काफी उचित। क्या आप चाहते हैं कि मैं एक अलग मुद्दा खोलूं, या आप इसका नाम बदलना चाहते हैं, आदि?

अलग मुद्दा अच्छा रहेगा।

आप मूल रूप से जो कर रहे हैं उससे अधिक क्रियात्मक नहीं है

यह अब क्रियात्मक नहीं है, लेकिन मैं वास्तव में आशा करता हूं कि आप इस तथ्य पर विचार करेंगे कि बहुत से लोग उस वाक्य-विन्यास को नापसंद करते हैं। बेहतर या बदतर के लिए, कई डीएक्स डेकोरेटर्स की पेशकश को पसंद करते हैं।

अलग मुद्दा अच्छा रहेगा।

मैं कल एक टाइप करूंगा, और संदर्भ के लिए इस से लिंक करूंगा।

इसके माध्यम से काम करने में मदद करने के लिए धन्यवाद :)

अगर मैं अंदर जा सकता हूं, @masaeedu मैं इस कथन से असहमत हूं:

आप जो चाहते हैं उसका विशेष रूप से सज्जाकारों से कोई लेना-देना नहीं है। आपकी समस्या यह है कि टाइपस्क्रिप्ट का तंत्र "हे टाइपस्क्रिप्ट, इस संरचना में सामान हो रहा है जिसके बारे में आप कुछ भी नहीं जानते हैं, मैं आपको इसके बारे में सब कुछ बता दूं", वर्तमान में बहुत सीमित है। अभी हमारे पास केवल इंटरफ़ेस मर्जिंग है, लेकिन आप चाहते हैं कि फ़ंक्शंस इंटरफ़ेस मर्जिंग को उनके तर्कों पर लागू करने में सक्षम हों, जो कि किसी भी तरह से डेकोरेटर से विशेष रूप से संबंधित नहीं है।

निश्चित रूप से टाइपस्क्रिप्ट क्लास डेकोरेटर के रिटर्न प्रकार को देख सकता है कि उत्परिवर्तित वर्ग किस प्रकार का होना चाहिए। "तर्कों में विलय इंटरफ़ेस लागू करने" की कोई आवश्यकता नहीं है। तो जैसा कि मैं इसे देखता हूं, यह पूरी तरह से सज्जाकारों के साथ करना है।

इसके अलावा, टाइपस्क्रिप्ट के मामले में यह नहीं जानना कि एक कनेक्टेड घटक को अब प्रॉप्स की आवश्यकता नहीं है, एक पहलू है जिसने मुझे रिएक्ट और टाइपस्क्रिप्ट के साथ 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 का रिटर्न प्रकार होना चाहिए। मैं इस बात से सहमत नहीं हूं कि this के अंदर Foo किसी भी तरह से प्रभावित होना चाहिए। connect का उपयोग यहां विवाद के बिंदु के लिए पूरी तरह से अप्रासंगिक है, क्योंकि connect सजाए गए घटक के बारे में जागरूक होने और उन सदस्यों का उपयोग करने की अपेक्षा नहीं करता है जो इसे प्रोटोटाइप में जोड़ रहे हैं।

मैं समझ सकता हूं कि आप निराश हैं @masaeedu लेकिन यह मत मानिए कि मैं सक्रिय रूप से इस पर अपनी राय नहीं दे रहा हूं और आप पिछले 48 घंटों से कर रहे हैं कि मैं चर्चा का पालन नहीं कर रहा हूं - तो कृपया कृपालु साथी मुझे बख्श दो।

जैसा कि मैं इसे समझता हूं, आपको लगता है कि एक सजाए गए वर्ग के अंदर इसे सजावटी द्वारा किए गए किसी भी उत्परिवर्तन के बारे में नहीं पता होना चाहिए, लेकिन इसके बाहर होना चाहिए। मैं इससे असहमत नहीं हूं। तथ्य यह है कि @arackaf एक वर्ग के अंदर सोचता है कि उत्परिवर्तित संस्करण देखना चाहिए मेरी टिप्पणी के बिंदु के अलावा है।

किसी भी तरह से, टाइपस्क्रिप्ट एक डेकोरेटर फ़ंक्शन द्वारा लौटाए गए प्रकार का उपयोग एक वर्ग के लिए सत्य के स्रोत के रूप में कर सकता है। और इसलिए यह एक डेकोरेटर मुद्दा है, न कि कुछ नए विचित्र तर्क उत्परिवर्तन कार्यक्षमता जैसा कि आप सुझाव देते हैं, जो ईमानदारी से सिर्फ एक स्ट्रॉ-मैन के प्रयास की तरह लगता है।

@Zalastax जो डेकोरेटर फ़ंक्शन का उपयोग फ़ंक्शन के रूप में कर रहा है, हालांकि डेकोरेटर के रूप में नहीं। यदि आपके पास कई सज्जाकार हैं, तो आपको उन्हें लागू करने की आवश्यकता है, आपको उन्हें घोंसला बनाने की आवश्यकता है, जो तकनीकी रूप से अब वर्बोज़ नहीं है, लेकिन वाक्य रचनात्मक रूप से सुखद नहीं है - क्या आप जानते हैं कि मेरा क्या मतलब है?

कृपालुता आदि

शोर।

तथ्य यह है कि @arackaf एक वर्ग के अंदर सोचता है कि उत्परिवर्तित संस्करण देखना चाहिए मेरी टिप्पणी के बिंदु के अलावा है।

यह उस पैराग्राफ का केंद्रीय बिंदु है जिसका आप जवाब दे रहे हैं, इसलिए यदि आप किसी और चीज के बारे में बात कर रहे हैं तो यह अप्रासंगिक है। @arackaf क्या चाहता है, मोटे तौर पर, इंटरफ़ेस फ़ंक्शन तर्कों पर विलय कर रहा है। यह सज्जाकारों से स्वतंत्र एक विशेषता द्वारा बेहतर ढंग से संबोधित किया जाता है। आप जो चाहते हैं (जो स्पष्ट रूप से मैं जो चाहता हूं उसके समान है) टाइपस्क्रिप्ट में बग को ठीक करना है जहां <strong i="12">@foo</strong> class Foo { } के परिणामस्वरूप Foo के लिए const Foo = foo(class { }) के समान प्रकार के हस्ताक्षर नहीं होते हैं

जैसा कि मैं इसे समझता हूं, आपको लगता है कि एक सजाए गए वर्ग के अंदर इसे सजावटी द्वारा किए गए किसी भी उत्परिवर्तन के बारे में नहीं पता होना चाहिए, लेकिन इसके बाहर होना चाहिए। मैं इससे असहमत नहीं हूं

यदि आपने किसी ऐसी बात के बारे में बात करने का फैसला किया है जिस पर हम सहमत हैं, लेकिन इसे "मैं इस कथन से असहमत हूं" के साथ पेश करता हूं, तो आप बस समय बर्बाद कर रहे हैं।

क्या मुझे इस नमक के साथ कुछ फ्राई मिल सकते हैं?

ओह, मैं देखता हूं, जब आप अपने साथियों को संरक्षण देते हैं तो यह ठीक है लेकिन अगर लोग आपको इस पर खींचते हैं, तो यह शोर है।

मैं नहीं देखता कि @arackaf ने जो प्रस्तावित किया है उसे लागू करने के लिए आपकी "तर्क उत्परिवर्तन" अवधारणा की आवश्यकता क्यों है।

भले ही हम @arackaf से सहमत हों या नहीं, मेरी विनम्र राय में, किसी भी तरह से टाइपस्क्रिप्ट केवल डेकोरेटर परिणाम से वास्तविक प्रकार का अनुमान लगा सकता है।

क्षमा करें यदि आप के लिए कृपालु महसूस किया; इरादा आपको पाने का था
वास्तव में एक विशाल जुझारू धागा जिसके लिए किसी को भी माफ किया जा सकता है
स्किमिंग मैं इस पर कायम हूं, क्योंकि यह अभी भी बहुत स्पष्ट है कि आप जागरूक नहीं हैं
विवरण के बारे में और मेरे साथ "असहमत" की गलतफहमी के आधार पर हैं
मेरा स्थान।

उदाहरण के लिए, आपका प्रश्न क्यों इंटरफ़ेस फ़ंक्शन पर विलय कर रहा है
तर्क हल करते हैं एडम की समस्या का सबसे अच्छा उत्तर प्रासंगिक को देखकर दिया जाता है
एडम के साथ चर्चा, जहां वह कहता है कि वह पहले से ही इंटरफेस विलय का उपयोग कर रहा है,
लेकिन प्रत्येक घोषणा स्थल पर ऐसा करना कष्टप्रद लगता है।

मुझे लगता है कि इसके सभी तकनीकी पहलुओं को पीट-पीट कर मार डाला गया है। मैं
मैं नहीं चाहता कि धागे पर आपसी झगड़ों का बोलबाला हो, इसलिए यह
मेरी आखिरी पोस्ट होने जा रही है।

यह सच है, सज्जाकारों के साथ दो बग हैं: रिटर्न प्रकार का सम्मान नहीं किया जाता है, और कक्षा के लिए आंतरिक, जोड़े गए सदस्यों का सम्मान नहीं किया जाता है ( this कक्षा के अंदर)। और हां, मैं बाद वाले से अधिक चिंतित हूं, क्योंकि पूर्व को अधिक आसानी से काम किया जाता है।

मैंने यहां एक अलग मामला खोला है: https://github.com/Microsoft/TypeScript/issues/16599

हे सब लोग, मैं इस बातचीत को सप्ताहांत में चूक गया, और शायद अब इसे वापस लाने का कोई कारण नहीं है; लेकिन मैं सभी को याद दिलाना चाहता हूं कि इस तरह की चर्चाओं की गर्मी में, आम तौर पर वजन करने वाला हर व्यक्ति नेक इरादे वाला होता है। एक सम्मानजनक स्वर रखने से बातचीत को स्पष्ट करने और चलाने में मदद मिल सकती है, और नए योगदानकर्ताओं को बढ़ावा मिल सकता है। ऐसा करना हमेशा आसान नहीं होता है (खासकर जब इंटरनेट पाठक पर निर्भर करता है), लेकिन मुझे लगता है कि यह भविष्य के परिदृश्यों के लिए महत्वपूर्ण है। मैं

इस पर क्या स्थिति है?

@ alex94puchades यह अभी भी एक चरण 2 का प्रस्ताव है, इसलिए हमें शायद अभी भी कुछ समय मिल गया है। ऐसा लगता है कि TC39 में कम से कम इस पर कुछ हलचल है ।

इस टिप्पणी के अनुसार, ऐसा लगता है कि इसे चरण 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

/गुनगुनाहट

अगर कोई इसका हल ढूंढ रहा है, तो मैं नीचे आया एक कामकाज है।

यह सबसे अच्छा समाधान नहीं है क्योंकि इसके लिए एक नेस्टेड ऑब्जेक्ट की आवश्यकता होती है, लेकिन मेरे लिए यह अच्छी तरह से काम करता है क्योंकि मैं वास्तव में चाहता था कि डेकोरेटर के गुण किसी ऑब्जेक्ट में हों, न कि केवल क्लास इंस्टेंस पर फ्लैट।

यह कुछ ऐसा है जो मैं अपने कोणीय 5 मोडल के लिए उपयोग कर रहा हूं।

मान लीजिए मेरे पास एक @ModalParams(...) डेकोरेटर है जिसे मैं कस्टम ConfirmModalComponent पर उपयोग कर सकता हूं। मेरे कस्टम घटक के भीतर @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();
    }
}

: / हाँ, लेकिन फिर प्रकार सजावटी से अलग हो गया है और आप निश्चित रूप से उनमें से दो का उपयोग नहीं कर सकते हैं ..:( इसके अलावा यदि वर्ग विधियों को लागू नहीं करेगा तो आपको त्रुटियां मिलेंगी .. :( मुझे नहीं लगता कि वहां इस समय इस पैटर्न के साथ सही प्रकार प्राप्त करने का एक तरीका है

हाँ, यह बहुत अच्छा होगा यदि यह संभव हो, टाइपस्क्रिप्ट को इतना बेहतर और अभिव्यंजक बनाता है। उम्मीद है कि जल्द ही इसमें से कुछ निकलेगा।

@lansana हाँ, मुद्दा यह है कि क्लास डेकोरेटर्स के लिए यह अच्छा होगा कि वे क्लास के हस्ताक्षर को अपने दम पर बदलने में सक्षम हों, बिना क्लास को कुछ और बढ़ाने या लागू करने की आवश्यकता के बिना (क्योंकि यह प्रयास और प्रकार की जानकारी का दोहराव है) .

साइड नोट: अपने उदाहरण में, ध्यान रखें कि params सजाए गए मोडल घटक वर्गों के सभी उदाहरणों में स्थिर होगा, क्योंकि यह एक ऑब्जेक्ट संदर्भ है। हालांकि शायद यह डिजाइन द्वारा है। : - ) लेकिन मैं पीछे हटा...

संपादित करें: जैसा कि मैं इस बारे में सोचता हूं, मैं कक्षा हस्ताक्षरों को संशोधित करने के लिए सज्जाकारों को सक्षम करने के विपक्ष को देख सकता हूं। यदि वर्ग कार्यान्वयन में स्पष्ट रूप से कुछ प्रकार के एनोटेशन हैं, लेकिन एक डेकोरेटर झपट्टा मारने और उन सभी को बदलने में सक्षम है, तो यह डेवलपर्स पर खेलने के लिए एक औसत चाल होगी। बहुत सारे उपयोग के मामले स्पष्ट रूप से नए वर्ग तर्क को शामिल करने से संबंधित हैं, इसलिए दुर्भाग्य से उनमें से कई को विस्तार या इंटरफ़ेस कार्यान्वयन के माध्यम से बेहतर सुविधा दी जाएगी - जो मौजूदा वर्ग हस्ताक्षर के साथ समन्वय करता है और जहां टकराव होता है वहां उचित त्रुटियां होती हैं। निश्चित रूप से कोणीय जैसा ढांचा कक्षाओं को बढ़ाने के लिए सज्जाकारों का प्रचुर उपयोग करता है, लेकिन डिजाइन वर्ग को "लाभ" या डेकोरेटर से नए तर्क में मिश्रण करने की अनुमति नहीं देता है जिसे वह अपने स्वयं के कार्यान्वयन में उपयोग कर सकता है - इसे अलग करना है फ्रेमवर्क समन्वय तर्क से वर्ग तर्क। वैसे भी यह मेरी _विनम्र_राय है। :- )

डेकोरेटर्स + हैक्स के बजाय केवल उच्च क्रम की कक्षाओं का उपयोग करना बेहतर लगता है। मुझे पता है कि लोग इस सामान के लिए डेकोरेटर का उपयोग करना चाहते हैं, लेकिन कंपोज़ + एचओसी का उपयोग करने का रास्ता है और यह शायद इस तरह रहेगा ... हमेशा के लिए;) एमएस आदि के अनुसार डेकोरेटर केवल कक्षाओं में मेटाडेटा संलग्न करने के लिए हैं और जब आप एंगुलर जैसे डेकोरेटर्स के बड़े उपयोगकर्ताओं की जाँच करें, आप देखेंगे कि वे केवल इस क्षमता में उपयोग किए जाते हैं। मुझे संदेह है कि आप अन्यथा टाइपस्क्रिप्ट अनुरक्षकों को समझाने में सक्षम होंगे।

यह दुखद और थोड़ा अजीब है कि इतनी शक्तिशाली विशेषता, जो वास्तविक फीचर संरचना की अनुमति देती है, और जो इस तरह की जुड़ाव उत्पन्न करती है, टीएस टीम द्वारा इतने लंबे समय से नजरअंदाज कर दिया गया है।

यह वास्तव में एक ऐसी विशेषता है जो हमारे कोड लिखने के तरीके में क्रांति ला सकती है; हर किसी को बिटली या एनपीएम जैसी चीजों पर छोटे मिश्रण जारी करने की अनुमति देता है और टाइपस्क्रिप्ट में वास्तव में भयानक कोड का पुन: उपयोग होता है। अपनी खुद की परियोजनाओं में मैं तुरंत अपना @Poolable @Initable @Translating और शायद एक ढेर और अधिक बना दूंगा।

कृपया सभी शक्तिशाली टीएस कोर टीम। लागू करने के लिए "आप सभी की जरूरत है" यह है कि लौटाए गए इंटरफेस को सम्मानित किया जाना चाहिए।

// 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 को अंतिम रूप देने के लिए प्रतीक्षा करें और फिर हम उन्हें उस रूप में प्राप्त करने की सबसे अधिक संभावना है जिस पर सभी सहमत हों।

@कुक्कीमोनसुता
मैं आपके साथ दृढ़ता से असहमत हूं क्योंकि मैं जो अनुरोध कर रहा हूं वह पूरी तरह से प्रकार के बारे में है न कि कार्यक्षमता के बारे में। इसलिए इसका ES सामान से कोई लेना-देना नहीं है। ऊपर मेरा समाधान पहले से ही काम करता है, मैं बस कास्ट नहीं करना चाहता हूं.

@AllNamesRTaken आप यह _today_ बिना किसी चेतावनी के मिक्सिन के साथ कर सकते हैं:

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 के फ़ंक्शन इंटरफ़ेस का उपयोग करने के लिए मजबूर हैं।

इस सुविधा को हल करने से दुनिया को खुशहाल जगह मिल जाएगी।

वही झगड़ा* कुछ समय पहले मटेरियल-यूआई टाइपिंग और withStyle के साथ हुआ था, जिसे एक डेकोरेटर के रूप में उपयोग करने के लिए डिज़ाइन किया गया था, लेकिन जिसे टाइप सुरक्षित तरीके से उपयोग करने के लिए टाइपस्क्रिप्ट उपयोगकर्ताओं को उपयोग करने की आवश्यकता है एक नियमित समारोह के रूप में। भले ही धूल ज्यादातर उस पर बस गई हो, लेकिन यह परियोजना में नए लोगों के लिए चल रहे भ्रम का एक स्रोत है!

*खैर, "झगड़ा" एक मजबूत शब्द हो सकता है

मैं इसे लंबे समय से देख रहा हूं, और जब तक यह नहीं आता है, तब तक अन्य लोग इस व्यवहार को आगे संगत तरीके से प्राप्त करने के लिए मेरी छोटी हैक से उम्मीद कर सकते हैं। तो यहाँ यह है, एक सुपर बेसिक स्कैला स्टाइल केस क्लास 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 विधि के साथ एक अनाम वर्ग बनाता है। यह ठीक वैसा ही काम करता है जैसा कि जावास्क्रिप्ट में अपेक्षित होता है जब एक वातावरण में सज्जाकार का समर्थन करते हैं।

टाइपस्क्रिप्ट में इसका उपयोग करने के लिए, और वास्तव में टाइप सिस्टम लक्षित वर्ग में नई विधि को दर्शाता है, निम्नलिखित हैक का उपयोग किया जा सकता है:

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

MyCaseClass के सभी उदाहरण CaseClass डेकोरेटर के अंदर अनाम वर्ग से विरासत में मिली copy पद्धति के लिए टाइपिंग को उजागर करेंगे। और, जब टाइपस्क्रिप्ट घोषित प्रकारों के उत्परिवर्तन का समर्थन करता है, तो इस कोड को बिना किसी अप्रत्याशित ब्लिप के सामान्य डेकोरेटर सिंटैक्स <strong i="18">@CaseClass</strong> etc में आसानी से संशोधित किया जा सकता है।

अगले प्रमुख टाइपस्क्रिप्ट रिलीज में इसे देखना बहुत अच्छा होगा - मेरा मानना ​​​​है कि यह प्रॉक्सी कक्षाओं की अजीब गड़बड़ी को निर्यात करने के बजाय क्लीनर और अधिक संक्षिप्त कोड में मदद करेगा।

यह सुविधा कब उपलब्ध होगी?

मैं बार-बार काम करने के लिए क्लास डेकोरेटर का इस्तेमाल करना चाहता था।
लेकिन अब कक्षा शुरू करते समय, मुझे निम्न त्रुटि मिलती है: 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 ?

मैं मटेरियल यूआई का उपयोग कर रहा हूं और बस यह महसूस करना था कि टाइपस्क्रिप्ट withStyles के लिए डेकोरेटर सिंटैक्स का समर्थन नहीं करता है: https://material-ui.com/guides/typescript/#decorating -components

कृपया अगले टाइपस्क्रिप्ट रिलीज़ में उस सीमा को ठीक करें। क्लास डेकोरेटर्स अभी मुझे बहुत बेकार लगते हैं।

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

@ जी-रथ मुझे लगता है कि इसके बजाय 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 प्रोप पास करता है।

यदि आप स्टाइल के साथ वापसी मूल्य बढ़ाते हैं तो आप A वर्ग को लागू करने के बजाय B रैपर का विस्तार कर रहे हैं जो वास्तव में classes प्रोप प्राप्त करता है।

कोई फर्क नहीं पड़ता कि आप इसे कैसे प्रारूपित करते हैं, स्टाइल्स (शैलियों) (...) के साथ फैलता है, मौलिक रूप से उचित सुझाव की तरह नहीं लगता है। withStyles एक क्लास मिक्सिन नहीं है।

वास्तव में। निश्चित नहीं है कि यहाँ इतना पुशबैक क्यों है।

उस ने कहा, मैं जो सुनता हूं, उससे सज्जाकार चरण 3 के बेहद करीब हैं, इसलिए मुझे लगता है कि टीएस को जल्द ही यहां उचित समर्थन मिलेगा।

मैं उन लोगों को सुनता हूं जो क्लीनर सिंटैक्स चाहते हैं, हालांकि, esp। सज्जाकार के रूप में कई HoCs का उपयोग करते समय। हमारे द्वारा उपयोग किया जाने वाला अस्थायी समाधान वास्तव में एक पाइप फ़ंक्शन के अंदर कई डेकोरेटर्स को लपेटना है और फिर उस शुद्ध फ़ंक्शन का उपयोग घटक को सजाने के लिए करना है। जैसे

@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
))))

एक और कारण जो मैं इसका उपयोग करता हूं, वह यह है कि डेकोरेटर स्पेक की घोषणा और उचित रूप से समर्थित होने के बाद यह पैटर्न आसानी से ढूंढ-और-प्रतिस्थापन-सक्षम/grep-सक्षम है।

@justinfagnani अजीब तरह से मुझे ESLint से सिंटैक्स त्रुटि मिलती है जब मैं extends React.Component<Props, State> को extends withStyles(styles)(React.Component<Props, State>) में बदलने का प्रयास करता हूं, इसलिए मैं उसी तरह @ जी-रथ की टाइप त्रुटि को सत्यापित नहीं कर सका।

लेकिन मैंने देखा कि अगर मैं कुछ ऐसा करता हूं तो 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.

क्या इसका मतलब यह है कि सामग्री यूआई द्वारा लौटाया गया प्रकार एक निर्माता नहीं है (हालांकि यह होना चाहिए)?

@ सागर-एसएम लेकिन, क्या आपको सामग्री यूआई प्रकार द्वारा सही प्रकार बढ़ाया गया है? ऐसा नहीं लगता कि आप करेंगे।

संदर्भ के लिए, मैंने इस पर ठोकर खाई क्योंकि मैं सामग्री UI के withStyles को एक डेकोरेटर के रूप में उपयोग करने का प्रयास कर रहा था, जो काम नहीं करता था इसलिए मैंने यह प्रश्न पूछा: https://stackoverflow.com/questions/53138167

इसकी आवश्यकता है, तो हम async फ़ंक्शन को ब्लूबर्ड के रूप में वापस कर सकते हैं

मैंने कुछ ऐसा ही करने की कोशिश की। एटीएम मैं निम्नलिखित वर्कअराउंड का उपयोग कर रहा हूं:

पहले यहाँ मेरा "मिक्सिन" डेकोरेटर है

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 प्रकार के रूप में दिखाता है लेकिन टाइपस्क्रिप्ट से जांच काम कर रही है।
यदि आप @ के बिना डेकोरेटर का उपयोग करेंगे - नोटेशन इसे केवल एक फ़ंक्शन के रूप में आमंत्रित करता है तो आपको सही चौराहे-प्रकार मिलेगा लेकिन कक्षा के अंदर ही टाइप-चेकिंग की क्षमता खो जाएगी क्योंकि आप इसका उपयोग नहीं कर सकते हैं इंटरफ़ेस चाल अब और यह और अधिक बदसूरत लग रहा है। जैसे:

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 पर कब पहुंचे? क्या वह हाल है?

उन्होंने अभी तक नहीं किया है; मेरा मानना ​​है कि वे जनवरी टीसी39 की बैठक में फिर से स्टेज 2 से स्टेज 3 तक आगे बढ़ने के लिए तैयार हैं।

आप विवरण के लिए एजेंडे पर नजर रख सकते हैं।

सही (हालांकि मैं पुष्टि नहीं कर सकता कि यह जनवरी में प्रगति के लिए तैयार है)। मैं केवल यह पूछ रहा था कि क्या स्टेज 3 वहां पहुंचने पर क्वालीफाई कर पाएगा।

मेरी राय में, डेकोरेटर प्रस्ताव में अभी भी कई गंभीर मुद्दे हैं, इसलिए यदि यह जनवरी में चरण 3 में आगे बढ़ता है, तो यह समस्यात्मक वर्ग क्षेत्रों के प्रस्ताव और वैश्विक प्रस्ताव की तरह फिर से गलती करेगा।

@hax क्या आप विस्तृत कर सकते हैं?
मैं वास्तव में यह वास्तव में चाहता हूं और इस मामले पर संचार की कमी को दुखद पाता हूं और दुर्भाग्य से समस्याओं के बारे में नहीं सुना है।

@AllNamesRTaken डेकोरेटर प्रस्ताव की जारी सूची की जाँच करें। उदाहरण के लिए, export पहले/बाद में डेकोरेटर तर्क चरण 3 का अवरोधक है।

रिडिजाइन एपीआई जैसे कुछ प्रस्तावित बदलाव भी हैं, जो मेरा मानना ​​​​है कि प्रस्ताव चरण 3 के लिए स्थिर नहीं है।

और यह समस्याग्रस्त वर्ग क्षेत्रों के प्रस्ताव से भी संबंधित है। हालांकि कक्षा के क्षेत्र चरण 3 तक पहुंच चुके हैं, फिर भी बहुत सारे मुद्दे हैं। मुझे चिंता है कि एक बड़ी समस्या यह है कि यह कई मुद्दों को सज्जाकारों (उदाहरण के लिए, संरक्षित ) पर छोड़ देता है और यह दोनों प्रस्तावों के लिए बुरा है।

ध्यान दें, मैं TC39 प्रतिनिधि नहीं हूं, और कुछ TC39 प्रतिनिधि कई मुद्दों की वर्तमान स्थिति के बारे में मेरी टिप्पणियों से कभी सहमत नहीं होते हैं। (विशेष रूप से मेरी दृढ़ राय है कि वर्तमान टीसी39 प्रक्रिया में कई विवादास्पद मुद्दों पर बड़ी विफलताएं हैं। कुछ मुद्दों को डेकोरेटर्स के लिए स्थगित करें, वास्तव में समस्या का समाधान कभी नहीं होता है, बस डेकोरेटर प्रस्ताव को और अधिक नाजुक बनाते हैं।)

मुझे लगता है कि उन चीजों का पता चल जाएगा और प्रस्ताव ठीक रहेगा, लेकिन मैं चाहूंगा कि हम यहां प्रस्ताव की स्थिति पर चर्चा न करें।

मुझे लगता है कि चरण 3 पर्याप्त आत्मविश्वास के साथ या चरण 4 शायद वह जगह है जहाँ हम नए प्रस्ताव को लागू करेंगे, और फिर हम इस मुद्दे को देख सकते हैं।

धन्यवाद डैनियल! चरण 3 आमतौर पर 4 में एक मजबूत आत्मविश्वास का अर्थ है, इसलिए जनवरी की बैठक के लिए उंगलियां पार हो गईं।

और यहां डेकोरेटर्स की चर्चा को समाप्त करने के लिए धन्यवाद। यह अजीबोगरीब है कि इस फीचर के कारण गुस्सा और बाइक शेडिंग का स्तर बढ़ गया है। मैंने ऐसा कुछ कभी नहीं देखा

सिर्फ रिकॉर्ड के लिए एक ही चीज़ के बारे में एक सुविधा अनुरोध था: https://github.com/Microsoft/TypeScript/issues/8545

जब आप जावास्क्रिप्ट (https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#better-handling-for-namespace-patterns-in) से संकलित करते हैं, तो कष्टप्रद रूप से पर्याप्त टाइपस्क्रिप्ट इस सुविधा का एक हद तक समर्थन करता है। -जेएस-फाइलें):

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

और यहां तक ​​​​कि टाइपस्क्रिप्ट कोड के लिए भी, लेकिन केवल जब फ़ंक्शंस की बात आती है (!)(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 बैठक में आगे नहीं बढ़े; वे अगली बैठक में फिर से उन्नति के लिए तैयार हो सकते हैं। हालाँकि, यह अस्पष्ट है; इस बिंदु पर प्रस्ताव के बारे में हवा में बहुत कुछ है।

यहां जो लोग रुचि रखते हैं, उन्हें अच्छी तरह से प्रस्ताव को ट्रैक करने की सलाह दी जाएगी - जो हम में से उन लोगों के लिए और साथ ही टीएस अनुरक्षकों के लिए शोर को कम करेगा।

इस पर कोई अपडेट?

वर्कअराउंड (कोणीय :)) 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

मैंने सजाए गए वर्ग गुणों को टाइप करने के लिए वर्कअराउंड बनाने में काफी समय बिताया। मुझे नहीं लगता कि यह इस धागे में परिदृश्यों के लिए एक व्यवहार्य समाधान होगा, लेकिन आपको इसके कुछ हिस्से उपयोगी लग सकते हैं। यदि आप रुचि रखते हैं, तो आप मेरी पोस्ट को माध्यम पर देख सकते हैं

इस मुद्दे पर कोई अपडेट?

हम इसके साथ कैसे कर रहे हैं?

इस मुद्दे का क्या परिणाम है, यह अब कैसे काम करता है?

आप उस प्रभाव को प्राप्त करने के लिए मिक्सिन-क्लास का उपयोग कर सकते हैं
https://mariusschulz.com/blog/mixin-classes-in-typescript

@ बनया जो पूरी तरह से वह नहीं है जो हम अभी चाहते हैं;)।
सज्जाकार हमें ऐसी कक्षाएं बनाने से बचते हैं जिनका हम कभी भी उपयोग करने का इरादा नहीं रखते हैं जैसे हम पुराने स्कूल जावा कर रहे थे। सज्जाकार एक बहुत साफ और सुव्यवस्थित संरचना वास्तुकला की अनुमति देंगे जहां वर्ग मुख्य कार्यक्षमता करना जारी रख सकता है और उस पर अतिरिक्त सामान्यीकृत कार्यक्षमता बना सकता है। हाँ मिक्सिंस इसे कर सकते थे लेकिन यह बैंडेड है।

डेकोरेटर प्रस्ताव पिछले महीनों में महत्वपूर्ण रूप से बदल गया है - यह बेहद असंभव है कि टीएस टीम किसी भी समय मौजूदा कार्यान्वयन में निवेश करेगी जो जल्द ही असंगत होगी।

मैं निम्नलिखित संसाधनों को देखने की अनुशंसा करता हूं:

सज्जाकार प्रस्ताव: https://github.com/tc39/proposal-decorators
टाइपस्क्रिप्ट रोडमैप: https://github.com/microsoft/TypeScript/wiki/Roadmap

@ बनया जो पूरी तरह से वह नहीं है जो हम अभी चाहते हैं;)।
सज्जाकार हमें ऐसी कक्षाएं बनाने से बचते हैं जिनका हम कभी भी उपयोग करने का इरादा नहीं रखते हैं जैसे हम पुराने स्कूल जावा कर रहे थे। सज्जाकार एक बहुत साफ और सुव्यवस्थित संरचना वास्तुकला की अनुमति देंगे जहां वर्ग मुख्य कार्यक्षमता करना जारी रख सकता है और उस पर अतिरिक्त सामान्यीकृत कार्यक्षमता बना सकता है। हाँ मिक्सिंस इसे कर सकते थे लेकिन यह बैंडेड है।

यह मिश्रण नहीं, बल्कि एक वर्ग है।
यह खराब-कॉपी-सामान मिश्रण नहीं है
जब पाइपलाइन ऑपरेटर आएगा, तो सिंटैक्स भी उचित होगा

आप उस प्रभाव को प्राप्त करने के लिए मिक्सिन-क्लास का उपयोग कर सकते हैं

टाइपस्क्रिप्ट में क्लास-फ़ैक्टरी मिक्सिन एक दर्द हो सकता है; यहां तक ​​कि अगर वे नहीं भी थे, तो वे आपको मिक्सिन में बदलने के लिए एक फ़ंक्शन में कक्षाओं को लपेटने की आवश्यकता के कारण बहुत बॉयलरप्लेटी हैं, जो कभी-कभी आप केवल तब नहीं कर सकते जब आप तृतीय-पक्ष कक्षाएं आयात कर रहे हों।

निम्नलिखित बहुत बेहतर, सरल, साफ-सुथरा है, और आयातित तृतीय पक्ष वर्गों के साथ काम करता है। मैंने इसे सादे जावास्क्रिप्ट में ठीक काम किया है, जिसमें विरासत-शैली के डेकोरेटर को स्थानांतरित करने के अलावा कोई ट्रांसपिलेशन नहीं है, लेकिन 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()

और क्रोम में आउटपुट है:

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 में जाम हो गई है। इसके लिए टीएस लोगों को बिल्कुल भी दोष नहीं दे सकते। वे तब तक लागू नहीं होंगे जब तक कि यह मानक न हो।

लेकिन यह माइक्रोसॉफ्ट है, वे बस इसे लागू कर सकते हैं और फिर मानकों से लोग कह सकते हैं - "देखो, लोग पहले से ही हमारे संस्करण का उपयोग कर रहे हैं": ट्रोलफेस:

यहां मुद्दा यह है कि टाइपस्क्रिप्ट द्वारा डेकोरेटर लागू करने के बाद से डेकोरेटर्स का प्रस्ताव _महत्वपूर्ण रूप से (पीछे की ओर असंगत तरीकों से) बदल गया है। यह एक दर्दनाक स्थिति की ओर ले जाने वाला है जब नए डेकोरेटर को अंतिम रूप दिया जाएगा और लागू किया जाएगा, क्योंकि कुछ लोग टाइपस्क्रिप्ट के वर्तमान डेकोरेटर व्यवहार और शब्दार्थ पर भरोसा कर रहे हैं। मुझे दृढ़ता से संदेह है कि टाइपस्क्रिप्ट टीम इस मुद्दे पर कार्रवाई करने से बचना चाहती है क्योंकि ऐसा करने से वर्तमान गैर-मानक सज्जाकारों के आगे उपयोग को बढ़ावा मिलेगा, जो अंततः किसी भी नए डेकोरेटर कार्यान्वयन के लिए संक्रमण को और भी दर्दनाक बना देगा। अनिवार्य रूप से, मैं व्यक्तिगत रूप से ऐसा होते हुए नहीं देखता।

संयोग से, मैंने हाल ही में #36348 बनाया है, जो एक ऐसी सुविधा के लिए एक प्रस्ताव है जो एक बहुत ही ठोस समाधान प्रदान करेगा। बेझिझक इसे देखें/इस पर प्रतिक्रिया दें/सैवेज करें। मैं

tl; dr - यह सुविधा TC39 में जाम हो गई है। इसके लिए टीएस लोगों को बिल्कुल भी दोष नहीं दे सकते। वे तब तक लागू नहीं होंगे जब तक कि यह मानक न हो।

इस तथ्य को देखते हुए, विकास टीम के लिए एक त्वरित स्पष्टीकरण और स्थिति अद्यतन लिखने के लिए बुद्धिमान हो सकता है, और इस बातचीत को तब तक लॉक कर सकता है जब तक कि टीसी39 इसे आवश्यक चरण में आगे नहीं ले जाता है?

क्या इसे पढ़ने वाले किसी का भी इस मामले में कोई वजन है?

दरअसल, लगभग हर सज्जाकार से संबंधित बातचीत हवा में लटकी हुई है। उदाहरण: https://github.com/Microsoft/TypeScript/issues/2607

सज्जाकारों के भविष्य पर कुछ स्पष्टता प्राप्त करना मददगार होने वाला है, भले ही यह योगदानकर्ताओं को आवश्यक कार्यक्षमता को लागू करने के लिए कहने के बारे में हो। स्पष्ट मार्गदर्शन के बिना सज्जाकारों का भविष्य धुंधला है

मुझे अच्छा लगेगा अगर टाइपस्क्रिप्ट टीम डेकोरेटर प्रस्ताव के लिए एक सक्रिय भूमिका निभा सकती है, ठीक उसी तरह जैसे उन्होंने वैकल्पिक श्रृखंला को प्राप्त करने में मदद की। मुझे भी मदद करना अच्छा लगेगा, लेकिन अभी तक भाषा के विकास में काम नहीं किया है और इसलिए यह सुनिश्चित नहीं है कि इसे सर्वोत्तम तरीके से कैसे किया जाए: - /

मैं एक परियोजना के रूप में पूरी टीम, और टाइपस्क्रिप्ट के लिए बात नहीं कर सकता - लेकिन मुझे लगता है कि यह संभावना नहीं है कि हम कोई नया डेकोरेटर काम करेंगे जब तक कि यह तय और पुष्टि न हो जाए, यह देखते हुए कि कैसे टाइपस्क्रिप्ट कार्यान्वयन से डेकोरेटर कार्यान्वयन पहले ही अलग हो गया है।

प्रस्ताव अभी भी सक्रिय विकास में है, और इस सप्ताह 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"));

मुझे लगता है कि दस्तावेज़ों में जोड़ना उचित है कि लौटा वर्ग का इंटरफ़ेस मूल को प्रतिस्थापित नहीं करेगा।

दिलचस्प है, मैंने टाइपस्क्रिप्ट के पुराने संस्करणों के एक समूह का परीक्षण किया और ऐसा कोई अवसर नहीं मिला जहां वह कोड नमूना काम करता हो ( उदाहरण 3.3.3 से ) - तो हाँ, मैं सहमत हूं।

मैंने https://github.com/microsoft/TypeScript-Website/issues/443 बनाया है - अगर कोई जानता है कि उस क्लासडेकोरेटर को एक स्पष्ट चौराहे का प्रकार कैसे बनाया जाए, तो कृपया उस मुद्दे पर टिप्पणी करें

मैं यहाँ समाप्त हो गया क्योंकि ऊपर सूचीबद्ध दस्तावेज़ीकरण के साथ समस्या ने मुझे भ्रमित कर दिया। हालांकि यह बहुत अच्छा होगा यदि डेकोरेटर से लौटाए गए मूल्य के प्रकार के हस्ताक्षर को टीएस कंपाइलर द्वारा मान्यता दी गई थी, उस बड़े बदलाव के बदले में मैं सहमत हूं कि दस्तावेज़ीकरण को स्पष्ट किया जाना चाहिए।

रिकॉर्ड के लिए, यह @orta के पीआर से संबंधित दस्तावेज़ों के प्रारूप में मैं जो प्रयास कर रहा था उसका एक सरलीकृत संस्करण है:

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);