दृश्य घटकों का एकीकरण। भाग 1. शैलियाँ

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

गीत

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

उपयोग की गई शर्तें:

• एक दृश्य घटक एक घटक है जो DOM में एम्बेडेड तत्व देता है। उदाहरण के लिए, return (<div />) । एक घटक जो केवल दूसरे घटक को लौटाता है, उसे नेत्रहीन व्याख्या नहीं की जानी चाहिए।

परिचय

जब आप एक घटक विकसित करते हैं, तो आप इसे पूरी तरह से सार्वभौमिक नहीं बना सकते। आपके सिर में, आप हमेशा इसके उपयोग के लिए विशिष्ट विकल्पों से शुरू करते हैं। यह अक्सर पता चलता है कि विकास के बाद, आपके सहकर्मी "इस घटक को कहीं भी भेजना" शुरू करते हैं। आप उनसे नाराज़ हैं: “ठीक है, मैंने इसे इसके लिए विकसित नहीं किया है! यह इस कार्य के लिए अभिप्रेत नहीं है! " बेशक, सुधार अपरिहार्य हैं, और आवश्यक भी। लेकिन यह इंडेक्स को 4px से 8px तक बढ़ाने के लिए एक नया सहारा फेंकने जैसे सुधार नहीं होना चाहिए, जो कि पचास में से एक या दो मामलों में उपयोग किया जाएगा। अवयवों में कस्टम बाहरी ज्यामिति होनी चाहिए।

टाइपस्क्रिप्ट, मदद करें

इंटरफ़ेस पर विचार करें, जो अर्थ में स्थित होना चाहिए, उदाहरण के लिए, src/Library/Controls.ts । खेतों के लिए संक्षिप्त टिप्पणी दी गई है, नीचे हम उन्हें और अधिक विस्तार से विश्लेषण करेंगे।

 export interface VisualComponentProps { //  .   - children?: React.ReactNode; //    css className?: string; //   ,     . doNotRender?: boolean; //     doNotRender true fallback?: JSX.Element; //    css style?: React.CSSProperties; } 

यह घटक सहारा इंटरफ़ेस है। कौन-कौन से? सभी दृश्य घटक। उन्हें इसके मूल तत्व पर लागू किया जाना चाहिए।

प्रत्येक विकसित दृश्य घटक के प्रॉप्स को इस इंटरफ़ेस का उपयोग करके विस्तारित किया जाना चाहिए।

तुरंत इस तथ्य पर ध्यान दें कि ये सभी प्रॉप वैकल्पिक हैं। उन पर विचार करें।

• children React.Component वर्ग के घटकों, React.FC घटक घटकों में हैं, लेकिन वे React.FC टाइपिंग को निर्दिष्ट किए बिना सामान्य कार्यों में नहीं हैं। इसलिए, हम उससे पूछते हैं।
• className/style समान नाम का उपयोग करते हैं, जैसा कि सामान्य JSX'nom <div /> में है। हम शब्दार्थ का उत्पादन नहीं करते हैं। नाम की पहचान के इस सिद्धांत का उपयोग, उदाहरण के लिए, रिफ लिंक को निर्दिष्ट करने के लिए प्रॉप्स में किया जाता है ।
• doNotRender रेंडरिंग में दर्दनाक बैसाखी के विकल्प के रूप doNotRender उपयोग किया जाता है। इस समाधान को लागू करते हुए, हमें कोड की पठनीयता को ख़राब करते हुए, रेंडर तरीकों में ब्रेसेस लगाने की आवश्यकता नहीं है। 2 कोड स्निपेट की तुलना करें:
  
  वर्जिन सशर्त प्रतिपादन:
  
  App.tsx
  
  

   renderComponent() { const {props, state} = this; const needRender = state.something; return ( <PageLayout> <UIButton children={'This is a button'} /> {needRender && <UIButton children={'This is another button'} /> } </PageLayout> ); } 

  
  चाड प्रॉप्स doNotRender:
  
  App.tsx
  
  

   renderComponent() { const {props, state} = this; const needRender = state.something; return ( <PageLayout> <UIButton children={'This is a button'} /> <UIButton children={'This is another button'} doNotRender={!needRender} /> </PageLayout> ); } 

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

मैं यह दिखाना चाहता हूं कि इसका सही इस्तेमाल कैसे किया जाए। चलो एक साधारण बटन बनाते हैं।

नोट: नीचे दिए गए कोड में मैं सीएसएस-मॉड्यूल, एसएएस और क्लासनाम का भी उपयोग करता हूं।

UIButton.tsx

 import * as React from 'react'; import { VisualComponentProps } from 'Library/Controls'; import * as css from './Button.sass'; import cn from 'classnames'; //  ()  export interface ButtonBasicProps { disabled?: boolean; } export interface ButtonProps extends ButtonBasicProps, VisualComponentProps {} export function UIButton(props: ButtonProps) { //   undefined,     // "Nothing was returned from render." if (props.doNotRender) return props.fallback || null; //      const rootClassNames = cn( // ,   sass css.Button, // ,     props props.className, //      props.disabled && css._disabled ); return ( <div children={props.children} className={rootClassNames} style={props.style} /> ) } 

App.tsx

 renderComponent() { const {props, state} = this; const needRenderSecond = true; return ( <PageLayout> <UIButton children={'This is a button'} style={{marginRight: needRenderSecond ? 5 : null}} /> <UIButton disabled children={'This is another button'} doNotRender={!needRenderSecond} /> </PageLayout> ); } 

परिणाम:

चिंतन और निष्कर्ष

विभिन्‍न आवरणों, रचनाओं, विशेषज्ञताओं का निर्माण करते हुए, उनमें सम्‍मिलित मूल कार्यक्षमता के ढाँचे से परे जाकर ऐसे घटकों के साथ काम करना सुविधाजनक है।

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

अंत में, मैं कुछ जोड़े (शाब्दिक) क्षण जोड़ूंगा।

1. ध्यान दें कि doNotRender सशर्त प्रतिपादन व्यवहार को पूरी तरह से दोहराता नहीं है। आप जीवन चक्र विधियों को भी चलाएंगे, बस रेंडर एक कमबैक या अशक्तता लौटाएगा। कुछ जटिल घटकों में, आप जीवन चक्र विधियों को निष्पादित करने से बचना चाह सकते हैं। ऐसा करने के लिए, आपको बस अपने घटक का एक अंतर्निहित विशेषज्ञता बनाने की आवश्यकता है।
   
   UIButton उदाहरण का उपयोग करना: UIButton का नाम बदलकर UIButtonInner करें और इसके अंतर्गत निम्न कोड जोड़ें:
   
   UIButton.tsx
   
   

    export function UIButton(props: ButtonProps) { if (props.doNotRender) return props.fallback || null; return <UIButtonInner {...props} />; } 

   
   PS इस फ़ंक्शन में UIButton पुनरावर्ती कॉल त्रुटि न करें!
   
2. दुर्लभ मामलों में जब आवरण और लिपटे घटक पर शैली स्वतंत्र रूप से बदल सकती है, तो निम्न इंटरफ़ेस आपके लिए उपयोगी हो सकता है
   
   Library/Controls.ts
   
   

    export interface VisualComponentWrapperProps extends VisualComponentProps { wrappedVisual?: VisualComponentProps; } 

   
   
   और इसका उपयोग

   UIButton.tsx
   
   

    interface ButtonSomeWrapperProps extends ButtonBasicProps, VisualComponentWrapperProps { myCustomProp?: number; } export function UIButtonSomeWrapper(props: ButtonSomeWrapperProps) { if (props.doNotRender) return props.fallback || null; const { //  VisualComponentProps  style, className, children, fallback, doNotRender, // VisualComponentProps   wrappedVisual, //    myCustomProp, //     ...uiButtonProps } = props; return ( <div style={style} className={className} > {myCustomProp} <UIButton {...wrappedVisual} {...uiButtonProps} /> {children} </div> ); } 

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