Definitelytyped: React.d.ts केवल पढ़ने के लिए<t>राज्य और सहारा में</t>

को निर्मित 25 जन॰ 2017 · 91टिप्पणियाँ · स्रोत: DefinitelyTyped/DefinitelyTyped

नमस्ते @ericanderson

व्यवहार में उपयोग किए जाने पर मुझे इस परिवर्तन के साथ कई समस्याएं आ रही हैं:

समस्या 1: परिभाषा पर जाएँ

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

interface MyComponentProps {
    name: string;
}

export abstract class MyComponent extends React.Component<MyComponentProps , void> {
    myMethood() {
       this.props.name; //<-- Go To definition in name
   }
}

समझ में आता है क्योंकि सदस्य कृत्रिम रूप से उत्पन्न होता है, लेकिन वैसे भी परेशान होता है।

समस्या 2: घटकों के पदानुक्रम (बाधाओं के साथ सामान्य पी)

अधिक महत्वपूर्ण, यदि आप इस तरह से अमूर्त घटक बनाते हैं:

interface MyBaseProps {
    onChange?: (val: any) => void;
}

export abstract class MyBase<P extends MyBaseProps> extends React.Component<P, void> {
    myMethood() {
        this.props.onChange!(2); //The type is S["onChange"] instead of (val: any) => void and so is not invocable. 
   }
}

टीएस यह दिखाने में सक्षम है कि चेंज पर एक संपत्ति है, लेकिन कभी-कभी उसका प्रकार नहीं खोजा जा सकता है।

यह सबसे महत्वपूर्ण परिवर्तन है क्योंकि अगर मुझे उन घटकों के पदानुक्रम से रोकता है जो सामान्य प्रोप और कार्यक्षमता साझा करते हैं। यह टीएस कंपाइलर में एक समस्या की तरह दिखता है लेकिन जब तक यह ठीक नहीं हो जाता।

समस्या 3: केवल पढ़ने के लिए नहीं।

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

C# this.state.name = "John"; this.forceUpdate(); //Ok as long as you don't setState afterwards, but calling setState also is annoying with the callback.

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

बेशक आप राज्य को S (या any ) में डाल सकते हैं और बदलाव कर सकते हैं, लेकिन अगर यह एक सामान्य पैटर्न है तो बोझिल हो जाता है।

निष्कर्ष: क्या यह इसके लायक है?

मुझे दुख है कि टीएस की नई चमकदार विशेषता इस मामले में समाधान की तुलना में अधिक समस्याएं पैदा करती है, लेकिन मुझे ईमानदारी से लगता है कि यह मामला यहां है।

दूसरी तरफ, setState का परिवर्तन बहुत अच्छा है Pick<S,K> के बारे में नहीं पता था।

स्रोत

olmobrutall

👍9

सबसे उपयोगी टिप्पणी

मुझे लगता है कि समस्या 3 बहस के लिए तैयार है।

आप सही हैं कि आप उपरोक्त उदाहरण को रिएक्ट में _तकनीकी रूप से कर सकते हैं, लेकिन मैं निश्चित रूप से तर्क दूंगा कि यह उस तरह से नहीं था जिस तरह से रिएक्ट का उपयोग करने का इरादा था।

इसे 3 अलग-अलग मामलों में विभाजित किया जा सकता है।

सामान्य आरंभीकरण

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  public state: State = {
    bar: 5,
  };
}

सहारा के आधार पर आरंभीकरण

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = {
      bar: props.baz,
    };

    // or
    this.setState({
      bar: props.baz,
    });
  }
}

`forceUpdate` के साथ रैंडम असाइनमेंट

यह देखते हुए कि मुझे लगता है कि लोगों को "सही" चीज़ की ओर धकेलना बेहतर है, आप public state को फिर से घोषित करके इस मुद्दे पर आसानी से काम कर सकते हैं:

interface State {
  bar: number;
}

class Foo extends React.Component<{}, State> {
  public state: State;
  public myMethod() {
    this.state.bar = 5;
  }
}

ericanderson 25 जन॰ 2017

👍7

सभी 91 टिप्पणियाँ

आपका विजुअल स्टूडियो किस टाइपस्क्रिप्ट का उपयोग कर रहा है?

ericanderson 25 जन॰ 2017

@vsaio sa . के लिए

ericanderson 25 जन॰ 2017

समस्या 1 के लिए, TS 2.1.5 और नवीनतम VSCode के साथ, यह मेरे लिए ठीक काम करता है। मेरे पास विंडोज़/वीएस नहीं है इसलिए मैं वहां जांच नहीं कर सकता, लेकिन मैं शर्त लगा सकता हूं कि आपके प्लगइन्स में अपडेट हैं या आप टीएस 2.1.5 पर नहीं हैं

ericanderson 25 जन॰ 2017

समस्या 2 के लिए वही

ericanderson 25 जन॰ 2017

टीएस 2.1.5.0 . के साथ वी.एस. 2015

olmobrutall 25 जन॰ 2017

मुझे लगता है कि समस्या 3 बहस के लिए तैयार है।

इसे 3 अलग-अलग मामलों में विभाजित किया जा सकता है।

सामान्य आरंभीकरण

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  public state: State = {
    bar: 5,
  };
}

सहारा के आधार पर आरंभीकरण

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = {
      bar: props.baz,
    };

    // or
    this.setState({
      bar: props.baz,
    });
  }
}

`forceUpdate` के साथ रैंडम असाइनमेंट

interface State {
  bar: number;
}

class Foo extends React.Component<{}, State> {
  public state: State;
  public myMethod() {
    this.state.bar = 5;
  }
}

ericanderson 25 जन॰ 2017

👍7

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

class TBaseState {
  public value: string;
}

function globalFunc<T extends Readonly<TBaseState>>(item: T) {
}

class MyComponent<TProps, TState extends TBaseState> extends React.Component<TProps, TState> {
  broken() {
    // typing of this.state is Readonly<TState>
    // this is not assignable to Readonly<TBase>
    globalFunc(this.state);

    // this is a horrible hack to fix the generics variance issue
    globalFunc(this.state as TState as Readonly<TBaseState>);
  }
}

class MyState extends TBaseState {
}

let component: MyComponent<any, MyState>;

// here the typing of component.state is Readonly<MyState>
// this is assignable to Readonly<TBase>
globalFunc(component.state);

patsissons 25 जन॰ 2017

मैं टीएस 2.1.5.0 . में हूं

लेकिन हो सकता है कि वीएस में हमारे पास वीएस कोड की तुलना में सबसे खराब टीएस अनुभव हो ...

समस्या 1 के लिए, परिभाषा पर जाएँ TS VS कोड में भी काम नहीं करता है:

interface MyComponentProps {
    name: string;
}

export abstract class MyComponent extends React.Component<MyComponentProps , void> {
    fullName: string;
    myMethood() {
       this.props.name; //<-- doesnt work
       this.fullName; //<-- works
   }
}

समस्या 2 के लिए यह सच है कि वीएस कोड बेहतर व्यवहार करता है:

जबकि वीएस भ्रमित दिखता है:

olmobrutall 25 जन॰ 2017

मुझे लगता है कि वीएससीओडी और समस्या 1 के लिए, यह काम कर रहा है क्योंकि मैं "नवीनतम टाइपस्क्रिप्ट और जावास्क्रिप्ट व्याकरण" के लिए प्लगइन का उपयोग कर रहा हूं जिसमें बेहतर प्रबंधन होना चाहिए।

ericanderson 25 जन॰ 2017

@patsissons एक दिलचस्प उदाहरण है, हालांकि मुझे लगता है कि परिभाषा फ़ाइल में एक बग की तुलना में टाइपस्क्रिप्ट में एक बग का अधिक प्रतिनिधि है। उदाहरण के लिए, setState उपयोग S करने के लिए किया जाता था, जिसका अर्थ था कि आंशिक रूप से करने के लिए हमें setState({foo:5} as any as State) जैसी अजीब चालें करनी पड़ती थीं या एक फ़ंक्शन का उपयोग करना होता था। मुझे यकीन नहीं है कि संकलक की अभिव्यक्ति की कमी टाइपिंग को "गलत" बनाती है। मुझे लगता है कि इस एज केस को चिह्नित करने के लिए रीडमे में बदलाव के लिए यह एक अच्छा तर्क है।

क्या आपने TS पर कोई समस्या दर्ज की है?

ericanderson 25 जन॰ 2017

तो यह परिवर्तन आजकल सभी वीएस को तोड़ देता है और सभी वीएस कोड में गो टू डेफिनिशन को अक्षम कर देता है, सिवाय इसके कि आपके पास प्लग-इन है ...

इसके अलावा पूर्णता तर्क है। अरबों एपीआई हैं जो केवल पढ़ने के लिए हैं और आजकल नहीं हैं, बस React.d.ts . में हैं

 interface ComponentLifecycle<P, S> {
        componentWillMount?(): void;
        componentDidMount?(): void;
        componentWillReceiveProps?(nextProps: Readonly<P>, nextContext: any): void;
        shouldComponentUpdate?(nextProps: Readonly<P>, nextState: Readonly<S>, nextContext: Readonly<any>): boolean;
        componentWillUpdate?(nextProps: Readonly<P>, nextState: Readonly<S>, nextContext: Readonly<any>): void;
        componentDidUpdate?(prevProps: Readonly<P>, prevState: Readonly<S>, prevContext: Readonly<any>): void;
        componentWillUnmount?(): void;
    }

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

olmobrutall 25 जन॰ 2017

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

patsissons 25 जन॰ 2017

आह हाँ, मुझे पता था कि मैंने कुछ याद किया है। @olmobrutall यदि हम उन राज्य परिवर्तनों को रखते हैं जिन्हें मैंने केवल पढ़ने के लिए चिह्नित करने के लिए पेश किया था, तो मैं सहमत हूं कि उन विधियों को अद्यतन किया जाना चाहिए। मुझे लगता है कि हमें पहले सही काम करने के लिए आम सहमति की जरूरत है।

जहां तक वीएस ब्रेक का सवाल है, मुझे नहीं पता कि क्या सही है। क्या प्रकारों को वापस रखा जाना चाहिए क्योंकि कुछ उपकरण अद्यतित नहीं हैं?

ericanderson 25 जन॰ 2017

@patsissons आप हमेशा प्रतिक्रिया के लिए अपनी टाइपिंग प्रदान कर सकते हैं यदि आप यह देखने के लिए इंतजार करना चाहते हैं कि यह आपके सभी कोड को अपडेट करने से पहले कैसे निकलता है। https://ericlanderson.com/using-custom-typescript-definitions-with-ts-2-x-3121db84015d#.ftlkojwnb

ericanderson 25 जन॰ 2017

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

patsissons 25 जन॰ 2017

@ericanderson हैक अभी के लिए इतना बुरा नहीं है, मुझे अपना T प्राप्त करने के लिए बस Readonly<T> जीतना है जो Readonly<Base> को असाइन करने योग्य है।

patsissons 25 जन॰ 2017

हम 'react.d.ts' के बारे में बात कर रहे हैं, इस एकल सदस्य घोषणा का व्यापक रूप से उपयोग किया जाता है। मुझे लगता है कि वीएस तैयार होने तक रुकना उचित है।

साथ ही, जैसे दुनिया में 50% प्रकार केवल पढ़ने के लिए होते हैं, जैसे कि आपको एपीआई से प्राप्त होने वाली वस्तुएं, मुझे नहीं लगता कि हमें उस पर टिप्पणी करने की आवश्यकता है।

मुझे लगता है कि रीडोनली का उपयोग उन वस्तुओं के लिए किया जाना चाहिए जिन्हें स्पष्ट रूप से केवल-प्राप्त गुणों में परिवर्तित किया गया है। फ्रीज की तरह।

olmobrutall 25 जन॰ 2017

👍1

@olmobrutall Readonly नया है, इसलिए सटीक सर्वोत्तम अभ्यास वास्तव में परिभाषित नहीं है। मैं व्यक्तिगत रूप से सब कुछ पसंद करूंगा कि यह घोषित करने में मदद करने के लिए Readonly<> चीजों की आवश्यकता होती है कि यह इसे उत्परिवर्तित नहीं करेगा। इसी तरह, रिएक्ट आपसे state को setState $ के बाहर संशोधित करने की अपेक्षा नहीं करता है और इस प्रकार यह परिवर्तन सुनिश्चित करता है कि दुर्घटनाएं बग पेश नहीं करती हैं, जो जावास्क्रिप्ट पर टाइपस्क्रिप्ट का उपयोग करने के प्राथमिक लाभों में से एक है।

यदि प्रदर्शन Object.freeze के लिए ब्राउज़र में अधिक सुसंगत था, तो मुझे लगता है कि प्रतिक्रिया लोग वास्तव में setState के बाद फ्रीज करना शुरू कर देंगे।

ericanderson 25 जन॰ 2017

फोर्सअपडेट का उद्देश्य क्या है?

olmobrutall 25 जन॰ 2017

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

cc/ @johnnyreilly @vsaio @pspeter3 विशेष रूप से प्रतिक्रिया और सामान्य रूप से अन्य विचारों पर विचारों के लिए
cc/ @andy-ms @mhegazy इस बारे में विचारों के लिए कि कैसे निश्चित रूप से टाइप किए गए को टूलींग अपडेट और Readonly के उत्साही उपयोग के लिए दार्शनिक रूप से आगे बढ़ना चाहिए

ericanderson 25 जन॰ 2017

@olmobrutall हम राज्य की ओर से देखने योग्य घटनाओं से प्रेरित प्रतिक्रिया पक्ष पर एक रेंडर को कतारबद्ध करने के लिए forceUpdate का उपयोग करते हैं।

अद्यतन :
मैं अपने परिदृश्य को थोड़ा स्पष्ट करूंगा ताकि इसे गलत न समझा जाए। हमारी राज्य वस्तुएं लंबे समय तक रहने वाली अपरिवर्तनीय वस्तुएं हैं (इसलिए Readonly<T> वास्तव में हमारे लिए बहुत उपयुक्त है)। इन राज्य वस्तुओं में एकाधिक rxjs देखने योग्य धाराएं होती हैं जो stateChanged नामक अधिसूचना में फ़नल होती हैं। प्रतिक्रिया घटक घटनाओं के लिए इसे देखने योग्य देखते हैं और उन घटनाओं को forceUpdate (डिबाउंसिंग के बाद) पर कॉल में फ़नल करते हैं। वास्तव में, हमारा परिवर्तनशील राज्य राज्य के भीतर रहता है, लेकिन राज्य और राज्य में मौजूद सदस्य सभी अपरिवर्तनीय हैं। यह निश्चित रूप से रिएक्ट के लिए मानक उपयोग नहीं है, लेकिन यह प्रवाह में बहुत समान है। हमारे पास बस स्मार्ट स्टेट ऑब्जेक्ट हैं जो जानते हैं कि पुन: प्रतिपादन की आवश्यकता होने पर घटकों को कैसे सूचित किया जाए।

patsissons 25 जन॰ 2017

@ericanderson मुख्य मुद्दा यह है कि इस प्रकार की परिभाषाएँ SemVer मुद्दों से पीड़ित हैं। क्योंकि टाइप डेफिनिशन संस्करण काफी हद तक उनके संबंधित मॉड्यूल संस्करणों से बंधे होते हैं, हम एक मामूली संस्करण बम्प के साथ समाप्त होते हैं जो ब्रेकिंग टाइप डेफिनिशन परिवर्तन लाता है, जिसका अर्थ है कि हमें अपने package.json में @types संस्करणों को पिन करना होगा। फ़ाइल।

patsissons 26 जन॰ 2017

@olmobrutall प्रतिक्रिया के दस्तावेज़ों से:

आम तौर पर आपको forceUpdate() के सभी उपयोगों से बचने की कोशिश करनी चाहिए और केवल this.props और this.state से रेंडर () में पढ़ना चाहिए।

प्रतिक्रिया गाइड वास्तव में आपको सीधे राज्य को अपडेट नहीं करने के लिए कहता है: https://facebook.github.io/react/docs/state-and-lifecycle.html#do -not-modify-state-directly

forceUpdate , जैसा कि मैंने इसे पढ़ा है, यह केवल आपके घटक को अद्यतन करने के लिए मजबूर करने के लिए है जब आपका घटक आपके प्रोप या आपके राज्य में डेटा _not_ पर आधारित होता है।

ericanderson 26 जन॰ 2017

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

उस ने कहा, शायद Readonly<> से state बहुत बड़ा बदलाव है, लेकिन एक पल के लिए मान लीजिए कि यह सही बदलाव है। इसे निश्चित रूप से टाइप किए गए में कब जारी किया जाना चाहिए? state को Readonly<> $ के रूप में चिह्नित करने वाला अपडेट मिलने के बाद आपके कोड को हमेशा बदलने की आवश्यकता होगी।

मैं अभी भी नहीं जानता कि Readonly<> को state पर लागू करने के बारे में क्या सही है जिससे सेवर, या टूलिंग, या किसी अन्य चीज़ पर बहस करना मुश्किल हो जाता है। मेरी आंत थी कि यह सही था। जिन लोगों ने बदलाव की समीक्षा की, उन्होंने इसे कभी मुद्दा नहीं बनाया। यह प्रतिक्रिया टीम के इरादे से इनलाइन लगता है।

मुझे निश्चित रूप से टाइप किए गए में प्रतिक्रिया के लिए किसी भी समीक्षक को स्थगित करने में खुशी हो रही है (मैंने उन सभी को ऊपर cc'd किया है)।

ericanderson 26 जन॰ 2017

तो ऑब्जर्वेबल उस राज्य को बदल देता है जिसे आप अपडेट करते हैं? तो राज्य को अनिवार्य रूप से बदलना कुछ हद तक अनुमति है।

मुझे लगता है कि जहां रीडोनली का उपयोग किया जाना चाहिए वह 100% परिभाषित नहीं है। लेकिन क्या उपकरण तैयार होने से पहले हमें एक विवादास्पद और व्यापक रूप से उपयोग की जाने वाली संपत्ति के साथ शुरुआत करने की आवश्यकता है?

मैं सभी दृढ़ता से टाइप करने के लिए हूं, मैं सख्त नलचेक के साथ 6 परियोजनाओं का प्रबंधन करता हूं, लेकिन यहां लाभ वर्तमान में उत्पन्न होने वाली समस्याओं की तुलना में बहुत कम हैं।

olmobrutall 26 जन॰ 2017

@ericanderson मेरा मानना है कि SemVer2 को नोड संस्करण घोषणाओं जैसे ^15.0.0 की अनुमति देने के लिए डिज़ाइन किया गया है और उम्मीद है कि मॉड्यूल में कोई मामूली या पैच अपग्रेड (यानी, 15.0.1 या 15.1.0 ) पारदर्शी हैं या बाहरी दृष्टिकोण से कम से कम पीछे की ओर संगत। किसी भी बड़े अपग्रेड ( 16.0.0 ) को बदलाव लाने के लिए संस्करण घोषणा में समायोजन की आवश्यकता होगी। यह अनिवार्य रूप से टाइपिंग सिस्टम में लाए जाने से परिवर्तनों को तोड़ देता है। लेकिन वर्तमान में टाइप परिभाषा संस्करण अपने संबंधित मॉड्यूल संस्करण प्रमुख संस्करण (सम्मेलन द्वारा) से विचलित नहीं हो सकते हैं, जिसके परिणामस्वरूप यह असंतुलन होता है।

संक्षिप्त संस्करण यह है कि प्रकार की परिभाषाओं में मॉड्यूल के बिना शुरू किए गए ब्रेकिंग परिवर्तन हो सकते हैं, और ब्रेकिंग परिवर्तनों के लिए एक प्रमुख संस्करण टक्कर की आवश्यकता होती है।

patsissons 26 जन॰ 2017

लेकिन आप एक पीआर हटाने के बल को अपडेट नहीं करेंगे, है ना?

फिर अगर फोर्सअपडेट है तो राज्य को अनिवार्य रूप से बदलना भी होना चाहिए।

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

सौभाग्य से रिएक्ट एक स्केप मार्ग की अनुमति देता है और राज्य में प्रत्यक्ष परिवर्तन संभव बनाता है, क्या हम टीएस डेवलपर्स को उस मार्ग को लेने से मना करने जा रहे हैं? क्या यह बहुत पितृसत्तात्मक नहीं है?

उदाहरण के लिए Vue.js अनिवार्य परिवर्तनों को बढ़ावा देता है, अगर यह प्रतिक्रिया को प्रभावित करता है तो मुझे आश्चर्य नहीं होगा।

इसके अलावा, मैं कुछ रिएक्ट लेखक के ब्लॉग पोस्ट को बहुत पहले नहीं पढ़ रहा था (मुझे याद है) सभी Redux समारोह के बिना रिएक्ट का उपयोग करने के लिए प्रोत्साहित करना।

olmobrutall 26 जन॰ 2017

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

patsissons 26 जन॰ 2017

इस पर सोने के बाद मेरी निजी राय इस प्रकार है:

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

उपरोक्त विचारों के साथ-साथ गैर-मानक रिएक्ट ऐप्स के आसपास के कामकाज को देखते हुए, मुझे लगता है कि रीडऑनली सही है और पूर्णता के लिए केवल आवश्यक परिवर्तन जीवन चक्र विधियों को मिलान करने के लिए अद्यतन करना है।

ericanderson 26 जन॰ 2017

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

patsissons 26 जन॰ 2017

पैटिसन, वीएस, वीएस कोड या किसी अन्य संपादक का उपयोग कर रहे हैं?

मेरा कहना यह है कि जबकि रिएक्ट एक कार्यात्मक दृष्टिकोण को बढ़ावा देता है, यह एक वीडियोगेम-जैसे वर्कफ़्लो की अनुमति देता है जहाँ आप अनिवार्य रूप से (राज्य) दुनिया में परिवर्तन करते हैं और फिर रेंडर (फोर्सअपडेट) करते हैं। यह दृष्टिकोण अब TS में निषिद्ध है। फंक-दंतवाद की तरह :)

मैं अपने वर्तमान पारिस्थितिकी तंत्र को काम करने योग्य बनाने के लिए विकल्पों के बारे में सोचूंगा...

olmobrutall 27 जन॰ 2017

समस्या 2 केवल strictNullChecks के साथ त्रुटि फेंक रहा है।

[TS] Cannot invoke an expression whose type lacks a call signature. Type '((val: any) => void) | undefined' has no compatible call signatures.

GiedriusGrabauskas 30 जन॰ 2017

+1 मैं सख्त नलचेक का उपयोग कर रहा हूं

olmobrutall 30 जन॰ 2017

@ericanderson ?

GiedriusGrabauskas 1 फ़र॰ 2017

जैसा कि ऊपर कहा गया है, यह टूलिंग से संबंधित है, जो स्पष्ट रूप से डीटी के दायरे से बाहर है। यदि आप VSCode पर हैं और आगामी TS पार्सर का पूर्वावलोकन स्थापित करते हैं, तो जब मैं उपरोक्त में से कोई भी लिख रहा था, तो मुझे यह समस्या सख्त नलचेक के साथ नहीं दिखाई दी।

मेरे पास खिड़कियाँ नहीं हैं इसलिए मैं वीएस से ठीक से बात नहीं कर सकता।

ericanderson 1 फ़र॰ 2017

इस Pick पैच ने VSCode के तहत सुझावों को तोड़ा। this.setState({ | }) (Ctrl + Space) करते समय, कुछ भी नहीं दिखाया जाता है, भले ही राज्य स्पष्ट रूप से परिभाषित हो और Partial<State> का उपयोग कर रहा हो क्योंकि setState सदस्यों की स्थिति को चुनिंदा रूप से सेट कर सकता है

IMHO सही कोड setState(state: Partial<S>, callback?: () => any): void; . होना चाहिए

pocesar 19 फ़र॰ 2017

जैसा कि मूल पुल अनुरोध शाखा में चर्चा की गई थी, हमने आंशिक के साथ शुरुआत की। हालाँकि यदि आपका राज्य वस्तु है:

इंटरफ़ेस राज्य {
फू: स्ट्रिंग;
}

फिर आंशिक के साथ आप निम्न कार्य कर सकते हैं:

सेटस्टेट ({foo: अपरिभाषित});

जो स्पष्ट रूप से गलत है।

ericanderson 19 फ़र॰ 2017

मुझे खेद है - लेकिन फिर से Readonly के बारे में

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

तो उस व्यवहार को क्यों जोड़ें जो मूल प्रतिक्रिया कोड में .d.ts फ़ाइल में मौजूद नहीं है? .d.ts मूल पुस्तकालय का प्रतिबिंब होना है, लेकिन लेखक के दृष्टिकोण के अनुसार लोगों को सही कोडिंग शैली की शिक्षा देना नहीं है!

Iezious 23 मार्च 2017

@lezious , मुझे डर है कि मैं आपकी स्थिति को समझ नहीं पा रहा हूं। क्या आप एक कोड नमूना प्रदान कर सकते हैं और नमूने के संबंध में टाइपिंग के बारे में क्या टूटा हुआ है? धन्यवाद!

ericanderson 23 मार्च 2017

कोई दिक्कत नहीं है:

यह मेरा राज्य वर्ग है

class UserInfoBlockState  
{
    <strong i="7">@observable</strong>                  <- this is mobx way to declare state
    public updating: boolean;
    <strong i="8">@observable</strong> 
    public deleted: boolean;
}

और यह मेरा घटक है

<strong i="12">@observer</strong>       <-- this is mobx way to make component react to state change
export class UserPanel extends React.Component<IUserInfoBlockProps, UserInfoBlockState>
{
   ......
     private updateUser()
    {
        this.state.updating = true;
        UsersAPI.update(this.props.user)
       .then(() =>
            {
                this.state.updating = false;      <--- this is the mobx way to work with the state
            }
        ).catch(() =>
            {
                this.showErrror("Server error");
                this.state.updating = false;
            });
    }
   ....

}

और अब हम (हमारी कंपनी रिएक्ट + मोबक्स पर लिखी गई विशाल परियोजना के साथ) ने नए रिलीज सर्कल की शुरुआत पर डीटी और रिएक्ट को अपडेट किया और ... 3000+ संकलन त्रुटियां "संपत्ति केवल पढ़ने के लिए है"। बहुत खूब। आप मुझे क्या करने का सुझाव देते हैं - पूरी परियोजना को redux में फिर से लिखें, कभी भी प्रतिक्रिया अपडेट न करें। d.ts या हमेशा फोर्कड संस्करण रखें और समर्थन करें?

@mweststrate , कृपया इसे जांचें।

Iezious 23 मार्च 2017

👍1

@Iezious मैं आपकी स्थिति की सराहना करता हूं और मैं पूछता हूं कि आप कृपया शांत हो जाएं। मैं आपके साथ काम करने की कोशिश कर रहा हूं। इसका Redux से कोई लेना-देना नहीं है, लेकिन शुद्ध प्रतिक्रिया है।

मैं नहीं चाहता कि डीटी एक ऐसे उपयोग के मामले को अवरुद्ध करे जो पहले काम कर चुका हो, हालाँकि मुझे नहीं लगता कि आप प्रतिक्रिया के साथ मोबक्स के उपयोग का वर्णन कैसे करते हैं, यह प्रतिक्रिया प्रलेखन के अनुरूप है (न ही अब मोबक्स प्रलेखन जिसे मैंने पढ़ा है यह)।

रिएक्ट स्पष्ट रूप से प्रलेखन में बताता है कि राज्य का सही उपयोग करने के 3 तरीके हैं, और सबसे पहले "राज्य को सीधे संशोधित न करें" है।

यह मुझे विश्वास दिलाता है कि जिस तरह से आपका कोड आधार वर्तमान में काम करता है, वह प्रतिक्रिया के भविष्य के संस्करणों में टूटने की काफी संभावना है। https://github.com/mobxjs/mobx-react के माध्यम से देखने में, मुझे कोई सुझाव नहीं दिखता है कि आप इस तरह से राज्य का उपयोग करते हैं। वास्तव में, ऐसा लगता है कि वे चाहते हैं कि आप गुणों का उपयोग करें।

https://mobx.js.org/getting-started.html की समीक्षा करना और "mobx प्रतिक्रिया स्थिति" के लिए गुगली करना, मुझे ऐसा कोई दस्तावेज़ नहीं मिला जो यह सुझाव दे कि आप जिस तरह से कर रहे हैं, उसी तरह से आप mobx का उपयोग करें।

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

मुझे यकीन नहीं है कि मैं आपको क्या सुझाव देता हूं। कुछ विकल्प जो मैं हाथ से सोच सकता हूं:

एक "सस्ता" विकल्प, यदि आप state चर को लेने पर जोर देते हैं तो React.Component को MyComponent से खोजना और बदलना है और MyComponent को उपवर्ग के रूप में परिभाषित करना है React.Component का रीडोनली बाधाओं के बिना।
मोबक्स के लिए प्रलेखन में पोस्ट किए गए मुहावरेदार उदाहरणों के आधार पर एक और, this.state का उपयोग बंद करने के लिए समय निकालना है और वास्तविक React.Component पर केवल चर का उपयोग करना है। यह थोड़ा दर्दनाक हो सकता है लेकिन आपके प्रोजेक्ट में कम से कम नए लोग आपके कोड बेस में पैटर्न देख पाएंगे जैसा कि उन्हें ऑनलाइन वर्णित किया गया है।
आप प्रत्येक घटक में state को फिर से घोषित कर सकते हैं यदि आप इसे उसी तरह करते रहना चाहते हैं जैसे आप कर रहे हैं।
आप this.state को this.somethingElse से खोज और बदल सकते हैं और मैन्युअल रूप से घोषित कर सकते हैं।
आप डीटी से प्रतिक्रिया करने के लिए अपडेट लेना बंद कर सकते हैं (और संभवतः भविष्य में सामान्य रूप से प्रतिक्रिया से भविष्य में परिवर्तन आपके उपयोग के मामले को कैसे प्रभावित कर सकते हैं)।

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

क्षमा करें, मैं आपसे सहमत नहीं हो सका (इसका मतलब यह नहीं है कि दूसरे आपसे सहमत नहीं होंगे)। मैंने उस हिस्से को वापस करने का एक कारण खोजने की कोशिश की, लेकिन मैं इस समय बोर्ड पर नहीं लग सकता।

ericanderson 23 मार्च 2017

👍1

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

patsissons 23 मार्च 2017

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

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

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

Iezious 23 मार्च 2017

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

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

ericanderson 23 मार्च 2017

👍6

https://facebook.github.io/react/docs/react-component.html#state

इसे कभी भी सीधे मत बदलें, क्योंकि कॉल करने के बाद setState() आपके द्वारा किए गए म्यूटेशन को बदल सकता है। इस स्थिति को ऐसे समझें कि यह अपरिवर्तनीय है।

यह बहुत स्पष्ट लगता है कि प्रतिक्रिया this.state अपरिवर्तनीय मानती है। रिएक्ट this.state के _properties_ को अपरिवर्तनीय नहीं मानता (जो कि रेडक्स धारणा है)। आप ऐसा करने के लिए स्वतंत्र हैं:

this.state.user.name = "foo";

मुहावरेदार प्रतिक्रिया में।

मेरी प्राथमिकता एपीआई को सटीक रूप से टाइप करने की ओर है (जिसका इस मामले में मतलब है Readonly ) और प्रतिक्रिया टीम के सभी इनवेरिएंट को व्यक्त करना।

AndyMoreland 23 मार्च 2017

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

johnnyreilly 23 मार्च 2017

@amoreland असहमत। प्रति: https://facebook.github.io/react/docs/state-and-lifecycle.html#do -not-modify-state-directly

राज्य को सीधे संशोधित न करें
उदाहरण के लिए, यह एक घटक को फिर से प्रस्तुत नहीं करेगा:
// Wrong
this.state.comment = 'Hello';
इसके बजाय, सेटस्टेट () का उपयोग करें:
// Correct
this.setState({comment: 'Hello'});
एकमात्र स्थान जहां आप इसे असाइन कर सकते हैं। स्टेट कंस्ट्रक्टर है।

ericanderson 23 मार्च 2017

@johnnyreilly मैंने नहीं किया था। यह तो दिलचस्प है। स्रोत?

ericanderson 23 मार्च 2017

हालिया प्रतिक्रिया सम्मेलन में एक वार्ता में इसे शामिल किया गया था। यह यूट्यूब पर उपलब्ध है। हो सकता है कि यह लिन क्लार्क की बात रही हो। 1 दिन की पहली वार्ता में से एक - v16 के लिए प्रतिक्रिया करने के लिए आगामी परिवर्तनों को कवर करना। फाइबर आदि

johnnyreilly 23 मार्च 2017

https://www.reddit.com/r/reactjs/comments/5zqgsb/react_fiber_functional_setstate/ यहां @gaeron द्वारा उल्लेख किया गया है

johnnyreilly 23 मार्च 2017

सॉरी @gaearon मेरा मतलब था

johnnyreilly 23 मार्च 2017

मोबक्स राज्य परिवर्तन क्यों कर रहा है, इसका कारण यह है कि वेधशालाएं रिएक्ट अपडेट चला रही हैं, राज्य को पूरी तरह से _replaceing_ के बजाय, राज्य एक इंजन बन जाता है जो रेंडरिंग को संचालित करता है। इसलिए this.state.updating = true; जैसा कुछ करके आप वास्तव में एक राज्य प्रतिस्थापन के बराबर कर रहे हैं, लेकिन इसके बजाय राज्य इतना स्मार्ट है कि घटक को सूचित करके एक नया रेंडर ट्रिगर कर सकता है कि राज्य अपनी पिछली सामग्री से बदल गया है। मैं मानता हूं कि यह _परंपरागत_ प्रतिक्रिया उपयोग नहीं है, बल्कि प्रतिक्रिया का अधिक व्यापक और उच्च स्तर का उपयोग है। मेरा तर्क है कि पारंपरिक रिएक्ट का उपयोग केवल मुट्ठी भर घटकों वाली छोटी परियोजनाओं के लिए उपयोगी है। जब आप 100 घटकों के साथ समाप्त होते हैं, जिनमें से प्रत्येक में कई दर्जनों प्रतिक्रियाशील उत्परिवर्तन ड्राइवर होते हैं, तो आप अब पारंपरिक प्रतिक्रिया स्थिति परिवर्तन (यानी, सेटस्टेट) का मज़बूती से उपयोग नहीं कर सकते हैं और वास्तुशिल्प परिवर्तनों का मनोरंजन करना चाहिए जिसमें _smart_ राज्य शामिल है (जो कि मोबक्स अनिवार्य रूप से करता है) )

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

patsissons 23 मार्च 2017

👍2

@Iezious अगर आपको इस प्रकार की समस्या के लिए एक त्वरित समाधान की आवश्यकता है, तो आप प्रतिक्रिया टाइपिंग को बढ़ाकर इससे दूर हो सकते हैं और अपने घटकों को React.Component प्रकार defs के एक्सटेंशन का उपयोग करने के लिए पुन: सक्रिय कर सकते हैं।

import * as React from 'react';
declare module 'react' {
  class MutableStateComponent<P, S> extends React.Component<P, S> {
    state: S;
  }
}
(React as any).MutableStateComponent = React.Component;

और अब आप नियमित घटकों की तरह ही परिवर्तनशील राज्य घटक बना सकते हैं, सिवाय उनके state सदस्य को अब readonly के रूप में चिह्नित नहीं किया गया है।

export class MyComponent extends React.MutableStateComponent<MyProps, MyState> {
  // this.state.name is writable
}

patsissons 23 मार्च 2017

@patsissons हाँ, यही कारण है।

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

मुझे पता है कि मैं अपना घटक बना सकता हूं, मैं अपने एनपीएम सर्वर में भी स्क्रिप्ट बना सकता हूं जो हमेशा हमारी कंपनी के लिए इस बदलाव को वापस लाएगा। मैं "this.state.state.updated" जैसे हैक और किसी भी अन्य हैक का उपयोग कर सकता हूं।

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

Iezious 23 मार्च 2017

शायद मेरे सुझाए गए MutableStateComponent के बजाय हम इसे ObservableComponent कहते हैं जो ऑब्जर्वेबल रिएक्ट पैटर्न के साथ अधिक संरेखित है।

patsissons 23 मार्च 2017

यदि आप Readonly छोड़ देते हैं तो जो लोग नियमित प्रतिक्रिया के साथ प्रतिक्रिया प्रकारों का उपयोग कर रहे हैं (और/या mobx से अलग किसी भी अन्य राज्य-प्रबंधन प्रणाली) त्रुटियों के संपर्क में हैं। मैं अपने विशाल प्रोजेक्ट में mobx का उपयोग नहीं करता हूं और जब कोई टाइपो बनाता है और गलती से this.state.foo = bar का उपयोग करता है तो मैं कंपाइलर त्रुटियों की सराहना करता हूं।

यदि मानक प्रतिक्रिया और गैर-मानक प्रतिक्रिया उपयोग के बीच एक अपरिहार्य ट्रेडऑफ़ है, तो मानक प्रतिक्रिया प्रकार पूर्व की ओर झुकना चाहिए।

AndyMoreland 23 मार्च 2017

इसके अलावा, यदि आप mobx का मुहावरेदार तरीके से उपयोग करते हैं, तो यह कोई समस्या नहीं है।

ericanderson 23 मार्च 2017

यदि आप रीड ओनली को छोड़ देते हैं तो जो लोग नियमित प्रतिक्रिया के साथ प्रतिक्रिया प्रकारों का उपयोग कर रहे हैं (और/या मोबक्स से अलग किसी भी अन्य राज्य-प्रबंधन प्रणाली) त्रुटियों के संपर्क में हैं। मैं अपने विशाल प्रोजेक्ट में mobx का उपयोग नहीं करता और जब कोई टाइपो बनाता है और गलती से this.state.foo = bar का उपयोग करता है तो मैं कंपाइलर त्रुटियों की सराहना करता हूं।

तो एक बार फिर - आप कोड लिखना सिखा रहे हैं

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

बस इतना ही।

Iezious 24 मार्च 2017

@patsissons

यदि आपको इस प्रकार की समस्या के लिए एक त्वरित समाधान की आवश्यकता है, तो आप प्रतिक्रिया टाइपिंग को बढ़ाकर इससे दूर हो सकते हैं और अपने घटकों को React.Component प्रकार defs के एक्सटेंशन का उपयोग करने के लिए पुन: सक्रिय कर सकते हैं।

सही नहीं है। उद्यम की दुनिया में, जहां से मैं हूं, वहां कोई "त्वरित सुधार" नहीं है। जब एसडीके में कुछ बदलता है या पिछड़ा संगत होना चाहिए , या इसमें सालों लगते हैं। कोड प्रोजेक्ट की 2M+ लाइनों में कोई त्वरित सुधार नहीं है। यह बड़ी संख्या में लोगों के लिए परिवर्तन, परीक्षण, ए/बी उत्पाद परीक्षण, रोल-आउट के सप्ताह हैं। इसमें असली पैसा खर्च होता है। और यह सब बड़ा प्रयास सिर्फ इसलिए कि किसी ने पिछड़ा संगत परिवर्तन नहीं जोड़ा जो वास्तविक पुस्तकालय में मौजूद नहीं है?

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

@ericanderson ने लिखा है कि

this.state.state.value = 1

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

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

Iezious 24 मार्च 2017

@Iezious

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

यदि आपकी स्थिति में रिफैक्टरिंग संभव नहीं है, तो परिवर्तन किए जाने से पहले या तो @types/react को 15.0.1 $ पर पिन करें, या केवल @types/react का उपयोग न करें और इसके बजाय अपने स्वयं के संस्करण को बनाए रखें defs टाइप करें और बस state टाइपिंग को Component के लिए बदल दें। मुझे सच में नहीं लगता कि आपको किसी को भी बदलाव को वापस लाने के लिए मनाने में कोई सफलता मिलेगी।

forceUpdate मौजूद है क्योंकि इसे आंतरिक संरचनात्मक स्थिति संशोधित होने पर ड्राइविंग रेंडरिंग के लिए अनुशंसित कोड पथ के रूप में प्रलेखित किया गया है (या जब render() राज्य के बाहर डेटा का उपयोग करता है जो कि परिवर्तनशील है)। forceUpdate का उपयोग ठीक उसी उपयोग पैटर्न के लिए डिज़ाइन किया गया है जिसका उपयोग मेरी टीम प्रतिक्रिया के साथ करती है।

patsissons 24 मार्च 2017

👍3

प्रतिक्रिया टीम जेएस के साथ राज्य को अपरिवर्तनीय बना सकती है, यह आसान है। लेकिन पिछड़ा संगत नहीं।

एक बार फिर, है:

this.state.state.value = 1

वैध या नहीं?

Iezious 24 मार्च 2017

मुझे लगता है कि यह है, लेकिन मेरी राय पहले से ही स्पष्ट है ...

olmobrutall 24 मार्च 2017

👍1

मुझे नहीं लगता कि परिवर्तनशीलता/अपरिवर्तनीयता के बारे में बातचीत प्रासंगिक है _अभी तक। स्पष्ट रूप से इस परिवर्तन के साथ संयुक्त TS कंपाइलर ( Readonly के संबंध में) में बग सामान्य घटकों को उपयोग करने के लिए पूरी तरह से असंभव बना देता है, जिससे बहुत सारे मौजूदा कोड टूट जाते हैं। निश्चित रूप से यह एक सार्वभौमिक रूप से स्वीकृत वैध उपयोग-मामला है और अभी के लिए इसे वापस रोल करने का पर्याप्त कारण है ???

interface test1 {
    num: number;
}

function add<T extends test1>(initial: T, add: number) {
    var copy: Readonly<T> = initial;

    //ERROR HERE: [ts] Operator '+' cannot be applied to types 'T["num"]' and 'number'.
    return copy.num + add;
}

क्या किसी को पता है कि इस बारे में टाइपस्क्रिप्ट टीम के साथ कोई खुला मुद्दा है या नहीं? मुझे उनके ट्रैकर पर प्रासंगिक समस्या नहीं मिल रही है।

caesay 1 मई 2017

@caesay माइक्रोसॉफ्ट/टाइपस्क्रिप्ट देखें#15501

andy-ms 1 मई 2017

मुझे कंस्ट्रक्टर में राज्य में प्रवेश करना है, लेकिन tslint दिखाता है "राज्य केवल पढ़ा जाता है" ....

constructor(props) {
  super(props);
  this.state = {
     value: props.defaultValue,
  };
}

मेरे द्वारा यह कैसे किया जा सकता है...............

alanwei0 27 जून 2017

सेटस्टेट का प्रयोग करें

ericanderson 27 जून 2017

👎2

सेटस्टेट कंस्ट्रक्टर में काम नहीं करता है

alanwei0 27 जून 2017

👍1

या कंपोनेंटविलमाउंट पर विचार करें w/setState

ericanderson 27 जून 2017

धन्यवाद

alanwei0 27 जून 2017

नमस्ते,

मैंने पूरा सूत्र पढ़ा लेकिन मुझे यह स्पष्ट नहीं है कि क्या @alanwei0 परिदृश्य को संभालने की कोई योजना है?

मैं पूरी तरह से सहमत हूं कि state को ReadOnly $ के रूप में रखना समझ में आता है। कहा जा रहा है कि कंस्ट्रक्टर में प्रारंभिक स्थिति को सेट करने में सक्षम नहीं होने से चीजें काफी जटिल हो जाती हैं क्योंकि render को componentDidMount से पहले कहा जाता है।

pawelpabich 12 सित॰ 2017

@pawelpabich कंस्ट्रक्टर में this.state = { का उपयोग करना कोई समस्या नहीं है। आप कंस्ट्रक्टर में readonly वैरिएबल असाइन कर सकते हैं, और Readonly<T> असाइनमेंट (कभी भी!) को नहीं रोकता है।

interface TInterface {
    test: string;
}

class TClass {
    readonly blah: Readonly<TInterface>;
    constructor() {
        this.blah = { test: "constructor" };
    }

    fn = () => {
        this.blah = { test: "fn" };
    }
}

यहां एकमात्र त्रुटि fn के अंदर होगी - Readonly<T> के कारण नहीं, बल्कि readonly कीवर्ड के कारण। वास्तव में, टाइपिंग का नवीनतम संस्करण readonly कीवर्ड का भी उपयोग नहीं करता है, इसलिए आप वास्तव में राज्य को कहीं भी असाइन कर सकते हैं, बस राज्य के अंदर गुण नहीं बदल सकते हैं।

जिस मुद्दे के बारे में हम यहां बात कर रहे थे वह टाइपस्क्रिप्ट कंपाइलर के साथ एक बग था जिसके कारण राज्य के गुण विरासत में मिले घटकों में अपने प्रकार खो देते थे। यह तब से तय किया गया है, मुझे विश्वास है, और यदि ऐसा है तो इस मुद्दे को बंद किया जा सकता है।

caesay 12 सित॰ 2017

@caesay क्षमा करें, मैंने सोचा कि यही वह मामला था जिसके बारे में हम यहां बात कर रहे हैं। मेरी समस्या यह है कि मैं राज्य को बेस क्लास में सेट नहीं कर सकता। मैं टीएस 2.4.1 पर हूं। क्या आप किसी भी तरह से इस मुद्दे की आईडी हैं ताकि मैं इसकी जांच कर सकूं?

pawelpabich 12 सित॰ 2017

आप हमेशा सेटस्टेट (घटकविलमाउंट में) को कॉल कर सकते हैं।

ericanderson 12 सित॰ 2017

@pawelpabich फिर, यह कोई मुद्दा नहीं है :) आप उद्देश्य पर आधार वर्ग से राज्य को असाइन नहीं कर सकते हैं। आप कैसे कर सकते हैं? आप व्युत्पन्न घटक द्वारा उपयोग किए जा रहे प्रोप अनुबंध को नहीं जानते हैं।

interface BaseCompState {
    baseState1?: string;
}

class BaseComp<TState extends BaseCompState> extends React.Component<any, TState> {
    constructor(props) {
        super(props);
        this.state = {
            baseState1: "fromBase",
        };
    }
}

interface TopCompState extends BaseCompState {
    topState1?: string;
}

class TopComp extends BaseComp<TopCompState> {
    constructor(props) {
        super(props);
        this.state = {
            baseState1: "fromTop",
            topState1: "fromTop",
        };
    }
}

यह एक व्युत्पन्न घटक का एक सरल उदाहरण है (छोड़े गए प्रोप, लेकिन एक ही विचार)। बेस क्लास में this.state = स्पष्ट रूप से काम नहीं कर सकता, क्योंकि यह नहीं जानता कि TState क्या है। इसके अलावा, अगर यह _did_ काम करता है, तो यह केवल माता-पिता द्वारा निर्धारित राज्य को ओवर-राइट कर देगा। अंतिम स्थिति { baseState1: "fronBase" } होगी। टॉपस्टेट संपत्ति का क्या हुआ?

यदि आप पूरी तरह से आश्वस्त हैं कि आपको अपने मूल घटक में राज्य को संभालने की आवश्यकता है, तो आप राज्य को व्युत्पन्न घटक से मूल घटक कन्स्ट्रक्टर में पास कर सकते हैं ( TState ताकि आप इसे असाइन कर सकें) - ऐसा कुछ दिख सकता है यह:

interface BaseCompState {
    baseState1?: string;
}

class BaseComp<TState extends BaseCompState> extends React.Component<any, TState> {
    constructor(props, state: TState) {
        super(props);
        this.state = Object.assign({
            baseState1: "fromTop",
        }, state);
    }
}

interface TopCompState extends BaseCompState {
    topState1?: string;
}

class TopComp extends BaseComp<TopCompState> {
    constructor(props) {
        super(props, {
            topState1: "fromTop",
        });
    }
}

या और भी सरल, आप अपने मूल घटक के भीतर से this.setState( पर कॉल कर सकते हैं (हाँ, आप इसे कंस्ट्रक्टर में कर सकते हैं!)

यहां कोई मुद्दा नहीं है।

caesay 12 सित॰ 2017

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

import * as React from "react";

/* tslint:disable:max-classes-per-file*/

interface BaseProps {
    baseProp: string;
}

interface BaseState {
    baseState: string;
}

class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
    constructor(props) {
        super(props);

        this.state = {
            baseState: props.baseProp
        };
    }

    render() {
        return <div>{this.state.baseState}</div>;
    }
}

interface DerivedProps extends BaseProps {
    derivedProp: string;
}

interface DerivedState extends BaseState {
    derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
    constructor(props) {
        super(props);

        this.state = {
            derivedState: props.derivedProp
        };
    }

    render() {
        return <div>{this.state.derivedState}</div>;
    }
}

त्रुटियाँ

webpack: Compiled successfully.
ERROR at Test.tsx(17,9):
TS2322: Type '{ baseState: any; }' is not assignable to type 'Readonly<TState>'.

ERROR at Test.tsx(39,9):
TS2322: Type '{ derivedState: any; }' is not assignable to type 'Readonly<DerivedState>'.
  Property 'baseState' is missing in type '{ derivedState: any; }'.

Version: typescript 2.4.1

pawelpabich 12 सित॰ 2017

प्रथम। कंस्ट्रक्टर में बेस में आपका प्रॉप्स टाइप नहीं किया गया है। इस प्रकार props.baseProp any है, जो असाइन करने योग्य नहीं है!

दूसरा, Derived में आपके प्रॉप्स में भी यही समस्या है और आप baseState को याद कर रहे हैं। रीडोनली की परवाह किए बिना कौन सा पाठ्यक्रम काम नहीं करेगा

ericanderson 12 सित॰ 2017

TProps extends BaseProps जिसका अर्थ है कि TProps में कम से कम वही सदस्य हैं जो BaseProps के हैं। तो यह कैसे परिभाषित नहीं है? मैं समझता हूं कि संकलक इसका अनुमान लगाने में सक्षम नहीं हो सकता है, लेकिन यह कहना कि परिभाषित नहीं है, सही नहीं लगता है। Derived पर भी यही सोच लागू की जा सकती है।

pawelpabich 13 सित॰ 2017

@caesay setState कंस्ट्रक्टर में एक विश्वसनीय समाधान नहीं है क्योंकि यह विधि async है और आप अभी भी प्रारंभिक स्थिति सेट के बिना render प्राप्त कर सकते हैं।

एकमात्र विश्वसनीय समाधान जो मैं देख सकता हूं वह है पूरे राज्य को व्युत्पन्न कक्षाओं में सेट करना। इसका एक स्पष्ट दोष है कि:

इसे हर व्युत्पन्न वर्ग में दोहराया जाना चाहिए
व्युत्पन्न वर्गों को उस राज्य के बारे में जानने की जरूरत है जिसकी उन्हें परवाह नहीं है।

मैंने ऊपर जो उदाहरण दिखाया है वह C# में काम करेगा, इसलिए यह अच्छा होगा यदि यह टाइपस्क्रिप्ट में काम कर सके।

pawelpabich 13 सित॰ 2017

~सेटस्टेट कंस्ट्रक्टर में सुरक्षित है~
व्युत्पन्न वर्ग के मामले में, सबसे अच्छा मामला जो मैं देख सकता हूं वह है setState को अपने componentWillMount में कॉल करना। आपका आधार नहीं जानता कि उसके बच्चे के लिए राज्य में क्या होना चाहिए, इसलिए यह संभवतः एक सुरक्षित कॉन्फ़िगरेशन में this.state प्राप्त नहीं कर सकता है। हालाँकि आपका उपवर्ग माता-पिता के componentWillMount को कॉल कर सकता है और फिर वह जो भी राज्य सोचता है उसे भी सेट कर सकता है।
कई भाषाओं में भाषा की विशेषताएं हैं जो टाइपस्क्रिप्ट में होना अच्छा होगा। कुछ व्यवहार्य हैं। अन्य नहीं हैं। किसी भी तरह से यह उनके शामिल किए जाने का तर्क नहीं है।
आप जो त्रुटियां देख रहे हैं वे समझ में आती हैं। वे टाइपप्रति और न ही टाइपिंग में बग का सुझाव नहीं देते हैं। प्रत्येक मामले में आप सचमुच this.state को उस वस्तु के साथ असाइन करने का प्रयास कर रहे हैं जो अपेक्षित प्रकार से मेल नहीं खाता है।

संपादित, यह प्रतिबिंबित करने के लिए कि मैं कन्स्ट्रक्टर में सेटस्टेट के बारे में गलत था और पठनीयता के लिए बैकटिक्स जोड़ने के लिए गलत था।

ericanderson 13 सित॰ 2017

@ericanderson मुझे नहीं लगता कि हम यहां कोई प्रगति कर रहे हैं। मैंने आपको एक उदाहरण दिखाया और अगर आप इस पर ध्यान केंद्रित कर सकें तो मैं आभारी रहूंगा। अन्यथा चर्चा करना कठिन है।

पुन: setState कंस्ट्रक्टर में उपयोग करना सुरक्षित नहीं है। यह एक त्रुटि नहीं फेंकता है लेकिन रेंडर होने से पहले यह राज्य को सेट नहीं करेगा। मेरे पास कोड है जो उसके कारण टूट जाता है और रिएक्ट डॉक्स बहुत स्पष्ट हैं जिसका उपयोग वहां नहीं किया जाना चाहिए।

pawelpabich 13 सित॰ 2017

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

उदाहरण के लिए, जब आप करते हैं

this.state = { baseState: props.baseProp };
// now the state is exactly { baseState: props.baseProp }

राज्य बिल्कुल { baseState: props.baseProp } है और यह TProps extends BaseProps की आवश्यकता को पूरा नहीं करता है (क्योंकि हम नहीं जानते कि TProps क्या है! इसमें कोई गुण हो सकते हैं)।

उसके बाद, आप एक _ SEPARATE _ असाइनमेंट कर रहे हैं।

this.state = { derivedState: props.derivedProp };
// now the state is exactly {  derivedState: props.derivedProp }

राज्य अब बिल्कुल { derivedState: props.derivedProp } है (आपने अपने मूल राज्य असाइनमेंट को अधिलेखित कर दिया है !!) और यह DerivedState या BaseProps को संतुष्ट नहीं करता है।

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

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

caesay 13 सित॰ 2017

मैं शायद ही आपके साथ इस पर बहस करने के लिए एक नई परियोजना बनाने के लिए पढ़ने से दूर हटना चाहता हूं, लेकिन अफसोस...

मैं कंस्ट्रक्टर में setState () के बारे में सही खड़ा रहूंगा, लेकिन यह नहीं बदलता है कि मैं इसे componentWillMount में उपयोग करने के बारे में कैसा महसूस करता हूं।

यह कैसे किया जाएगा इसका कार्य उदाहरण:
https://github.com/ericanderson/set-state-example

विशेष रूप से, index.tsx:

import * as React from "react";
import * as ReactDOM from "react-dom";

/* tslint:disable:max-classes-per-file*/

interface BaseProps {
  baseProp: string;
}

interface BaseState {
  baseState: string;
}

class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
  public componentWillMount() {
    this.setState({
      baseState: this.props.baseProp,
    });
  }

  public render() {
    return (
      <p>
        <code>this.state.baseState: </code>
        {this.state.baseState}
      </p>
    );
  }
}

interface DerivedProps extends BaseProps {
  derivedProp: string;
}

interface DerivedState extends BaseState {
  derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
  public componentWillMount() {
    super.componentWillMount();
    this.setState({
      derivedState: this.props.derivedProp,
    });
  }

  public render() {
    return (
      <div>
        <p>
          <code>this.state.derivedState: </code>
          {this.state.derivedState}
        </p>
        {super.render()}
      </div>
    );
  }
}

ReactDOM.render(<Derived derivedProp="its derived" baseProp="its basic" />, document.getElementById("main"));

ericanderson 13 सित॰ 2017

@pawelpabich यदि आप प्रारंभिक स्थिति के साथ एक पॉलिमॉर्फिक घटक को कार्यान्वित करना चाहते हैं, तो आपको अपना मूल घटक सार बनाना होगा और अपनी व्युत्पन्न कक्षा में लागू करने के लिए एक सार getInitialState() (या इसी तरह थीम्ड) फ़ंक्शन बनाना होगा। आप केवल एक बार राज्य को कंस्ट्रक्टर में या setState के साथ असाइन करना चाहते हैं जैसा कि @ericanderson ने दिखाया है।

राज्य निर्माण के संबंध में चिंताओं को पूरी तरह से अलग करने के साथ, आपका उदाहरण पूरी तरह से पॉलिमॉर्फिक समाधान में परिवर्तित हो गया है:

interface BaseProps {
  baseProp: string;
}

interface BaseState {
  baseState: string;
}

abstract class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
  constructor(props: TProps) {
      super(props);

      this.state = this.getInitialState();
  }

  protected abstract getInitialState(): TState;

  protected getBaseState() {
    return this.props.baseProp;
  }

  render() {
      return <div>{this.state.baseState}</div>;
  }
}

interface DerivedProps extends BaseProps {
  derivedProp: string;
}

interface DerivedState extends BaseState {
  derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
  getInitialState(): DerivedState {
    return {
      baseState: this.getBaseState(),
      derivedState: this.props.derivedProp,
    };
  }

  render() {
      return <div>{this.state.derivedState}</div>;
  }
}

patsissons 13 सित॰ 2017

👍4

@patsissons धन्यवाद!

pawelpabich 13 सित॰ 2017

@ कैसे मैं मानता हूं कि मैं गलत था और किसी कारण से यह नहीं देखा कि असाइनमेंट एक-दूसरे को ओवरराइड करेंगे। कहा जा रहा है कि CAPS और ! के उपयोग ने मुझे अपने छेद से बाहर निकलने में मदद नहीं की।

@patsissons और @ericanderson ने समस्या पर ध्यान केंद्रित किया और अब हमारे पास एक समाधान है जिसका अन्य लोग उपयोग कर सकते हैं।

pawelpabich 13 सित॰ 2017

@pawelpabich मैं मानता हूं कि मेरे तरीके पेशेवर से कम थे - लेकिन समझ में आता है कि मैंने आपको कई स्पष्टीकरण, नमूने आदि दिए हैं, और आप मेरी बात नहीं सुनना चुनते हैं।

तो यह सिर्फ माता-पिता द्वारा निर्धारित राज्य को ओवर-राइट कर रहा होगा।

[_यदि आप चाहते हैं कि_] अपने मूल घटक में स्थिति को संभालें, तो आप राज्य को व्युत्पन्न घटक से मूल घटक निर्माता में पारित कर सकते हैं

[_यदि आप अपने व्युत्पन्न घटक में राज्य को संभालना चाहते हैं_] आप एक संरक्षित सदस्य getBaseState() जोड़ सकते हैं और जब आप राज्य सेट करते हैं तो इसे व्युत्पन्न कन्स्ट्रक्टर से कॉल कर सकते हैं।

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

caesay 13 सित॰ 2017

मैं प्रतिक्रिया और टाइपस्क्रिप्ट के लिए नया हूं, शायद मैं sth नहीं जानता, लेकिन भले ही ऐप बिना किसी त्रुटि, चेतावनी और संकेत के संकलित हो, मुझे रनटाइम त्रुटि मिलती है। नीचे एक उदाहरण घटक है। मैं त्रुटि का श्रेय Readonly स्थिति को देता हूं। यदि ऐप ने Readonly परिवर्तन से पहले काम किया, तो इस परिवर्तन के बाद इसने काम करना बंद कर दिया और यह कोई संकलन समय त्रुटियाँ नहीं देता है।

import * as React from 'react';

export default class HomePage extends React.Component<any, Map<string, string>> {

  public componentWillMount() {
    const map = new Map<string, string>();
    map.set('aKey', 'aValue');
    this.setState(map);
  }

  public render() {

      return (
        <div className="home">
          <div className="greeting">
            Home page: {this.state.get('aKey')} // <-- I get an error here
          </div>
        </div>
      );
  }
}

त्रुटि:

homePage.tsx:12 Uncaught TypeError: this.state.get is not a function
    at HomePage.render (homePage.tsx:12)
    at eval (ReactCompositeComponent.js:793)
    at measureLifeCyclePerf (ReactCompositeComponent.js:73)
    at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (

jbialobr 29 सित॰ 2017

राज्य हमेशा एक सादे कुंजी वाली वस्तु होना चाहिए, इसलिए इसके बजाय राज्य को परिभाषित करें
कुछ इस तरह: { values: Map <string, string> } और पढ़ें
this.state.values.get('aKey')

ऑप वीआर 29 सितंबर। 2017 बजे 09:01 श्राफ जानूस बियालोब्रज़ेवस्की <
सूचनाएं@github.com>:

मैं प्रतिक्रिया और टाइपस्क्रिप्ट के लिए नया हूँ, शायद मैं sth नहीं जानता, लेकिन यहाँ तक कि
हालांकि ऐप बिना किसी त्रुटि, चेतावनी और संकेत के संकलित करता है, मुझे रनटाइम मिलता है
त्रुटि। नीचे एक उदाहरण घटक है। मैं त्रुटि का श्रेय केवल पढ़ने के लिए देता हूं
राज्य। यदि ऐप रीडोनली परिवर्तन से पहले काम करता है, तो इसके बाद
इसे बदलें काम करना बंद कर दिया और यह कोई संकलन समय त्रुटियां नहीं देता है।
आयात * 'प्रतिक्रिया' से प्रतिक्रिया के रूप में;
निर्यात डिफ़ॉल्ट वर्ग होमपेज React.Component का विस्तार करता है> {
सार्वजनिक घटक विलमाउंट () {
कास्ट नक्शा = नया नक्शा();
map.set ('aKey', 'aValue');
यह.सेटस्टेट (मानचित्र);
}
सार्वजनिक रेंडर () {
  return (
    <div className="home">
      <div className="greeting">
        Home page: {this.state.get('aKey')} // <-- I get an error here
      </div>
    </div>
  );
}
}
त्रुटि:
होमपेज। tsx :12 अनकॉटेड टाइप एरर: this.state.get कोई फंक्शन नहीं है
HomePage.render पर (homePage.tsx:12)
eval पर (ReactCompositeComponent.js:793)
माप पर LifeCyclePerf (ReactCompositeComponent.js:73)
ReactCompositeComponentWrapper._renderValidatedComponentWithOwnerOrContext पर (
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14250#issuecomment-333047367 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABvGhM5hDyRNyUeZuIiGeTZk1N-rfuA4ks5snJW5gaJpZM4LuDWV
.

mweststrate 29 सित॰ 2017

धन्यवाद, लेकिन यह राज्य को Readonly<S> के रूप में घोषित करने का एक व्यर्थ प्रयास प्रतीत होता है, क्योंकि इसके नेस्टेड सदस्य रीडोनली से प्रभावित नहीं होते हैं।

jbialobr 2 अक्तू॰ 2017

यह एक दिन संभव है कि Readonly पुनरावर्ती रूप से लागू होगा, लेकिन अभी के लिए, यह आप पर निर्भर करता है कि आपने इसे सही तरीके से संभाला है। आपके मामले में, आपको वास्तव में ReadonlyMap या . घोषित करना चाहिए

interface State {
    readonly [key: string]: string;
}

या नेस्टेड:

interface State {
    map: { readonly [key: string]: string };
}

ericanderson 2 अक्तू॰ 2017

हम इसका उपयोग केवल डीप रीड के लिए कर सकते हैं:

export type DeepReadonly<T> =
  T extends Array<any> ?
  ReadonlyArray<T[0]> :
  T extends Date ?
  T :
  T extends Function ?
  T :
  T extends object ?
  { readonly [P in keyof T]: DeepReadonly<T[P]> } :
  T;

export type Writable<T> =
  T extends ReadonlyArray<any> ?
  Array<WritableObject<T[0]>> :
  T extends Array<any> ?
  Array<WritableObject<T[0]>> :
  WritableObject<T>;

type WritableObject<T> =
  T extends Date ?
  T :
  T extends Function ?
  T :
  T extends object ?
  { -readonly [P in keyof T]: Writable<T[P]> } :
  T;

danieloprado 28 जून 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Definitelytyped: React.d.ts केवल पढ़ने के लिए<t>राज्य और सहारा में</t>

समस्या 1: परिभाषा पर जाएँ

समस्या 2: घटकों के पदानुक्रम (बाधाओं के साथ सामान्य पी)

समस्या 3: केवल पढ़ने के लिए नहीं।

निष्कर्ष: क्या यह इसके लायक है?

सबसे उपयोगी टिप्पणी

सामान्य आरंभीकरण

सहारा के आधार पर आरंभीकरण

forceUpdate के साथ रैंडम असाइनमेंट

सभी 91 टिप्पणियाँ

सामान्य आरंभीकरण

सहारा के आधार पर आरंभीकरण

forceUpdate के साथ रैंडम असाइनमेंट

राज्य को सीधे संशोधित न करें

संबंधित मुद्दों

`forceUpdate` के साथ रैंडम असाइनमेंट

`forceUpdate` के साथ रैंडम असाइनमेंट