रिएक्ट अनुप्रयोगों में सीएसएस-इन-जेएस पुस्तकालयों की छिपी कीमत

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

स्थिति अवलोकन

मेरी कंपनी में, UI लाइब्रेरी बनाने का निर्णय लिया गया था। इससे हमें काफी लाभ होगा, इससे हम विभिन्न परियोजनाओं में इंटरफेस के मानक टुकड़ों का पुन: उपयोग कर सकेंगे। मैं उन स्वयंसेवकों में से एक था जिन्होंने इस कार्य को किया। मैंने CSS-in-JS तकनीक का उपयोग करने का निर्णय लिया, क्योंकि मैं पहले से ही सबसे लोकप्रिय CSS-in-JS पुस्तकालयों की स्टाइलिंग एपीआई से परिचित था। काम के दौरान, मैंने यथोचित कार्रवाई करने का प्रयास किया। मैंने पुन: प्रयोज्य तर्क को डिज़ाइन किया और घटकों में साझा गुण लागू किए। इसलिए मैंने कल-पुर्जों की रचना की। उदाहरण के लिए, <IconButton /> घटक ने <IconButton /> घटक का विस्तार किया, जो बदले में, एक साधारण styled.button इकाई का कार्यान्वयन था। दुर्भाग्य से, यह पता चला कि IconButton को अपनी स्टाइलिंग की आवश्यकता है, इसलिए मैंने इस घटक को एक शैलीगत घटक में बदल दिया:

 const IconButton = styled(BaseButton)`  border-radius: 3px; `; 

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

वैसे, अगर आपने कभी सोचा है कि डेवलपर टूल इंस्पेक्टर का उपयोग करके CSS नियमों को क्यों संपादित नहीं किया जा सकता है, तो ध्यान रखें कि ऐसा इसलिए है क्योंकि वे CSSStyleSheet.insertRule () का उपयोग करते हैं। यह स्टाइल शीट को संशोधित करने का एक बहुत तेज़ तरीका है। लेकिन इसकी कमियों में से एक तथ्य यह है कि संबंधित शैली की चादरें अब निरीक्षक द्वारा संपादित नहीं की जा सकती हैं।

कहने की जरूरत नहीं है, रिएक्ट द्वारा उत्पन्न पेड़ वास्तव में बहुत बड़ा था। Context.Consumer घटकों की संख्या इतनी महान थी कि यह मुझे नींद से वंचित कर सकती थी। तथ्य यह है कि हर बार एक स्टाइल घटक को स्टाइल-घटकों या भावना का उपयोग करके प्रदान किया जाता है , एक नियमित प्रतिक्रिया घटक बनाने के अलावा, एक अतिरिक्त Context.Consumer । Context.Consumer घटक भी Context.Consumer । संगत स्क्रिप्ट (अधिकांश CSS-in-JS लाइब्रेरीज़ को उन स्क्रिप्ट्स पर निर्भर करने की अनुमति देने के लिए आवश्यक है जो पेज को चलाने के दौरान निष्पादित की गई स्क्रिप्ट्स) पर सही ढंग से उत्पन्न स्टाइलिंग नियमों को संसाधित करने के लिए होती हैं। आमतौर पर यह किसी विशेष समस्या का कारण नहीं बनता है, लेकिन हमें यह नहीं भूलना चाहिए कि घटकों को विषय तक पहुंच होनी चाहिए। यह प्रत्येक शैलीगत तत्व के लिए अतिरिक्त Context.Consumer को प्रस्तुत करने की आवश्यकता में अनुवाद करता है, जो आपको ThemeProvider घटक से विषय को "पढ़ने" की अनुमति देता है। नतीजतन, एक विषय के साथ एक आवेदन में एक शैलीगत घटक बनाते समय, 3 घटक बनाए जाते हैं। यह एक StyledXXX घटक और दो और StyledXXX घटक।

सच है, यहाँ कुछ भी विशेष रूप से भयानक नहीं है, क्योंकि रिएक्ट अपना काम जल्दी करता है, जिसका अर्थ है कि ज्यादातर मामलों में हमें चिंता करने की कोई बात नहीं है। लेकिन क्या होगा यदि अधिक जटिल घटक बनाने के लिए कई स्टाइलिश घटकों को इकट्ठा किया जाए? क्या होगा यदि यह जटिल घटक एक लंबी सूची या बड़ी तालिका का हिस्सा है, जहां इनमें से कम से कम 100 घटक प्रदान किए जाते हैं? ऐसी स्थितियों में, हम समस्याओं का सामना कर रहे हैं ...

रूपरेखा

विभिन्न सीएसएस-इन-जेएस समाधानों का परीक्षण करने के लिए, मैंने एक साधारण एप्लिकेशन बनाया। यह 50 बार Hello World टेक्स्ट प्रदर्शित करता है। इस एप्लिकेशन के पहले संस्करण में, मैंने इस पाठ को एक नियमित div एलिमेंट में लपेटा। दूसरे में , मैंने styled.div घटक का उपयोग किया। इसके अलावा, मैंने उस एप्लिकेशन में एक बटन जोड़ा है जिसके कारण इन सभी 50 तत्वों को फिर से प्रस्तुत किया जा सकता है।

<App /> घटक को प्रस्तुत करने के बाद, दो अलग-अलग रिएक्ट पेड़ प्रदर्शित किए गए थे। निम्नलिखित आंकड़े रिएक्ट द्वारा काटे गए तत्व पेड़ों को दर्शाते हैं।


एक पेड़ एक आवेदन में प्रदर्शित होता है जो एक नियमित div तत्व का उपयोग करता है


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

फिर, बटन का उपयोग करते हुए, मैंने सिस्टम पर लोड के संबंध में डेटा एकत्र करने के लिए <App /> 10 बार प्रदान किया, जो Context.Consumer अतिरिक्त घटक Context.Consumer । यहां डिज़ाइन मोड में नियमित रूप से div तत्वों के साथ एक आवेदन को बार-बार पुन: प्रस्तुत करने के बारे में जानकारी दी गई है।


डिज़ाइन मोड में नियमित div तत्वों के साथ एप्लिकेशन को फिर से प्रस्तुत करना। औसत मूल्य 2.54 एमएस है।


विकास मोड में स्टाइलल्डिविव तत्वों के साथ एप्लिकेशन को फिर से प्रस्तुत करना। औसत मूल्य 3.98 एमएस है।

यह बहुत दिलचस्प है कि औसतन, सीएसएस-इन-जेएस एप्लिकेशन सामान्य से 56.6% धीमा है। लेकिन यह एक विकास विधा थी। उत्पादन मोड के बारे में क्या?


उत्पादन मोड में सामान्य div तत्वों के साथ एप्लिकेशन को फिर से प्रस्तुत करना। औसत मूल्य 1.06 एमएस है।


उत्पादन मोड में स्टाइल स्टाइल तत्वों के साथ एप्लिकेशन को फिर से प्रस्तुत करना। औसत मूल्य 2.27 एमएस है।

जब उत्पादन मोड चालू होता है, तो विकास मोड में समान संस्करण की तुलना में एप्लिकेशन का div कार्यान्वयन 50% से अधिक तेज़ी से होता है। एक स्टाइल। डीआईवाई एप्लिकेशन केवल 43% तेज है। और यहां, पहले की तरह, यह स्पष्ट है कि सीएसएस-इन-जेएस समाधान सामान्य समाधान की तुलना में लगभग दोगुना है। क्या उसे धीमा करता है?

इसके निष्पादन के दौरान आवेदन का विश्लेषण

सीएसएस-इन-जेएस एप्लिकेशन को धीमा करने के सवाल का स्पष्ट उत्तर निम्नलिखित हो सकता है: "यह कहा गया था कि एक सौ सीएसएस-इन-जेएस लाइब्रेरी दो Context.Consumer प्रति घटक प्रदान करती है।" लेकिन अगर आप इस सब के बारे में Context.Consumer सोचते हैं, तो Context.Consumer एक JS वैरिएबल को एक्सेस करने के लिए सिर्फ एक तंत्र है। बेशक, रिएक्ट को कुछ काम करने की जरूरत है ताकि यह पता लगाया जा सके कि संबंधित मूल्य को कहां पढ़ना है, लेकिन यह अकेले उपरोक्त माप परिणामों की व्याख्या नहीं करता है। इस सवाल का असली जवाब Context.Consumer का उपयोग करने के कारण का विश्लेषण करके पाया जा सकता है। तथ्य यह है कि अधिकांश सीएसएस-इन-जेएस लाइब्रेरी उन लिपियों पर भरोसा करते हैं जो ब्राउज़र में पेज आउटपुट के दौरान चलते हैं, जो पुस्तकालयों को गतिशील रूप से घटक शैलियों की सहायता करते हैं। ये लाइब्रेरी पृष्ठ असेंबली के दौरान CSS कक्षाएं नहीं बनाती हैं। इसके बजाय, वे दस्तावेज़ में <style> टैग को गतिशील रूप से उत्पन्न और अद्यतन करते हैं। यह तब किया जाता है जब घटकों को माउंट किया जाता है, या जब उनके गुण बदलते हैं। इन टैगों में आम तौर पर एक एकल सीएसएस वर्ग होता है जिसका नाम एक एकल प्रतिक्रिया घटक के लिए हैश नाम होता है। जब इस घटक के गुण बदलते हैं, तो संबंधित <style> टैग को भी बदलना होगा। इस प्रक्रिया के दौरान क्या किया जा रहा है, इसका वर्णन कैसे करें:

• CSS नियम बताते हैं कि <style> टैग फिर से जेनरेट होना चाहिए।
• एक नया हैशेड क्लास नाम बनाया गया है जिसका उपयोग उपरोक्त सीएसएस नियमों को संग्रहीत करने के लिए किया जाता है।
• संबंधित रिएक्ट घटक का classname गुण एक नए से अपडेट किया जाता है, जो केवल निर्मित वर्ग को दर्शाता है।

उदाहरण के लिए, styled-components लाइब्रेरी पर विचार करें। styled.div घटक बनाते समय styled.div पुस्तकालय इस घटक को एक आंतरिक पहचानकर्ता (ID) प्रदान करता है और <head> HTML टैग में एक नया <style> टैग जोड़ता है। इस टैग में एक एकल टिप्पणी है जो प्रतिक्रिया घटक के आंतरिक पहचानकर्ता को संदर्भित करता है, जिसके अनुरूप शैली संबंधित है:

 <style data-styled-components>   /* sc-component-id: sc-bdVaJa */ </style> 

और यहां क्रियात्मक-घटक लायब्रेरी तब क्रिया करती है जब संबंधित अभिक्रिया-घटक प्रदर्शित करते हैं:

1. पार्स स्टाइल स्टाइल घटकों से सीएसएस के नियम स्ट्रिंग।
2. एक नया CSS क्लास नाम बनाता है (या पता करता है कि पिछला नाम रखना है )।
3. स्टाइलिस का उपयोग करते हुए शैलियों का प्रीप्रोसेसिंग करता है ।
4. HTML <head> के संबंधित <style> टैग में प्रीप्रोसेसिंग के परिणामस्वरूप सीएसएस एम्बेड करता है ।

इस प्रक्रिया के चरण # 1 में विषय का उपयोग करने में सक्षम होने के लिए, Context.Consumer की आवश्यकता है । इस घटक के लिए धन्यवाद, टेम्पलेट स्ट्रिंग में विषय से मूल्यों को पढ़ा जाता है। इस घटक से जुड़े <style> टैग को संशोधित करने में सक्षम होने के लिए, घटक से एक और Context.Consumer आवश्यकता है। यह आपको एक स्टाइलशीट के एक उदाहरण का उपयोग करने की अनुमति देता है। यही कारण है कि अधिकांश CSS-in-JS लाइब्रेरीज़ में हम Context.Consumer दो उदाहरणों में आते हैं।

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

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

 const StaticStyledDiv = styled.div`  color:red `; 

और यह घटक स्थिर नहीं है:

 const DynamicStyledDiv = styled.div`  color: ${props => props.color} `; 

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

यदि आप पहले प्रस्तुत किए गए स्क्रीनशॉट का विश्लेषण करते समय पर्याप्त सावधानी बरत रहे थे, तो आप देख सकते हैं कि प्रत्येक styled.div लिए उत्पादन मोड में भी। दो styled.div घटक Context.Consumer । दिलचस्प रूप से, जो घटक प्रदान किया गया था, वह "स्थिर" था, क्योंकि कोई गतिशील सीएसएस नियम इसके साथ जुड़े नहीं थे। ऐसी स्थिति में, किसी को यह उम्मीद होगी कि अगर यह उदाहरण स्टाइल-कंपोनेंट्स लाइब्रेरी का उपयोग करके लिखा गया है, तो यह Context.Consumer नहीं करेगा Context.Consumer को थीम के साथ काम करने की आवश्यकता है। यहाँ दो Context.Consumer क्यों प्रदर्शित किए जाते हैं इसका कारण यह है क्योंकि प्रयोग, जिसका डेटा ऊपर दिया गया है, भावना का उपयोग करके किया गया था - एक और CSS-in-JS लाइब्रेरी। यह पुस्तकालय स्टाइल-घटकों के रूप में लगभग एक ही दृष्टिकोण लेता है। उनके बीच के अंतर छोटे हैं। तो, भावना पुस्तकालय टेम्पलेट स्ट्रिंग को पार करता है, स्टाइलिस का उपयोग करके शैलियों को प्रीप्रोसेस करता है , और इसी <style> की सामग्री को अपडेट करता है। हालांकि, एक महत्वपूर्ण अंतर स्टाइल-घटकों और भावना के बीच ध्यान दिया जाना चाहिए। यह इस तथ्य में ThemeContext.Consumer है कि भावना पुस्तकालय हमेशा ThemeContext.Consumer में सभी घटकों को ThemeContext.Consumer - चाहे वे विषय का उपयोग करें या नहीं (यह ऊपर दिए गए स्क्रीनशॉट की उपस्थिति को स्पष्ट करता है)। दिलचस्प रूप से पर्याप्त है, भले ही भावना स्टाइल-घटकों की तुलना में अधिक उपभोक्ता घटकों को प्रस्तुत करती है, भावनाएं प्रदर्शन के मामले में स्टाइल-घटकों को बेहतर बनाती हैं। यह इंगित करता है कि संदर्भ को धीमा करने के लिए Context.Consumer घटकों की संख्या एक प्रमुख कारक नहीं है। यह ध्यान देने योग्य है कि इस सामग्री को लिखने के समय, स्टाइल-घटकों v5.xx का एक बीटा संस्करण जारी किया गया था, जो कि पुस्तकालय के डेवलपर्स के अनुसार, प्रदर्शन के मामले में भावना को दरकिनार कर देता है।

संक्षेप में हम जो बात कर रहे थे। यह पता चला है कि कई Context.Consumer तत्वों का संयोजन (जिसका अर्थ है कि रिएक्ट को अतिरिक्त तत्वों के काम का समन्वय करना है) और आंतरिक गतिशील स्टाइलिंग तंत्र एप्लिकेशन को धीमा कर सकता है। मुझे कहना होगा कि प्रत्येक घटक के लिए <head> जोड़े गए सभी <style> टैग कभी नहीं हटाए जाते हैं। यह इस तथ्य के कारण है कि तत्व हटाने के संचालन डोम पर एक बड़ा भार बनाते हैं (उदाहरण के लिए, ब्राउज़र को इस वजह से पृष्ठ को फिर से व्यवस्थित करना होगा)। यह भार अनावश्यक <style> तत्वों के पृष्ठ पर मौजूदगी के कारण सिस्टम पर अतिरिक्त भार से अधिक है। ईमानदार होने के लिए, मैं विश्वास के साथ नहीं कह सकता कि अनावश्यक <style> टैग प्रदर्शन समस्याओं का कारण बन सकते हैं। वे केवल पृष्ठ के संचालन के दौरान उत्पन्न अप्रयुक्त वर्गों को संग्रहीत करते हैं (अर्थात, यह डेटा नेटवर्क पर प्रेषित नहीं किया गया था)। लेकिन आपको सीएसएस-इन-जेएस तकनीक का उपयोग करने की इस सुविधा के बारे में पता होना चाहिए।

मुझे कहना होगा कि <style> टैग सभी CSS-in-JS लाइब्रेरीज़ नहीं बनाते हैं, क्योंकि ये सभी उन तंत्रों पर आधारित नहीं होती हैं जो तब काम करते हैं जब पेज ब्राउज़र में काम करते हैं। उदाहरण के लिए, ब्राउज़र में पेज चल रहा है, जबकि लिनारिया लाइब्रेरी कुछ भी नहीं करता है।

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

परिणाम

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

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

एप्लिकेशन प्रदर्शन में सुधार के लिए यहां कुछ सुझाव दिए गए हैं जो लोकप्रिय CSS-in-JS पुस्तकालयों का उपयोग करते हैं जो एक ब्राउज़र में पेज चलने पर अपना काम करते हैं:

1. स्टाइल वाले घटकों की संरचना के साथ बहुत दूर न जाएं। उस गलती को दोहराने की कोशिश न करें, जिसकी मैंने शुरुआत में बात की थी, और कोशिश नहीं की, एक दुर्भाग्यपूर्ण बटन बनाने के लिए, तीन शैलीगत घटकों की एक रचना का निर्माण करें। यदि आप कोड को "पुन: उपयोग" करना चाहते हैं, तो CSS संपत्ति का उपयोग करें और टेम्पलेट स्ट्रिंग लिखें। यह आपको Context.Consumer के कई अनावश्यक घटकों के बिना करने की अनुमति देगा। नतीजतन, रिएक्ट को कम घटकों का प्रबंधन करना होगा, जिससे परियोजना उत्पादकता बढ़ जाएगी।
2. "स्थिर" घटकों का उपयोग करने के लिए प्रयास करें। कुछ सीएसएस-इन-जेएस लाइब्रेरी जेनरेट किए गए कोड को ऑप्टिमाइज़ करते हैं यदि घटक की शैली थीम या गुणों पर निर्भर नहीं होती है। टेम्प्लेट स्ट्रिंग्स में जितना अधिक "स्थिर" होगा, सीएसएस-इन-जेएस पुस्तकालयों में स्क्रिप्ट की संभावना अधिक होगी।
3. अपने रिएक्ट एप्लिकेशन के अनावश्यक री-रेंडरिंग ऑपरेशन से बचने की कोशिश करें। जब आपको वास्तव में इसकी आवश्यकता हो, तभी प्रस्तुत करें। इसके लिए धन्यवाद, न तो रिएक्शन क्रियाएं और न ही सीएसएस-इन-जेएस लाइब्रेरी कार्रवाई लोड होगी। री-रेंडरिंग एक ऑपरेशन है जिसे केवल असाधारण मामलों में किया जाना चाहिए। उदाहरण के लिए - बड़ी संख्या में "भारी" घटकों की एक साथ वापसी के साथ।
4. पता करें कि क्या सीएसएस-इन-जेएस लाइब्रेरी आपके प्रोजेक्ट के लिए उपयुक्त है जो उन लिपियों का उपयोग नहीं करता है जो ब्राउज़र में पृष्ठ चल रहा है, जबकि निष्पादित किए जाते हैं। कभी-कभी हम CSS-in-JS तकनीक का चयन करते हैं क्योंकि डेवलपर के लिए इसका उपयोग करना अधिक सुविधाजनक है, और विभिन्न जावास्क्रिप्ट-एपीआई नहीं। लेकिन अगर आपके आवेदन को समर्थन की जरूरत नहीं है, अगर इसमें सीएसएस संपत्तियों का गहन उपयोग नहीं है, तो यह संभव है कि आप लिनारिया जैसी सीएसएस-इन-जेएस लाइब्रेरी का उपयोग कर सकते हैं जो पृष्ठ चलने के दौरान चलने वाली स्क्रिप्ट का उपयोग नहीं करता है। इसके अलावा, यह दृष्टिकोण लगभग 12 Kb तक एप्लिकेशन बंडल के आकार को कम कर देगा। तथ्य यह है कि अधिकांश CSS-in-JS लाइब्रेरीज़ का कोड आकार 12-15 Kb में फिट बैठता है, और समान लिनारिया का कोड 1 Kb से कम है।

प्रिय पाठकों! क्या आप CSS-in-JS लाइब्रेरीज़ का उपयोग करते हैं?