Definitelytyped: ts 2.0 सख्त अशक्त जाँच के साथ defaultProps को लागू करना

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

यहां बताया गया है कि आप अपने उदाहरण में इसे कैसे प्राप्त कर सकते हैं:

interface TestProps { x?: number}

class Test extends React.Component<TestProps, null> {

    static defaultProps =  {x: 5};

    render() {
        const x: number = (this.props.x as number);
        return <p>{x}</p>;
    }
}

देखें https://www.typescriptlang.org/docs/handbook/basic-types.html#type -assertions

अगर इसे संभालने का एक और शानदार तरीका है, तो मुझे इसे सुनना अच्छा लगेगा।

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

तीन सामान्य प्रकार की परिभाषाओं को शामिल करने के लिए टाइप डेफिनिशन फ़ाइल को अपडेट करने पर +1000।

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

सख्त अशक्त प्रकार की जाँच की प्रकृति के कारण प्रवाह समान वर्ग कार्यान्वयन को भी लागू करता है।
https://github.com/facebook/flow/blob/master/lib/react.js#L16
https://github.com/facebook/flow/blob/master/lib/react.js#L104 -L105

ऐसा लगता है कि तीसरे जेनेरिक को जोड़ने के लिए https://github.com/Microsoft/TypeScript/issues/2175 के हल होने की प्रतीक्षा के अलावा हमारे पास यहां अधिक विकल्प नहीं हैं।
मुझे नहीं लगता कि इस तरह के (ब्रेकिंग) परिवर्तन (मेरा मतलब है class Component<P, S, D> ) को समीक्षकों द्वारा अनुमोदित किया जा सकता है।
@johnnyreilly @bbenezech @pzavolinsky क्या आप लोगों की उस पर कोई राय है?

@ r00ger सहमत हुए। परिभाषा बदलना बहुत विघटनकारी है।

क्या किसी ने Partial का उपयोग करने पर विचार किया है?

जैसे की:

    interface ComponentClass<P> {
-        defaultProps?: P;
+        defaultProps?: Partial<P>;
    }

ध्यान न दें कि ऊपर Partial सामान।

आंशिक केवल हल करता है कि आंशिक प्रॉपटाइप समस्या को कैसे घोषित किया जाए। render के अंदर, lastName अभी भी string | undefined प्रकार का है। इसके चारों ओर जाने के लिए, आपको नीचे दिखाए गए अनुसार as या ! का उपयोग करके इसे स्ट्रिंग करना होगा। यह काम करता है, लेकिन आदर्श नहीं है।

interface IUser {
    firstName: string
    lastName?: string
}
export class User extends React.Component<IUser, {}> {
    public static defaultProps: Partial<IUser> = {
        lastName: 'None',
    }

    public render () {
        const { firstName, lastName } = this.props
        // error
        lastName.toUpperCase()

        return (
            <div>{firstName} {lastName}</div>
        )
    }
}

मैंने अभी TS का उपयोग करना शुरू किया है। क्या मुझे कुछ याद आ रहा है?

अगर किसी के पास प्रकार और डिफ़ॉल्टप्रॉप के लिए अच्छा समाधान है, तो मैं सभी कान हूं। हम वर्तमान में ऐसा करते हैं:

interface Props {
  firstName: string;
  lastName?: string;
}

interface DefaultProps {
  lastName: string;
}

type PropsWithDefaults = Props & DefaultProps;

export class User extends React.Component<Props> {
  public static defaultProps: DefaultProps = {
    lastName: 'None',
  }

  public render () {
    const { firstName, lastName } = this.props as PropsWithDefaults;

    return (
      <div>{firstName} {lastName}</div>
    )
  }
}

+1
मैं वर्तमान में इस मुद्दे से जूझ रहा हूं।

+1

+1

तीसरे प्रकार के पैरामीटर को जोड़ने के अलावा, आपको डिफ़ॉल्ट प्रॉप्स के खिलाफ प्रॉप्स को अलग करने की क्षमता की आवश्यकता होगी। खुशी से TS 2.4 के रूप में यह अब संभव है! देखें https://github.com/Microsoft/TypeScript/issues/12215#issuecomment -319495340

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

मुझे गलत मत समझो, मुझे टाइपस्क्रिप्ट पसंद है, लेकिन फ्लो 0.53 के बाद से मुझे कहना होगा कि यह रिएक्ट डेवलपमेंट के लिए बेहतर है https://medium.com/flow-type/even-better-support-for-react-in-flow- 25b0a3485627

@Hotell Flow में React.Component के लिए तीन प्रकार के पैरामीटर हैं - आपके द्वारा फ़्लो से लिंक किए गए मध्यम लेख के अनुसार, उपवर्ग एनोटेशन से वर्ग प्रकार के मापदंडों का अनुमान लगा सकते हैं - एक साफ-सुथरी भाषा-स्तरीय सुविधा TS समर्थन नहीं करती है, लेकिन एक प्रकार नहीं -घोषणा विचार AFAIK।

@aldendaniels

रिएक्ट के लिए फ्लो में तीन प्रकार के पैरामीटर होते हैं। कॉम्पोनेंट

नहीं, यह 0.53 से पहले ऐसा हुआ करता था, अब और नहीं :)

@ होटेल आह, निश्चित रूप से पर्याप्त! मुझे सुधारने के लिए धन्यवाद।

AFAIK हालांकि टीएस में डिफ़ॉल्ट प्रोप के प्रकार का अनुमान लगाने का कोई तरीका नहीं है। तीन-प्रकार-पैरामीटर दृष्टिकोण का उपयोग करके हम टाइपस्क्रिप्ट टीम से अपस्ट्रीम परिवर्तनों को अवरुद्ध किए बिना सही टाइपिंग प्राप्त करने में सक्षम होंगे।

क्या आप typeof MyComponent.defaultProps को एक प्रकार के परम के रूप में पारित किए बिना एक स्थिर संपत्ति के अनुमानित प्रकार का उपयोग करने के तरीके के बारे में जानते हैं?

इस विषय पर कोई खबर? क्या कोई तीसरे प्रकार के पैरामीटर को जोड़ने और https://github.com/Microsoft/TypeScript/issues/12215#issuecomment -319495340 का उपयोग करने के लिए पीआर करता है?

अपवोटिंग मुद्दा: वही समस्या

+1

मैं भी इसमें भाग गया, और मैंने static defaultProps का उपयोग करने से बचने के लिए (जब तक यह ठीक से तय नहीं हो जाता) चुना है और इसके बजाय एक सहायक एचओसी का उपयोग करें:

फ़ाइल घटक/हेल्पर्स/withDefaults.tsx :

import * as React from 'react'

export interface ComponentDefaulter<DP> {
  <P extends {[key in keyof DP]?: any}>(Component: React.ComponentType<P>): React.ComponentType<
    Omit<P, keyof DP> &         // Mandate all properties in P and not in DP
    Partial<Pick<P, keyof DP>>  // Accept all properties from P that are in DP, but use type from P
  >
}

export default function withDefaults<DP>(defaultProps: DP): ComponentDefaulter<DP> {
  return Component => props => <Component {...defaultProps} {...props}/>
}

अब मैं इसका उपयोग कर सकता हूं:

फ़ाइल घटक/Button.tsx :

import * as React from 'react'
import withDefaults from './helpers/withDefaults'

export interface ButtonProps {
  label: string
  onPress: () => any
}

export const defaultProps = {
  onPress: () => undefined
}

class Button extends React.Component<ButtonProps> {
  // ...
}

export default withDefaults(defaultProps)(Button)

तीन संभावित डाउनसाइड्स (जो मैं सोच सकता हूं):

1. इसके लिए एक एचओसी की आवश्यकता होती है, लेकिन चूंकि यह रिएक्ट की दुनिया में एक बहुत ही सामान्य प्रतिमान है, यह ठीक लगता है।
2. आपको प्रॉप्स को एक सामान्य प्रकार के पैरामीटर के रूप में घोषित करना होगा, और props संपत्ति से अनुमान पर भरोसा नहीं कर सकते।
3. defaultProps के प्रकारों की कोई अंतर्निहित जाँच नहीं है, लेकिन export const defaultProps: Partial<ButtonProps> = {...} निर्दिष्ट करके इसका उपचार किया जा सकता है।

@vsaarinen के अनुसार, मैं props: Props & DefaultProps के साथ बेस क्लास लिखता हूं, इसलिए बेस क्लास को विस्तारित करने वाली पूरी कक्षा $#$ this.props as PropsWithDefaults #$ का उपयोग किए बिना सीधे this.props का उपयोग कर सकती है।

इस कदर:

import * as React from 'react'

export class Component<P = {}, S = {}, DP = {}> extends React.Component<P, S> {
  props: Readonly<{ children?: React.ReactNode }> & Readonly<P> & Readonly<DP>
}

export interface Props {
  firstName: string
  lastName?: string
}

export interface DefaultProps {
  lastName: string
}

export class User extends Component<Props, any, DefaultProps> {
  render() {
    const { firstName, lastName } = this.props

    // no error
    return (
      <div>{firstName} {lastName.toUpperCase()}</div>
    )
  }
}

वास्तव में @ qiu8310 जो पूरी तरह से काम नहीं करता था, फिर भी कॉल साइटों के साथ समस्याएँ थीं जो उन डिफ़ॉल्ट प्रॉप्स के बारे में चिल्ला रही थीं जो वैकल्पिक नहीं थे। इसे मामूली समायोजन के साथ काम करने के लिए मिला

import * as React from 'react'

export class Component<P = {}, S = {}, DP = {}> extends React.Component<P, S> {
  // Cast the props as something where readonly fields are non optional
  props = this.props as Readonly<{ children?: React.ReactNode }> & Readonly<P> & Readonly<DP>
}

export interface Props {
  firstName: string
  lastName?: string
}

export interface DefaultProps {
  lastName: string
}

export class User extends Component<Props, any, DefaultProps> {
  render() {
    const { firstName, lastName } = this.props

    // no error
    return (
      <div>{firstName} {lastName.toUpperCase()}</div>
    )
  }
}

मैंने तीसरे जेनेरिक के साथ खेला और @ qiu8310 के प्रस्ताव के समान कुछ समाप्त किया:

// ComponentWithDefaultProps.ts
import * as React from "react";

export declare class ComponentWithDefaultProps<P, S, DP extends Partial<P>> extends React.Component<P & DP, S> {}
type redirected<P, S, DP> = ComponentWithDefaultProps<P, S, DP>;
const redirected: typeof ComponentWithDefaultProps = React.Component as any;

export const Component = redirected;

// User.ts
import { Component } from "ComponentWithDefaultProps";
export interface Props {
  firstName: string
  lastName?: string
}
export interface DefaultProps {
  lastName: string
}

export class User extends Component<Props, {}, DefaultProps> {
  public render() {
    const { firstName, lastName } = this.props;
    return <div>{firstName} {lastName.toUpperCase()}</div>;
  }
}

हालाँकि ये दोनों दृष्टिकोण (मेरा और ऊपर का दृष्टिकोण) बड़ी समस्या का कारण बनते हैं। मेरे उदाहरण में निर्मित घटक के प्रकार हैं:

User: React.ComponentClass<P & DP>
User["props"]: Readonly<{ children?: React.ReactNode }> & Readonly<P & DP>

जाहिर है, User का इंटरफ़ेस गलत है। React.ComponentClass<P & DP> का अर्थ है कि lastName की भी आवश्यकता है, ताकि

<User firstName="" />;
//    ~~~~~~~~~~~~  Property 'lastName' is missing...

@ qiu8310 के उदाहरण प्रकार भिन्न हैं:

User: React.ComponentClass<P>
User["props"]: Readonly<{ children?: React.ReactNode }> & Readonly<P> & Readonly<DP>

लेकिन JSX का एक ही टुकड़ा एक ही त्रुटि का कारण बनता है, क्योंकि tsc के JSX चेक props ' प्रकार पर आधारित होते हैं ।

<User firstName="John" />;
//    ~~~~~~~~~~~~~~~~  Property 'lastName' is missing...

मजेदार बात यह है कि <User firstName="John" /> को React.createElement(User, {firstName: "John"}) में बदला जा रहा है जो कि एक वैध टाइपस्क्रिप्ट होगा। उस स्थिति में प्रकार की जाँच ComponentClass पहले प्रकार के पैरामीटर पर निर्भर करती है, इसलिए

<User firstName="Jonh" />; // doesn't work, but
React.createElement(User, { firstName: "John" }); // works

जैसा कि आप देख सकते हैं, यहां तक ​​​​कि तीसरी जेनेरिक होने पर भी हमें सही इंटरफ़ेस वाले घटक को निर्यात करने के लिए एक और चाल जोड़नी होगी:

export const User = class extends Component<Props, {}, DefaultProps> {
    // ...
} as React.ComponentClass<Props>;

<User firstName="Jonh" />; // works

तो तीसरा जेनेरिक होने का ज्यादा मतलब नहीं है।

ऐसा लगता है कि कोई अच्छा समाधान नहीं है जिसे React की परिभाषा में विलय किया जा सकता है, अभी के लिए मैं ComponentWithDefaultProps का उपयोग कर रहा हूं और निर्यात किए गए घटक के प्रकार पर जोर दे रहा हूं।

export interface DefaultProps {
    lastName: string;
}
export interface Props extends Partial<DefaultProps> {
    firstName: string;
}

export type PropsWithDefault = Props & DefaultProps;

export const User: as React.ComponentClass<Props> =
class extends React.Component<PropsWithDefault> {
    render() {
        // no error
        return <div>
            {this.props.firstName}
            {this.props.lastName.toUpperCase()}
        </div>;
    }
};
// Note, we've assigned `React.Component<PropsWithDefault>` to `React.ComponentClass<Props>`

इसके अलावा आप घटक के तरीकों में this.props प्रकार के हर उपयोग पर जोर दे सकते हैं (उदाहरण के लिए const { lastName } = this.props as Props & DefaultProps , या हर जगह विस्मयादिबोधक चिह्न का उपयोग this.props.lastName!.toLowerCase() )।

मुझे इस चर्चा के बारे में कुछ उदाहरण मिले - https://github.com/gcanti/typelevel-ts#objectdiff

@rifler तथाकथित एचओसी दृष्टिकोण (मैं डेकोरेटर पसंद करता हूं) यहां कुछ समय के लिए रहा है , हम ऐसे समाधान के साथ आने का प्रयास करते हैं जो रनटाइम ओवरहेड नहीं जोड़ता है

बहुत अच्छे
आशा है आपको समाधान मिल जाएगा

कोइ प्रगति?

@r00ger द्वारा उल्लिखित तकनीक पर निम्नलिखित भिन्नता है:

interface IUser {
    name: string;
}
const User = class extends React.Component<IUser> {
    public static defaultProps: IUser = {name: "Foo"}
    public render() {
        return <div>{this.props.name}</div>;
    }
} as React.ComponentClass<Partial<IUser>>;
React.createElement(User, {}); // no error, will output "<div>Foo</div>"

उपरोक्त स्निपेट का उपयोग करना काम करेगा, लेकिन आप उपयोगकर्ता पर स्थिर गुणों का उपयोग करने की क्षमता खो देंगे, क्योंकि यह एक अनाम वर्ग बन जाता है। एक हैकी समाधान वर्ग के नाम को छाया देना होगा, जैसे:

// tslint:disable-next-line:no-shadowed-variable
const User = class User extends React.Component<IUser>

अब आप कक्षा के अंदर निजी स्थिर क्षेत्रों का उपयोग कर सकते हैं। सार्वजनिक सांख्यिकी अभी भी अनुपयोगी हैं। इसके अलावा, tslint को चुप कराने की आवश्यकता पर ध्यान दें।

मैंने सोचा कि यह उल्लेखनीय है कि टीएस 2.8 के रूप में, Exclude प्रकार आधिकारिक तौर पर समर्थित है:

type Omit<T, K> = Pick<T, Exclude<keyof T, K>>;

https://github.com/Microsoft/TypeScript/pull/21847 देखें।

तो हमें केवल React.createElement() के लिए Props के बदले निम्नलिखित की आवश्यकता है:

Omit<Props, keyof DefaultProps>

एकमात्र समस्या यह है कि रिएक्ट घोषणाओं में, कोई DefaultProps प्रकार नहीं है - इसके लिए हमें या तो तीसरे प्रकार के पैरामीटर या भाषा सुविधा के रूप में स्थिर सदस्यों के प्रकार का अनुमान लगाने की क्षमता की आवश्यकता है।

इस बीच, हम निम्नलिखित के साथ काम कर रहे हैं:

/**
 * The Create type allow components to implement a strongly thed create() function
 * that alows the caller to omit props with defaults even though the component expects
 * all props to be populated. The TypeScript React typings do not natively support these.
 */
export type Create<C extends BaseComponent<any, any>, D extends {} = {}> = (
  props?: typeHelpers.ObjectDiff<C['props'], D> & React.ClassAttributes<C>,
  ...children: React.ReactNode[]
) => React.ComponentElement<any, any>;

export interface DomPropsType {
  domProps?: domProps.DomProps;
}

export class BaseComponent<P, S = {}> extends React.Component<P & DomPropsType, S> {
  static create(props?: object, ...children: React.ReactNode[]) {
    return React.createElement(this, props, ...children);
  }

  constructor(props: P & DomPropsType, context?: any) {
  ...
}

और हमारे सभी घटक इस तरह दिखते हैं:

export class InsertObjectMenu extends BaseComponent<Props, State> {
  static create: Create<InsertObjectMenu, typeof InsertObjectMenu.defaultProps>;
  static defaultProps = {
    promptForImageUpload: true,
  };
  ...
}

अंत में हमारे पास एक लिंट नियम है जो लागू करता है कि create विशेषता सभी घटकों पर घोषित की जाती है। हम JSX का उपयोग नहीं करते हैं, इसलिए हम इसका उपयोग करते हैं:

InsertObjectMenu.create({...})

इसके बजाय React.createElement() ।

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

इस "साधारण मुद्दे" में इतना समय लगाया। मैं इसे यहाँ छोड़ता हूँ https://medium.com/@martin_hotell/ultimate -react-component-patterns-with-typescript-2-8-82990c516935

    interface Component<P = {}, S = {}, DP extends Partial<P>=P> extends ComponentLifecycle<P, S> { }
    class Component<P, S, DP extends Partial<P> = P> {
        constructor(props: P & DP, context?: any);

        // We MUST keep setState() as a unified signature because it allows proper checking of the method return type.
        // See: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment-351013257
        // Also, the ` | S` allows intellisense to not be dumbisense
        setState<K extends keyof S>(
            state: ((prevState: Readonly<S>, props: P) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
            callback?: () => void
        ): void;

        forceUpdate(callBack?: () => void): void;
        render(): ReactNode;

        // React.Props<T> is now deprecated, which means that the `children`
        // property is not available on `P` by default, even though you can
        // always pass children as variadic arguments to `createElement`.
        // In the future, if we can define its call signature conditionally
        // on the existence of `children` in `P`, then we should  remove this.
        private __externalProps: Readonly<{ children?: ReactNode }> & Readonly<P>;
        props: Readonly<{ children?: ReactNode }> & Readonly<P> & DP;
        state: Readonly<S>;
        context: any;
        refs: {
            [key: string]: ReactInstance
        };
    }

    class PureComponent<P = {}, S = {}, DP extends Partial<P>=P> extends Component<P, S, P> { }


interface ElementAttributesProperty { __externalProps: {}; }

अंतिम पंक्ति को ध्यान से देखें।

इन परिवर्तनों के साथ हम कर सकते थे

interface Props {
    a: string
    b?: string
    c?: string
}

class Comp extends React.Component<Props, {}, typeof Comp.defaultProps> {
    static defaultProps = {
        b: ''
    }

    render() {
        const {a, b, c} = this.props

        let res = a.concat(b)  // ok
        let res1 = a.concat(c) //fail

        return null
    }
}



const res1= <Comp a=''/> // ok
const res3 = <Comp /> // fail

static defaultProps का उपयोग करने पर हम सबसे अच्छा कौन सा प्राप्त कर सकते हैं (यदि हम typeof Comp.defaultProps को छोड़ना चाहते हैं तो ts चेकर को बदला जाना चाहिए)।
अन्य विकल्प, पहले से ही कहा गया था - एचओसी, टाइप कास्ट।

https://medium.com/@martin_hotell/ultimate -react-component-patterns-with-typescript-2-8-82990c516935 के विचार के आधार पर मेरा (बहुत बदसूरत) प्रयास यहां दिया गया है:

type ExtractProps<T> = T extends React.ComponentType<infer Q> ? Q : never;
type ExtractDefaultProps<T> = T extends { defaultProps?: infer Q } ? Q : never;
type RequiredProps<P, DP> = Pick<P, Exclude<keyof P, keyof DP>>;
type RequiredAndPartialDefaultProps<RP, DP> = Required<RP> & Partial<DP>;

type ComponentTypeWithDefaultProps<T> =
  React.ComponentType<
    RequiredAndPartialDefaultProps<
      RequiredProps<ExtractProps<T>, ExtractDefaultProps<T>>,
      ExtractDefaultProps<T>
    >
  >;

function withDefaultProps<T extends React.ComponentType<any>>(Comp: T) {
  return Comp as ComponentTypeWithDefaultProps<T>;
}

interface IProps {
  required: number;
  defaulted: number;
}

class Foo extends React.Component<IProps> {
  public static defaultProps = {
    defaulted: 0,
  };
}

// Whichever way you prefer... The former does not require a function call
const FooWithDefaultProps = Foo as ComponentTypeWithDefaultProps<typeof Foo>;
const FooWithDefaultProps = withDefaultProps(Foo);

const f1 = <FooWithDefaultProps />;  // error: missing 'required' prop
const f2 = <FooWithDefaultProps defaulted={0} />;  // error: missing 'required' prop
const f3 = <FooWithDefaultProps required={0} />;  // ok
const f4 = <FooWithDefaultProps required={0} defaulted={0} />;  // ok

@decademoon , ऐसा लगता है कि हम इस समाधान का उपयोग @types/react पर कर सकते हैं, है ना? मेरा मतलब है, अगर हम आपके समाधान के साथ सामान्य React.ComponentType को प्रतिस्थापित करते हैं।
अगर ऐसा है, तो शायद आप पीआर बना सकते हैं?

@decademoon आपकी परिभाषा उस मामले को संभालती नहीं है जहां गैर-डिफ़ॉल्ट प्रोप में वास्तव में वैकल्पिक फ़ील्ड शामिल होते हैं, यानी

interface IProps {
  required: number;
  notRequired?: () => void;
  defaulted: number;
}

class Foo extends React.Component<IProps> {
  public static defaultProps = {
    defaulted: 0,
  };
}

मैंने इसे "आवश्यक" के साथ "आरपी" को लपेटने के लिए आपके RequiredAndPartialDefaultProps प्रकार को बदलकर मेरे मामले में काम किया है।

type RequiredAndPartialDefaultProps<RP, DP> = RP & Partial<DP>;

मुझे आश्चर्य है कि अभी भी कोई उचित समाधान नहीं है या कम से कम एनपीएम पर काम करने वाला एचओसी नहीं है; जब तक मैंने कुछ याद नहीं किया।

https://github.com/Microsoft/TypeScript/issues/23812

हेलो सब लोग। बस कहना चाहता था और यदि आप अभी भी इस धागे को पढ़ रहे हैं: मुझे लगता है कि @JoshuaToenyes ने सबसे सार्थक और उपयोगी व्याख्या की है। यह निश्चित रूप से कोई मुद्दा नहीं है इसलिए इसका इससे कोई लेना-देना नहीं है। इस मामले में प्रकार के दावे का प्रयोग करें।

@toiletpatrol वास्तव में, @decademoon का समाधान (मेरे मामूली संशोधन के साथ) स्वचालित रूप से डिफ़ॉल्ट प्रोप को ठीक से संभालता है। यह निश्चित रूप से सभी के लिए सुविधा मानक प्रदान करने के लिए प्रतिक्रिया के लिए डीटी परिभाषाओं में विलय किया जा सकता है।

@toiletpatrol @RobRendell क्या आपने इसे https://github.com/Microsoft/TypeScript/issues/23812 देखा?

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

एक और समाधान जो मैं अभी मुश्किल मामलों के लिए उपयोग कर रहा हूं:

const restWithDefaults = { ...Component.defaultProps, ...rest };
return <Component {...restWithDefaults} />;

मुझे लगता है कि इसमें कुछ भी गलत नहीं है, इसलिए मैं इसे यहां एक गंदे लेकिन सरल कामकाज के रूप में छोड़ रहा हूं।

TS 3.2 और प्रतिक्रिया 16.7 टाइपिंग इसे ठीक कर रहे हैं। क्या हम बंद कर सकते हैं?

@Hotell अंततः इसे कैसे संभाला जाना चाहिए? मैं अभी भी इसे ठीक से काम नहीं कर पा रहा हूं

दूसरों को कुछ समय बचाने के लिए, टाइपस्क्रिप्ट 3 के रिलीज नोट्स का लिंक यहां दिया गया है:
JSX में डिफ़ॉल्टप्रॉप्स के लिए समर्थन

@cbergmiller मुझे डर है कि वे टाइपस्क्रिप्ट 3.1 के लिए रिलीज़ नोट हैं

अभी भी React.FunctionComponent . के साथ एक ही समस्या है

@denieler मैं defaultProps के साथ React.FunctionComponent का उपयोग करने की सलाह नहीं दूंगा, यह स्वाभाविक नहीं है। डिफ़ॉल्ट फ़ंक्शन पैरामीटर का उपयोग करना बेहतर है:

interface HelloProps {
  name?: string;
  surname?: string;
}

const HelloComponent: React.FunctionComponent<HelloProps> = ({
  name = 'John',
  surname = 'Smith',
}) => {
  return <div>Hello, {name} {surname}!</div>
};

@mgol यदि मैं प्रॉप्स को नष्ट नहीं करना चाहता, तो आप डिफ़ॉल्ट फ़ंक्शन मापदंडों को कैसे परिभाषित करेंगे?
मैं केवल "डिफ़ॉल्ट" गुणों को नष्ट करने के बारे में सोच सकता हूं जैसे:

interface HelloProps {
  name?: string;
  surname?: string;
}

const HelloComponent: React.FunctionComponent<HelloProps> = ({
  name = 'John',
  surname = 'Smith',
  ...props
}) => {
  return <div>Hello, {name} {surname}! You are {props.age} years old.</div>
};

लेकिन मुझे केवल कुछ प्रॉप्स निकालना शर्मनाक लगता है।

@gleceter आप उपयोग कर सकते हैं:

HelloComponent.defaultProps = {
    name: 'John',
    surname: 'Smith'
}

@Glinkis कृपया, https://github.com/reactjs/rfcs/pull/107/files#diff -20b9b769068a185d90c23b58a2095a9dR184 पर ध्यान दें।

@glecetre आप सभी प्रॉप्स को नष्ट क्यों नहीं करना चाहते हैं? यह defaultProps को परिभाषित करने और टाइप करने में आसान से आसान है। यदि आप बाहरी रूप से उपयोग करने के लिए निर्यात करते हैं तो क्लास-आधारित घटक का प्रॉप्स प्रकार आपको काट सकता है क्योंकि आवश्यक प्रॉप्स की अब आवश्यकता नहीं हो सकती है यदि उनके लिए defaultProps में कोई प्रविष्टि है। defaultProps का उपयोग करना भी थोड़ा जादुई लगता है जबकि पैरामीटर में यह सभी जावास्क्रिप्ट को नष्ट कर देता है।