💅 👨‍🚀 👲🏻 स्वच्छ प्रतिक्रिया कोड लिखने के लिए 14 सुझाव। भाग 1 🦎 🚂 🏤

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

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

1. विनाश गुण

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

विनाशकारी गुण भी प्रोग्रामर को उनके डिफ़ॉल्ट मान सेट करने की अनुमति देता है। यह काफी सामान्य है:

import React from 'react' import Button from 'components/Button' const MyComponent = ({ placeholder = '', style, ...otherProps }) => {   return (     <Button       type="button"       style={{         border: `1px solid ${placeholder ? 'salmon' : '#333'}`,         ...style,       }}       {...otherProps}     >       Click Me     </Button>   ) } export default MyComponent

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

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

 //   async function authenticate({ user_id, token }) {  try {    const response = await axios.post('https://someapi.com/v1/auth/', {      user_id,      token,    })    console.log(response)    return response.data  } catch (error) {    console.error(error)    throw error  } } //   async function authenticate({ user_id, jwt_token, token = jwt_token }) {  try {    const response = await axios.post('https://someapi.com/v1/auth/', {      user_id,      token,    })    console.log(response)    return response.data  } catch (error) {    console.error(error)    throw error  } }

कोड token पहुंचने पर jwt_token का मूल्यांकन किया जाएगा। नतीजतन, अगर jwt_token एक वैध टोकन निकला, और token इकाई undefined , तो jwt_token मान token में गिर जाएगा। यदि token पहले से ही कुछ मूल्य था जो जेएस नियमों (यानी कुछ वास्तविक टोकन) द्वारा गलत नहीं था, तो token में बस वही होगा जो पहले से ही है।

2. एक अच्छी तरह से सोचा फ़ोल्डर संरचना में घटक फ़ाइलों को रखें

निम्नलिखित निर्देशिका संरचना पर एक नज़र डालें:

src
- घटकों
- Breadcrumb.js
- CollapsedSeparator.js
इनपुट
- index.js
- Input.js
- utils.js
- focusManager.js
कार्ड
- index.js
- Card.js
- CardDivider.js
Button.js
Typography.js

ब्रेडक्रंब में विभाजक शामिल हो सकते हैं। CollapsedSeparator घटक Breadcrumb.js फ़ाइल में आयात किया गया है। इससे हमें यह जानकारी मिलती है कि परियोजना के कार्यान्वयन में वे जुड़े हुए हैं। हालाँकि, जो व्यक्ति इस जानकारी के स्वामी नहीं हैं, वे सुझाव दे सकते हैं कि Breadcrumb और Breadcrumb पूरी तरह से स्वतंत्र घटकों की एक जोड़ी है जो किसी भी तरह से एक दूसरे से जुड़े नहीं हैं। विशेष रूप से - यदि CollapsedSeparator कोई स्पष्ट संकेत नहीं है कि यह घटक Breadcrumb घटक के साथ जुड़ा हुआ है। इस तरह के संकेतों के बीच, उदाहरण के लिए, घटक नाम में एक Breadcrumb उपसर्ग का उपयोग किया जा सकता है, जो BreadcrumbCollapsedSeparator.js तरह नाम को कुछ में बदल सकता है।

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

यदि हम अपने उदाहरण में एक अच्छी तरह से सोची-समझी निर्देशिका संरचना का उपयोग करते हैं, तो हमें निम्न जैसा कुछ मिलता है:

src
- घटकों
ब्रेडक्रम्ब
- index.js
- Breadcrumb.js
- CollapsedSeparator.js
इनपुट
- index.js
- Input.js
- utils.js
- focusManager.js
कार्ड
- index.js
- Card.js
- CardDivider.js
Button.js
Typography.js

अब इससे कोई फर्क नहीं पड़ता कि Breadcrumb घटक से जुड़े कितने घटक बनाए जाएंगे। जब तक उनकी फाइलें Breadcrumb.js रूप में एक ही निर्देशिका में स्थित होती हैं। हम जानते हैं कि वे Breadcrumb घटक से जुड़े हैं:

src
- घटकों
ब्रेडक्रम्ब
- index.js
- Breadcrumb.js
- CollapsedSeparator.js
- Expander.js
- BreadcrumbText.js
- BreadcrumbHotdog.js
- BreadcrumbFishes.js
- BreadcrumbLeftOvers.js
- BreadcrumbHead.js
- BreadcrumbAddict.js
- BreadcrumbDragon0814.js
- BreadcrumbContext.js
इनपुट
- index.js
- Input.js
- utils.js
- focusManager.js
कार्ड
- index.js
- Card.js
- CardDivider.js
Button.js
Typography.js

इस तरह से समान संरचनाओं के साथ काम करना कोड में दिखता है:

 import React from 'react' import Breadcrumb, {  CollapsedSeparator,  Expander,  BreadcrumbText,  BreadcrumbHotdog,  BreadcrumbFishes,  BreadcrumbLeftOvers,  BreadcrumbHead,  BreadcrumbAddict,  BreadcrumbDragon0814, } from '../../../../../../../../../../components/Breadcrumb' const withBreadcrumbHotdog = (WrappedComponent) => (props) => (  <WrappedComponent BreadcrumbHotdog={BreadcrumbHotdog} {...props} /> ) const WorldOfBreadcrumbs = ({  BreadcrumbHotdog: BreadcrumbHotdogComponent, }) => {  const [hasFishes, setHasFishes] = React.useState(false)  return (    <BreadcrumbDragon0814      hasFishes={hasFishes}      render={(results) => (        <BreadcrumbFishes>          {({ breadcrumbFishes }) => (            <BreadcrumbLeftOvers.Provider>              <BreadcrumbHotdogComponent>                <Expander>                  <BreadcrumbText>                    <BreadcrumbAddict>                      <pre>                        <code>{JSON.stringify(results, null, 2)}</code>                      </pre>                    </BreadcrumbAddict>                  </BreadcrumbText>                </Expander>                {hasFishes                  ? breadcrumbFishes.map((fish) => (                      <>                        {fish}                        <CollapsedSeparator />                      </>                    ))                  : null}              </BreadcrumbHotdogComponent>            </BreadcrumbLeftOvers.Provider>          )}        </BreadcrumbFishes>      )}    />  ) } export default withBreadcrumbHotdog(WorldOfBreadcrumbs)

3. नामकरण मानक नामकरण का उपयोग करने वाले घटक

कुछ मानकों का उपयोग करते समय घटकों का नामकरण किसी ऐसे व्यक्ति के लिए आसान बनाता है जो इस परियोजना के लिए कोड पढ़ने के लिए परियोजना का लेखक नहीं है।

उदाहरण के लिए, उच्च आदेश घटकों (HOC) के नाम आमतौर पर उपसर्ग के with । कई डेवलपर्स इन घटक नामों के लिए उपयोग किए जाते हैं:

 import React from 'react' import hoistNonReactStatics from 'hoist-non-react-statics' import getDisplayName from 'utils/getDisplayName' const withFreeMoney = (WrappedComponent) => {  class WithFreeMoney extends React.Component {    giveFreeMoney() {      return 50000    }    render() {      return (        <WrappedComponent          additionalMoney={[            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),          ]}          {...this.props}        />      )    }  }  WithFreeMoney.displayName = `withFreeMoney(${getDisplayName(    WrappedComponent,  )}$)`  hoistNonReactStatics(WithFreeMoney, WrappedComponent)  return WithFreeMoney } export default withFreeMoney

मान लीजिए कि कोई इस अभ्यास से पीछे हटने का फैसला करता है और ऐसा करता है:

 import React from 'react' import hoistNonReactStatics from 'hoist-non-react-statics' import getDisplayName from 'utils/getDisplayName' const useFreeMoney = (WrappedComponent) => {  class WithFreeMoney extends React.Component {    giveFreeMoney() {      return 50000    }    render() {      return (        <WrappedComponent          additionalMoney={[            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),            this.giveFreeMoney(),          ]}          {...this.props}        />      )    }  }  WithFreeMoney.displayName = `useFreeMoney(${getDisplayName(    WrappedComponent,  )}$)`  hoistNonReactStatics(WithFreeMoney, WrappedComponent)  return WithFreeMoney } export default useFreeMoney

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

आम तौर पर स्वीकृत मानकों से विचलन किसी और के कोड को समझना मुश्किल बनाते हैं।

4. बुलियन ट्रैप्स से बचें

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

मान लें कि हमने एक Typography घटक बनाया है जो निम्नलिखित विकल्पों को स्वीकार कर सकता है: 'h1' , 'h2' , 'h3' , 'h4' , 'h5 ', 'h6' , 'title' , 'subheading' ।

यदि निम्नलिखित रूप में इसके लिए विकल्प पारित किए जाते हैं तो घटक के आउटपुट पर क्या प्रभाव पड़ेगा?

 const App = () => (  <Typography color="primary" align="center" subheading title>    Welcome to my bio  </Typography> )

जिन्हें रिएक्ट (या बल्कि जावास्क्रिप्ट के साथ) का कुछ अनुभव है, वे पहले ही मान सकते हैं कि title विकल्प सिस्टम के काम करने के तरीके के कारण subheading विकल्प को subheading देगा। अंतिम विकल्प पहले को अधिलेखित कर देगा।

लेकिन यहाँ समस्या यह है कि हम कोड को देखे बिना यह नहीं कह सकते हैं कि title विकल्प या subheading विकल्प विकल्प किस सीमा तक लागू होंगे।

उदाहरण के लिए:

 .title {  font-size: 1.2rem;  font-weight: 500;  text-transform: uppercase; } .subheading {  font-size: 1.1rem;  font-weight: 400;  text-transform: none !important; }

भले ही title जीतता हो, लेकिन सीएसएस text-transform: uppercase नियम लागू नहीं होगा। यह text-transform: none !important की उच्च विशिष्टता के कारण है text-transform: none !important यदि आप ऐसी स्थितियों में सावधानी नहीं बरतते हैं, तो शैलियों में ऐसी त्रुटियों को डीबग करना बेहद मुश्किल हो सकता है। विशेष रूप से - ऐसे मामलों में जहां कोड कंसोल में कुछ चेतावनियों या त्रुटि संदेशों को प्रदर्शित नहीं करता है। यह घटक के हस्ताक्षर को जटिल कर सकता है।

इस समस्या का एक संभावित समाधान Typography घटक के क्लीनर संस्करण का उपयोग करना है:

 const App = () => <Typography variant="title">Welcome to my bio</Typography>

यहाँ Typography घटक कोड है:

 import React from 'react' import cx from 'classnames' import styles from './styles.css' const Typography = ({  children,  color = '#333',  align = 'left',  variant,  ...otherProps }) => {  return (    <div      className={cx({        [styles.h1]: variant === 'h1',        [styles.h2]: variant === 'h2',        [styles.h3]: variant === 'h3',        [styles.h4]: variant === 'h4',        [styles.h5]: variant === 'h5',        [styles.h6]: variant === 'h6',        [styles.title]: variant === 'title',        [styles.subheading]: variant === 'subheading',      })}    >      {children}    </div>  ) }

अब, जब App घटक में हम Typography घटक variant="title" , तो हम यह सुनिश्चित कर सकते हैं कि केवल title घटक के आउटपुट को प्रभावित करेगा। यह हमें घटक कोड का विश्लेषण करने से बचाता है ताकि यह समझ सके कि यह घटक कैसा दिखेगा।

गुणों के साथ काम करने के लिए, आप सरल का उपयोग कर सकते हैं if/else :

 let result if (variant === 'h1') result = styles.h1 else if (variant === 'h2') result = styles.h2 else if (variant === 'h3') result = styles.h3 else if (variant === 'h4') result = styles.h4 else if (variant === 'h5') result = styles.h5 else if (variant === 'h6') result = styles.h6 else if (variant === 'title') result = styles.title else if (variant === 'subheading') result = styles.subheading

लेकिन इस दृष्टिकोण की मुख्य ताकत यह है कि आप केवल निम्नलिखित सिंगल-लाइन डिज़ाइन का उपयोग कर सकते हैं और इसे समाप्त कर सकते हैं:

 const result = styles[variant]

5. तीर के कार्यों का उपयोग करें

एरो फ़ंक्शंस जावास्क्रिप्ट में फ़ंक्शंस घोषित करने के लिए एक संक्षिप्त और स्पष्ट तंत्र का प्रतिनिधित्व करते हैं (इस मामले में, कार्यात्मक अभिव्यक्तियों पर तीर फ़ंक्शंस के लाभ के बारे में बात करना अधिक सही होगा)।

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

रिएक्ट एक समान तरीके से इन अवधारणाओं का उपयोग करता है। हालाँकि, यदि कोई प्रोग्रामर फ़ंक्शंस बढ़ाने में दिलचस्पी नहीं लेता है, तो, मेरी राय में, यह एरो फ़ंक्शंस के सिंटैक्स का उपयोग करने के लिए समझ में आता है:

 //     function Gallery({ title, images = [], ...otherProps }) {  return (    <CarouselContext.Provider>      <Carousel>        {images.map((src, index) => (          <img align="center" src={src} key={`img_${index}`} />        ))}      </Carousel>    </CarouselContext.Provider>  ) } //         const Gallery = ({ title, images = [], ...otherProps }) => (  <CarouselContext.Provider>    <Carousel>      {images.map((src, index) => (        <img align="center" src={src} key={`img_${index}`} />      ))}    </Carousel>  </CarouselContext.Provider> )

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

 //     function GalleryPage(props) {  return <Gallery {...props} /> } //         const GalleryPage = (props) => <Gallery {...props} />

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

6. अपने स्वयं के हुक के बाहर स्वतंत्र कार्य रखें

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

यहाँ एक उदाहरण है:

 import React from 'react' const initialState = {  initiated: false,  images: [], } const reducer = (state, action) => {  switch (action.type) {    case 'initiated':      return { ...state, initiated: true }    case 'set-images':      return { ...state, images: action.images }    default:      return state  } } const usePhotosList = ({ imagesList = [] }) => {  const [state, dispatch] = React.useReducer(reducer, initialState)  const removeFalseyImages = (images = []) =>    images.reduce((acc, img) => (img ? [...acc, img] : acc), [])  React.useEffect(() => {    const images = removeFalseyImages(imagesList)    dispatch({ type: 'initiated' })    dispatch({ type: 'set-images', images })  }, [])  return {    ...state,  } } export default usePhotosList

यदि हम इस कोड का विश्लेषण करते हैं, तो हम यह समझ सकते हैं कि removeFalseyImages कार्य करता है, वास्तव में, हुक के अंदर होने की जरूरत नहीं है; यह अपने राज्य के साथ बातचीत नहीं करता है, जिसका अर्थ है कि इसे इसके बाहर रखा जा सकता है और हुक से बिना किसी समस्या के कॉल किया जा सकता है।

7. कोड लिखते समय लगातार रहें

लेखन कोड के लिए एक सुसंगत दृष्टिकोण कुछ है जो अक्सर जावास्क्रिप्ट में कार्यक्रम करने वालों के लिए अनुशंसित है।

प्रतिक्रिया के मामले में, निम्नलिखित डिजाइनों के उपयोग के लिए एक सुसंगत दृष्टिकोण पर ध्यान देने योग्य है:

आयात और निर्यात टीम।
घटकों, हुक, उच्च क्रम घटकों, कक्षाओं के नामकरण।

घटकों को आयात और निर्यात करते समय, मैं कभी-कभी निम्नलिखित के समान कुछ का उपयोग करता हूं:

 import App from './App' export { default as Breadcrumb } from './Breadcrumb' export default App

लेकिन मुझे सिंटैक्स भी पसंद है:

 export { default } from './App' export { default as Breadcrumb } from './Breadcrumb'

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

संस्थाओं के सम्मेलनों के नामकरण का पालन करना बहुत महत्वपूर्ण है।

उदाहरण के लिए, यदि किसी ने हुक को useApp करने वाला नाम useApp , तो यह महत्वपूर्ण है कि अन्य हुक के नामों का निर्माण इसी तरह किया जाए - उपयोग उपसर्ग का उपयोग करते हुए। उदाहरण के लिए, इस दृष्टिकोण के साथ एक और हुक का नाम useController तरह लग सकता है।

यदि आप इस नियम का पालन नहीं करते हैं, तो अंत में एक परियोजना का कोड कुछ इस तरह से हो सकता है:

 //  #1 const useApp = ({ data: dataProp = null }) => {  const [data, setData] = React.useState(dataProp)  React.useEffect(() => {    setData(data)  }, [])  return {    data,  } } //  #2 const basicController = ({ device: deviceProp }) => {  const [device, setDevice] = React.useState(deviceProp)  React.useEffect(() => {    if (!device && deviceProp) {      setDevice(deviceProp === 'mobile' ? 'mobile' : 'desktop')    }  }, [deviceProp])  return {    device,  } }

यहाँ इन हुकों का आयात कैसा दिखता है:

 import React from 'react' import useApp from './useApp' import basicController from './basicController' const App = () => {  const app = useApp()  const controller = basicController()  return (    <div>      {controller.errors.map((errorMsg) => (        <div>{errorMsg}</div>      ))}    </div>  ) } export default App

पहली नज़र में यह पूरी तरह से basicController है कि basicController एक हुक है, जिसका उपयोग useApp के समान है। यह डेवलपर को आयात के कार्यान्वयन कोड को पढ़ने के लिए मजबूर करता है। यह केवल यह समझने के लिए किया जाता है कि डेवलपर किसके साथ काम कर रहा है। यदि हम लगातार संस्थाओं के नामकरण के लिए एक ही रणनीति का पालन करते हैं, तो ऐसी स्थिति पैदा नहीं होगी। सब कुछ एक नज़र में स्पष्ट हो जाएगा:

 const app = useApp() const controller = useBasicController()

जारी रखने के लिए ...

प्रिय पाठकों! आप अपने रिएक्ट प्रोजेक्ट्स में इकाई के नामकरण के बारे में क्या सोचते हैं?

स्वच्छ प्रतिक्रिया कोड लिखने के लिए 14 सुझाव। भाग 1