सीएसएस-इन-जेएस , पूरी तरह से नई तकनीक नहीं है और कई पुस्तकालयों में कार्यान्वित किया जाता है , फिर भी इसके उपयोग की उपयुक्तता के बारे में संदेह और बहस उठाता है। प्रतिक्रिया-सीएसएस-मॉड्यूल और बैबेल-प्लगइन के लेखक, गजस कुइजिनस ने सीएसएस-इन-जेएस के बारे में विवादों में "i" पर अपने डॉट्स सेट किए, और विशेष रूप से स्टाइल-घटकों के बारे में, एक साल पहले (27 अप्रैल 2017) -रेट-सीएसएस-मॉड्यूल , अभी भी मेरी राय में वर्तमान प्रकाशन "वेब विकास में सीएसएस-इन-जावास्क्रिप्ट का उपयोग करना बंद करें । "
निम्नलिखित कुछ परिवर्धन और निष्कर्ष के साथ थोड़ा संक्षिप्त अनुवाद है:
सीएसएस कहीं भी नहीं जाता है । कई परियोजनाओं में, जावास्क्रिप्ट में स्टाइलिंग का विकल्प गलत है। हम सीएसएस के माध्यम से आम गलतफहमी (मिथकों) और उनके संबंधित निर्णयों की सूची देंगे।
सीएसएस और जावास्क्रिप्ट का इतिहास
CSS एक मार्कअप भाषा में लिखे गए दस्तावेज़ की प्रस्तुति का वर्णन करने के लिए बनाया गया था। जावास्क्रिप्ट को एक "भाषा-गोंद" के रूप में बनाया गया था जैसे कि चित्र और प्लगइन्स जैसे घटकों को इकट्ठा करना। वर्षों से, जेएस बड़े हो गए हैं और बदल गए हैं, आवेदन के नए क्षेत्रों के लिए अनुकूल हैं। और, परिणामस्वरूप, आज हम एकल-पृष्ठ अनुप्रयोगों (एसपीए) के युग में रहते हैं, घटकों से इकट्ठे हुए अनुप्रयोग।
CSS के बारे में क्या?
यहाँ स्टाइल घटक के प्रलेखन से एक उद्धरण है:
नियमित सीएसएस के साथ समस्या यह है कि यह उस युग में बनाया गया था जब वेब दस्तावेजों से बना था। 1993 में मुख्य रूप से वैज्ञानिक दस्तावेजों का आदान-प्रदान करने के लिए वेब बनाया गया था और सीएसएस को इन दस्तावेजों को स्टाइल करने के लिए एक समाधान के रूप में पेश किया गया था। हालाँकि, आज हम विकसित, इंटरैक्टिव, उपयोगकर्ता-उन्मुख अनुप्रयोग विकसित कर रहे हैं, और सीएसएस केवल इसके लिए डिज़ाइन नहीं किया गया है।
ऐसा नहीं है।
सीएसएस पहले से ही आधुनिक उपयोगकर्ता इंटरफेस की सभी आवश्यकताओं को ध्यान में रखता है। पिछले दशक में लागू नए कार्यों की संख्या ऐसी है कि उन सभी (छद्म-वर्ग, छद्म तत्व, सीएसएस चर, मीडिया क्वेरी, कीफ्रेम, कॉम्बिनेटर, कॉलम, फ्लेक्स, ग्रिड, गणना मूल्यों, ...) को भी सूचीबद्ध करना असंभव है।
उपयोगकर्ता इंटरफ़ेस के दृष्टिकोण से, "घटक" दस्तावेज़ का एक पृथक टुकड़ा है (<बटन /> "घटक" है)। CSS को स्टाइल दस्तावेजों के लिए डिज़ाइन किया गया है, और दस्तावेज़ सभी घटकों को कवर करता है। क्या समस्या है?
जैसा कि कहा जाता है: "नौकरी के लिए सही उपकरण का उपयोग करें।"
स्टाइल घटकों
स्टाइल-घटक तथाकथित का उपयोग करके जावास्क्रिप्ट में सीएसएस लिखना संभव बनाता है टेम्प्लेट स्ट्रिंग्स को टैग किया गया । पुस्तकालय घटकों और शैलियों के बीच मानचित्रण को हटा देता है - घटक निम्न-स्तरीय स्टाइलिंग निर्माण में बदल जाता है, उदाहरण के लिए:
// Create a <Title> react component that renders an <h1> which is // centered, palevioletred and sized at 1.5em const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `;
स्टाइल-कंपोनेंट्स आज लोकप्रिय हैं और रिएक्ट में स्टाइलिंग घटकों के एक नए तरीके के रूप में जाना जाता है, हालांकि कभी-कभी इसे "सीएसएस विकास के शिखर" के रूप में भी प्रस्तुत किया जाता है:
सीएसएस विकास: सीएसएस, एसएएसएस, बीईएम, सीएसएस मॉड्यूल से स्टाइल घटक तक ।
लेकिन चलिए निम्नलिखित को स्पष्ट करते हैं: स्टाइल-घटक सिर्फ एक सीएसएस ऐड-ऑन है। यह लाइब्रेरी आपके द्वारा जावास्क्रिप्ट में परिभाषित सीएसएस शैलियों को पार्स करती है और उपयुक्त जेएसएक्स तत्व बनाती है।
स्टाइल-घटकों की लोकप्रियता कई गलत धारणाओं से भरा है। प्रोग्रामर के जवाबों की समीक्षा (आईआरसी, रेडिट और डिस्कोर्ड पर पाया गया) उन कारणों के बारे में एक सवाल है, जिन्होंने उन्हें इस पुस्तकालय का उपयोग करने के लिए प्रेरित किया, जिससे सबसे अधिक उल्लेख की सूची बनाना संभव हो गया। चलो उन्हें मिथक कहते हैं।
मिथक # 1: स्टाइल-घटक वैश्विक नाम स्थान की समस्याओं और शैली के टकराव को हल करते हैं
यह एक मिथक है, क्योंकि ऐसा लगता है कि कथित रूप से वर्णित समस्या अभी तक हल नहीं हुई है। हालांकि, सीएसएस मॉड्यूल्स , शैडो डोम और अनगिनत नामकरण सम्मेलनों (जैसे बीईएम ) ने समस्या का समाधान बहुत पहले कर दिया था।
स्टाइल-घटकों (बस सीएसएस मॉड्यूल की तरह) एक व्यक्ति से नामकरण जिम्मेदारी के मुद्दे को हटा देता है। गलतियाँ करना मानव स्वभाव है, कंप्यूटर अक्सर गलतियाँ करते हैं।
अपने आप से, यह स्टाइल-घटकों का उपयोग करने के लिए एक अच्छा पर्याप्त कारण नहीं है।
मिथक 2: स्टाइल-घटकों का उपयोग करने से अधिक कॉम्पैक्ट कोड प्राप्त करना संभव हो जाता है।
इसके समर्थन में अक्सर एक उदाहरण देते हैं:
<TicketName></TicketName> <div className={styles.ticketName}></div>
सबसे पहले, यह कोई फर्क नहीं पड़ता। अंतर नगण्य है।
दूसरे, यह सच नहीं है। वर्णों की कुल संख्या शैली के नाम पर निर्भर करती है।
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
शैलियों को बनाने के लिए भी यही बात लागू होती है, जिसे हम इस लेख में बाद में देखेंगे।
(मिथक 5: स्टाइल-कलपुर्जे घटकों के सशर्त स्टाइल की सुविधा देते हैं)। स्टाइल-घटक केवल सबसे बुनियादी घटकों के मामलों में संक्षिप्तता में जीतता है।
मिथक 3. स्टाइल वाले घटकों का उपयोग करने से आप शब्दार्थ के बारे में अधिक सोचते हैं।
मूल संदेश स्वयं त्रुटिपूर्ण है। स्टेलाइज़ेशन और शब्दार्थ विभिन्न समस्याएं हैं और विभिन्न समाधानों की आवश्यकता होती है। उदाहरण के लिए पढ़ें, यह एडम मोर्स (mrmrs) है ।
हालांकि, विचार करें:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
शब्दार्थ मार्कअप के लिए सही टैग के उपयोग से संबंधित है। क्या आप जानते हैं कि इस तरह के कंपोनेंट को रेंडर करने के लिए HTML टैग्स का क्या इस्तेमाल किया जाएगा? नहीं, आप नहीं जानते।
की तुलना करें:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
मिथक 4: शैलियों का विस्तार करना आसान है।
की तुलना करें:
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
अद्भुत! लेकिन आप CSS में भी ऐसा कर सकते हैं (या CSS मॉड्यूल कंपोजिशन का उपयोग कर सकते हैं, साथ ही SASS इनहेरिटेंस मिक्सिन @extend)।
button { padding: 10px; } button.tomato-button { color: #f00; }
और सरल पहला विकल्प?
मिथक 5: घटकों की सुस्पष्ट सशर्त स्टाइलिंग
विचार यह है कि आप सहारा के लिए तत्वों का उपयोग कर सकते हैं, उदाहरण के लिए:
<Button primary /> <Button secondary /> <Button primary active={true} />
यह प्रतिक्रिया में समझ में आता है। अंत में, घटक व्यवहार को सहारा के माध्यम से नियंत्रित किया जाता है। क्या यह शैलियों के लिए सीधे मानों को बांधने के लिए समझ में आता है? हो सकता है कि। लेकिन आइए ऐसे घटक के कार्यान्वयन को देखें:
styled.Button` background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'}; color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'}; opacity: ${props => props.active ? 1 : 0}; `;
जावास्क्रिप्ट का उपयोग करके सशर्त शैली बनाना संभावनाओं का एक टन प्रदान करता है। हालांकि, इसका मतलब यह भी है कि शैलियों की व्याख्या करना अधिक कठिन होगा। सीएसएस के साथ तुलना करें:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
इस मामले में, सीएसएस छोटा है (229 वर्ण बनाम 222) और समझने के लिए आसान (विषय)। इसके अलावा, सीएसएस में आप एक प्रीप्रोसेसर का उपयोग कर सकते हैं और भी छोटे और समूहित परिणाम प्राप्त करने के लिए:
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
मिथक 6: कोड संगठन में सुधार होता है
कुछ लोग कहते हैं कि वे स्टाइल-घटकों को पसंद करते हैं, क्योंकि एक फ़ाइल में शैलियों और लिपियों को रखना संभव हो जाता है। आप समझ सकते हैं कि एक घटक के लिए कई फाइलें थकाऊ लग सकती हैं, लेकिन एक ही फाइल में शैलियों और लेआउट को देखना भयानक है। न केवल यह संस्करण नियंत्रण प्रणाली ट्रैकिंग परिवर्तनों को जटिल करेगा, बल्कि यह एक साधारण बटन की तुलना में अधिक जटिल किसी भी तत्व पर अंतहीन "स्क्रॉलिंग" का नेतृत्व करेगा।
यदि आपको निश्चित रूप से CSS और JavaScript को एक ही फ़ाइल में रखना है, तो css- शाब्दिक-लोडर आज़माएँ। उत्तरार्द्ध आपको अर्क-टेक्स्ट-वेबपैक-प्लगइन का उपयोग करके बिल्ड के दौरान शैलियों का निर्माण करने और सीएसएस को संभालने के लिए मानक लोडर कॉन्फ़िगरेशन का उपयोग करने की अनुमति देता है।
मिथक 7: "डेवलपर एक्सपीरियंस (DX)" शानदार हो रहा है। उपकरण बहुत बढ़िया है!
जाहिर है आपने स्टाइल-घटकों का उपयोग नहीं किया।
- यदि शैलियों के साथ कुछ गलत हुआ, तो त्रुटि के लंबे स्टैक ट्रेस के साथ पूरा एप्लिकेशन क्रैश हो जाता है। इसका विपरीत सीएसएस है, जहां शैलियों में एक त्रुटि बस तत्व के गलत प्रदर्शन को जन्म देगी।
- तत्वों में अलग-अलग वर्ग का नाम नहीं होता है, इसलिए डिबगिंग के दौरान आपको रिएक्ट एलिमेंट ट्री और देवटूल डोम ट्री के बीच अंतहीन स्विच करना होगा।
- हालांकि लाइनिंग, कोड हाइलाइटिंग, कोड पूरा करने और अन्य समान "आकर्षण" के लिए प्लगइन्स पहले से ही स्टाइल-घटकों के लिए मौजूद हैं, फिर भी वे आपके आईडीई के लिए उपलब्ध नहीं हो सकते हैं। यदि आप एक सरकारी एजेंसी में वित्त के साथ काम करते हैं, तो एक मौका है कि एटम आईडीई अनुपलब्ध होगा।
मिथक 8: सब कुछ "तेज" हो जाता है, सब कुछ "आसान" हो जाता है
- जैसा कि यह निकला, स्टाइल वाले घटकों को स्थिर में नहीं निकाला जा सकता है
CSS फ़ाइल (जैसे एक्सट्रैक्ट-टेक्स्ट-वेबपैक-प्लगइन का उपयोग करके)। इसका मतलब यह है कि ब्राउज़र स्टाइल की व्याख्या तब तक शुरू नहीं कर पाएगा जब तक कि स्टाइल-कंपोनेंट उन्हें पार्स और डोम में जोड़ न दें। - शैलियों और लिपियों को एक फ़ाइल में संयोजित करने का अर्थ है कि अलग-अलग कैशिंग संभव नहीं है।
- स्टाइल-घटकों की प्रकृति ऐसी है कि वे सभी अतिरिक्त एचओसी में लिपटे हुए हैं। और यह प्रदर्शन में अनावश्यक कमी है। इसी दोष के कारण प्रतिक्रिया-सीएसएस-मॉड्यूल बंद हो गया और बेबल-प्लगइन-प्रतिक्रिया-सीएसएस-मॉड्यूल की उपस्थिति हुई।
- एक ही HOC के कारण, सर्वर-साइड रेंडरिंग के परिणामस्वरूप काफी बड़े दस्तावेज़ मार्कअप आकार मिलते हैं।
- यहां तक कि कीफ़्रेम के बजाय गतिशील शैलियों का उपयोग करते हुए चेतन घटकों के लिए भी प्रयास न करें।
मिथक 9: "उत्तरदायी" घटकों को विकसित करने की संभावना है
हम पर्यावरण पर आधारित एक घटक को स्टाइल करने की क्षमता के बारे में बात कर रहे हैं, उदाहरण के लिए, मूल कंटेनर का आकार, वारिस की संख्या आदि।
सबसे पहले, स्टाइल-घटकों का इससे कोई लेना-देना नहीं है।
यह परियोजना के दायरे से परे है। इस मामले में, अतिरिक्त प्रोसेसर भार से बचने के लिए घटक शैली मूल्यों को सीधे सेट करना बेहतर है।
हालांकि, एक मिनट रुको!
अधिकांश, यदि इन सभी समस्याओं को लंबे समय तक या तो समुदाय द्वारा, प्रतिक्रिया में या स्टाइल-घटकों में परिवर्तन द्वारा हल नहीं किया जा सकता है। लेकिन क्यों? सीएसएस पहले से ही व्यापक रूप से समर्थित है, एक ठोस समुदाय है और ... यह सिर्फ काम करता है।
लेकिन आपको हमेशा CSS-in-JavaScript या स्टाइल-घटकों का उपयोग करने से बचना चाहिए।
ऐसा कुछ है जो स्टाइल-घटकों को एक अच्छा पुस्तकालय बनाता है - यह सबसे अच्छा क्रॉस-प्लेटफ़ॉर्म समर्थन है।
बस गलत अभ्यावेदन के आधार पर स्टाइल-घटकों का उपयोग न करें।
इच्छुक पार्टियों से राय की एक जोड़ी।
हमारी परियोजना में स्टाइल-घटकों का उपयोग करते हुए, हमने पाया कि कुछ शैली नियम हैं जिन्हें स्टाइल-घटकों में लागू करना मुश्किल है; उदाहरण के लिए, एक पृष्ठ (मार्जिन या प्रदर्शन संपत्ति) पर तत्वों के प्लेसमेंट को नियंत्रित करने वाले नियम। इसे मानकीकृत करना मुश्किल था, इसलिए हमें अभी भी तत्वों की धारा में घटकों को रखने के लिए सरल सीएसएस पर बहुत अधिक निर्भर रहना पड़ा।
... हालांकि स्टाइल-घटकों का उपयोग करने में कठिनाइयां थीं, पुस्तकालय ने हमें कोड आधार को कम करने में मदद की।
( "सीएसएस विकास: सीएसएस, एसएएमएस, बीईएम और सीएसएस से - स्टाइल-घटकों के लिए मॉड्यूल" पर टिप्पणी)
... सीएसएस का कोई विकास यहाँ साधन विकसित नहीं है।
मेरी राय में, टाइपसेटिंग लेआउट में लगे होने पर कोई समस्या नहीं है, और प्रोग्रामर प्रोग्रामिंग में लगा हुआ है।
लेकिन जब प्रोग्रामर टाइप करने में लगे होते हैं, तो यह पूरा चिड़ियाघर शुरू हो जाता है, जो आगे समर्थन के साथ SIMPLICITY के बजाय एक अतिरिक्त सिरदर्द देता है।
...
शुद्ध सीएसएस में लिखें, और उपकरण को एक नाम स्थान और एक कलेक्टर की भूमिका दें - फिर सभी खुश होंगे ...
और अंत में, लेखक को एक शब्द:
गजस कुइजिनास: - तो क्या, सब के बाद, उपयोग करने के लिए?