मुझे इस पर कहीं भी कोई जानकारी नहीं मिली, लेकिन मैं सर्वोत्तम प्रथाओं के बारे में उत्सुक हूं।

अपने कार्य प्रोजेक्ट में मैं वर्तमान में अपने प्रॉप्स इंटरफेस को निम्नलिखित के रूप में परिभाषित कर रहा हूं:

export interface ExampleComponentProps {
  readonly firstExampleProp: string;
  readonly secondExampleProp: number
}

क्या export-इंटरफ़ेस या readonly-आईएनजी सदस्यों को संकलन या रनटाइम के दौरान एक प्रदर्शन ओवरहेड लगता है? क्या पठनीयता और खोजकर्ता के अलावा ऐसा करने का कोई फायदा है?

4
Ickerday 22 नवम्बर 2021, 17:39
3
रनटाइम पर प्रदर्शन के बारे में खुद से न पूछें, रनटाइम पर इंटरफेस मौजूद नहीं हैं। संकलन के समय अपने आप से प्रदर्शन के बारे में भी न पूछें, कोई स्पष्ट अंतर नहीं है। अपने स्रोत कोड के संगठन और संरचना के बारे में स्वयं से पूछें, यह केवल एक चीज है जो मायने रखती है
 – 
Guerric P
22 नवम्बर 2021, 17:48
मुझे खोजकर्ता और स्पष्टता पसंद है, यही वजह है कि मैं इस तरह से प्रॉप्स इंटरफेस लिखने के लिए तैयार था, लेकिन मुझे डर था कि इससे मुझे एक महत्वपूर्ण प्रदर्शन ओवरहेड खर्च हो रहा था। शुक्रिया!
 – 
Ickerday
22 नवम्बर 2021, 18:01

2 जवाब

सबसे बढ़िया उत्तर
  • हां, export-आईएनजी प्रॉप्स एक अच्छा अभ्यास है, क्योंकि यह अधिक उन्नत उपयोग-मामलों जैसे घटकों को दूसरे में लपेटने की अनुमति देता है। नीचे दिया गया उदाहरण देखें।
  • मुझे लगता है कि प्रत्येक संपत्ति में readonly जोड़ना एक व्यक्तिगत प्राथमिकता है। हां, किसी कॉम्पोनेंट के अंदर प्रॉप्स को कभी भी ओवरराइट नहीं किया जाना चाहिए, लेकिन साथ ही यह काफी सामान्य ज्ञान है और हर जगह readonly जोड़ना थोड़ा अनावश्यक हो सकता है।
import { ExampleComponent, ExampleComponentProps } from "./ExampleComponent";

type WrappedExampleComponentProps = {
  newProperty: string;
} & ExampleComponentProps; 
// I wouldn't be able to this if I weren't able to import ExampleComponentProps

export const WrappedExampleComponent = (props: WrappedExampleComponentProps ) => {
  const { newProperty, ...otherProps } = props;
  return (
      <ExampleComponent {...otherProps } />
      <SideComponent newProperty={newProperty} />
  );
};

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

2
Martin Devillers 22 नवम्बर 2021, 18:06

टीएलडीआर; हां, जैसा कि Martin's Answer में कहा गया है, प्रॉप्स को निर्यात करना सबसे अच्छा अभ्यास है, इसलिए कोई भी रैपर घटक उनका उपयोग कर सकता है। मेरी राय में केवल पढ़ने वाला झंडा अनावश्यक है क्योंकि प्रॉप्स को हमेशा पढ़ा जाना चाहिए (नीचे समझाया गया है) और प्रदर्शन कोई समस्या नहीं है।

निर्यात

लंबा जवाब: अपने प्रश्न के export-इंग भाग का उत्तर देने के लिए, आपको पूरी तरह से प्रॉप्स इंटरफ़ेस निर्यात करना चाहिए। उदाहरण के लिए Material UI (MUI) लें; टाइपस्क्रिप्ट कन्वेंशन README उनके GitHub राज्यों से:

निर्यात इंटरफ़ेस {घटक नाम} {घटक} Classes.ts से कक्षाएं और एपीआई दस्तावेज़ बनाने के लिए टिप्पणी जोड़ें (आंतरिक घटकों के लिए, कक्षाओं का खुलासा हो सकता है या नहीं, लेकिन टिप्पणी की आवश्यकता नहीं है)

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

निम्नलिखित कोड एक रिएक्ट + टीएस साइट में एक घटक परिभाषा है जिस पर मैं वर्तमान में काम कर रहा हूं।

import type {ButtonProps} from "@mui/material/Button";
import { ThrottleClasses } from "@/store/throttle";

/**
 * Props structure for {@link RequestButton}
 */
export interface RequestButtonProps
  extends Omit<ButtonProps, "title" | "variant"> {
  /**
   * Whether or not the form adjacent to this element is valid.
   */
  valid: boolean;
  /**
   * The name of a value in the throttle store to compare against
   * to decide if the request can be sent.
   */
  throttle?: string;
  /**
   * The `isLoading` property returned from an RTK query or mutation.
   */
  isLoading?: boolean;
  /**
   * The `isError` property returned from an RTK query or mutation.
   */
  isError?: boolean;
  /**
   * The action phrase which is displayed on the button's tooltip.
   */
  title?: React.ReactNode;
  /**
   * The button's style type, analogous to those defined in {@link ButtonProps}.
   */
  variant?: "contained" | "text" | "outlined";
}

/**
 * A button to be used when send requests to the backend.
 * This component also listens to the throttle state in 
 * order to prevent excessive requests if necessary.
 * This can be done by dispatching a throttle action when this button is clicked,
 * and passing the corresponding {@link ThrottleClasses} property to this.
 * @props {@link FormSubmitProps}
 * @component
 */
export const RequestButton: React.FC<RequestButtonProps> = ({
  valid,
  children,
  throttle,
  isLoading,
  isError = false,
  title = children,
  variant = "contained",
  ...props
}) => {
...

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

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

VSCode Example

केवल पढ़ने योग्य गुण

readonly टैग के संबंध में, मैं मार्टिन से पूरी तरह सहमत हूं; प्रॉप्स को फिर से असाइन करना बहुत बुरा व्यवहार है, जो readonly टैग को बेमानी बना देता है। यह इस उत्तर में प्रॉपर को पुन: असाइन करने के बारे में अच्छी तरह से समझाया गया है।

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

प्रदर्शन

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

0
Sam McElligott 22 नवम्बर 2021, 19:08