Material-ui: [आरएफसी] स्टाइल-घटकों में माइग्रेट करें

@kybarg उस मुद्दे को खोलने के लिए धन्यवाद! CSS-in-JSS एक गतिशील क्षेत्र है, अतीत में हमारे द्वारा किए गए विकल्प अब मान्य नहीं होंगे क्योंकि समस्याएं और समाधान बदलते हैं।

अतीत में स्टाइल-घटक क्यों नहीं?

हम JSS का चयन करने से पहले उपलब्ध विभिन्न स्टाइलिंग समाधानों की तुलना करते रहे हैं।

हमने निम्नलिखित कारणों से स्टाइल-घटकों का चुनाव नहीं किया:

• अमूर्त की लागत। css-in-js-perf-tests एक अच्छा संसाधन है, स्टाइल-घटक आंतरिक रूप से ग्लैमर का उपयोग करते हैं।
  
  
  
  • 126 kb JSS के लिए 22 kb से अधिक अनज़िप किया गया
  
  
  • पहली बार पेंट करने का समय धीमा है। https://github.com/MicheleBertoli/css-in-js के समकक्ष डेमो पर पहली बार पेंट करने के समय की तुलना करें, JSS 40% बेहतर प्रदर्शन करता है।
  
  
• क्लासनाम और CSS डीप सिलेक्टर पावर को एक्सपोज़ करने से परफॉर्मेंट इम्प्लीमेंटेशन की अनुमति मिलती है। उदाहरण के लिए <Grid /> : #6010 के साथ।
• कोई सर्वर-साइड रेंडरिंग संगामिति संभव नहीं है। यह शैलियों को इकट्ठा करने के लिए सिंगलटन पर निर्भर है, जबकि जेएसएस प्रत्येक अनुरोध पर शैलियों को इकट्ठा करने के लिए एक नया उदाहरण तुरंत चालू करता है। भाप लेना वास्तव में सीमित है।

दरअसल, जब @nathanmarks ने इनलाइन-शैली से दूर जाने पर काम करना शुरू किया तो स्टाइल-कंपोनेंट्स एक चीज़ (मौजूदा) भी नहीं थे।

तुलना तालिका

वैश्विक सीएसएस का समर्थन करता है

https://github.com/cssinjs/jss-global के साथ आप सामान लिख सकते हैं जैसे

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

ओवरराइड करना आसान

यह कैसे आसान नहीं है? सामग्री-यूआई पक्ष हमारे पास एक पूर्वनिर्धारित इंजेक्शन ऑर्डर टेबल है। उपयोगकर्ता-भूमि पर, वे कामोत्तेजक का उपयोग कर सकते हैं जो महान एफ़्रोडाइट ओवरराइड एपीआई को लागू करते हैं।

कोई आवरण घटक नहीं

हमारे पास सामग्री-यूआई पक्ष पर कोई रैपर घटक नहीं है। हम withStyles का उपयोग कर सकते थे लेकिन हम प्रदर्शन के कारण नहीं करते हैं। हम संदर्भ कार्यान्वयन को सारगर्भित करने के लिए उस उच्च-क्रम के घटक को उपयोगकर्ताओं के सामने उजागर करते हैं।

थीम

हम आंतरिक रूप से जेएसएस-थीम-रिएक्टर का उपयोग करते हैं। JSS एक निम्न-स्तरीय API को उजागर कर रहा है जो इसे संभव बनाता है।

प्रतिक्रियात्मक समर्थन

यह एक अच्छी बात है, प्रतिक्रिया-के-शैली एपीआई काफी दिलचस्प है। ऐसा कुछ है जिसे हम सुधार सकते हैं!

भविष्य

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

• सामग्री-यूआई किसी भी स्टाइलिंग समाधान के साथ कम युग्मित है
• स्टाइल-घटकों / एफ़्रोडाइट/... का उपयोग करने वाले उपयोगकर्ता आंतरिक रूप से उपयोग किए जाने वाले जेएसएस ओवरहेड को बचा सकते हैं।

प्रतिक्रिया-टूलबॉक्स उस पथ का अनुसरण कर रहा है। मेरी एकमात्र चिंता इसके द्वारा जोड़े जा रहे ओवरहेड के साथ होगी। मेरा मतलब है, क्या यह इसके लायक है?

मैं लूप में @kof और @mxstbr जोड़ रहा हूं।

@kybarg असल में, मैं पूरी तरह से समझ नहीं पा रहा हूं कि आप क्या सुझाव दे रहे हैं।
जैसा कि आपके प्रश्न से पता चलता है, हम react-jss का उपयोग नहीं कर रहे हैं।

जब आप कहते हैं कि हम, क्या आप उपयोगकर्ताओं या सामग्री-यूआई के बारे में बात कर रहे हैं?

मेरे अंक हैं:

• styled-components जेएसएस कोर की तुलना में एक उच्च स्तरीय पुस्तकालय है, आप निश्चित रूप से इसे अपनी एप्लिकेशन परत में उपयोग कर सकते हैं।
• ऊपर दी गई तुलना तालिका प्रतिक्रिया-जेएसएस के बारे में है, जेएसएस कोर के बारे में नहीं है और मैक्स की व्यक्तिपरक राय है। यह आंशिक रूप से सत्य नहीं है और आंशिक रूप से केवल कुछ विशिष्ट दृष्टिकोण से एक नज़र है जिसे हम तालिका से नहीं देखते हैं।
• हम अधिक कुशल गतिशील स्टाइल के लिए गतिशील नियमों के प्रतिपादन पर काम कर रहे हैं, जेएसएस-थीम-रिएक्टर अभी पहले से ही काम करता है, यह सिर्फ एक अनुकूलन का मामला है, जो शायद एमयूआई के लिए बहुत प्रासंगिक नहीं है।
• एमयूआई आंतरिक रूप से जो उपयोग करता है वह अंतिम उपयोगकर्ता के लिए पूरी तरह से चिंता का विषय होना चाहिए। उपयोगकर्ता को जो कुछ भी करने की ज़रूरत है वह यह जानने के बिना भी संभव होना चाहिए कि एमयूआई आंतरिक रूप से क्या उपयोग कर रहा है या कम से कम इसके कम या ज्यादा नियमित cssinjs सिंटैक्स थीमिंग के लिए।
• हमें उपयोग के मामलों को प्राप्त करने की आवश्यकता है एमयूआई अभी समर्थन नहीं करता है और उन्हें हल करता है। मुझे एकीकरण प्रक्रिया में मदद करने और गटर पर उपलब्ध होने में हमेशा खुशी होती है।
• वैसे भी प्रतिक्रिया-मूल समर्थन क्या है? क्या यह वेब प्लेटफॉर्म का सिर्फ एक सबसेट नहीं है? यदि ऐसा है तो यह सिर्फ काम करना चाहिए, अन्यथा मुझे बताएं कि प्रतिक्रिया-मूल का समर्थन करने के लिए जेएसएस को क्या करने में सक्षम होना चाहिए, यहां मुद्दा है ।

वह तालिका वास्तव में बहुत ही व्यक्तिपरक है और मेरे अपने अनुभव पर आधारित है। FWIW, styled-components किसी भी तीसरे पक्ष के घटक पुस्तकालय के साथ काम करता है:

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

यह तब तक काम करता है जब तक घटक className प्रोप को आंतरिक रूप से कुछ DOM नोड से जोड़ते हैं:

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

वैसे भी प्रतिक्रिया-मूल समर्थन क्या है? क्या यह वेब प्लेटफॉर्म का सिर्फ एक सबसेट नहीं है?

नहीं, यह इतना आसान नहीं है जेएसएस में समर्थन जोड़ना मुश्किल नहीं होना चाहिए, क्योंकि आपको केवल स्टाइल ऑब्जेक्ट को StyleSheet.create() तक पास करना है। CSS स्ट्रिंग्स को काम करने के लिए styled-components की ओर से थोड़ा और प्रयास करने की आवश्यकता है।

मैं कुछ समय से @javivelasco से बात कर रहा हूं और प्यार करता हूं कि वह react-toolbox के साथ कहां जा रहा है। उनका कार्यान्वयन अद्भुत है, और मुझे यह देखना अच्छा लगेगा कि सभी तृतीय पक्ष घटक पुस्तकालय इसे अपनाते हैं। उसे पिंग कर रहा हूं ताकि वह यहां अपने विचारों के साथ झंकार कर सके!

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

पूरी तरह से असंबंधित, इस मुद्दे पर एक एपीआई के लिए अपने विचारों के साथ टिप्पणी करने पर ध्यान दें जो ऐसा होने की अनुमति देगा? हमने तय नहीं किया है कि हम क्या करने जा रहे हैं, इसलिए आपके इनपुट की बहुत सराहना की जाएगी।

नमस्ते, मैंने इस बारे में जिटर में पूछताछ की। दूसरों की राय जानने के लिए, मैं इसे यहाँ भी पोस्ट करूँगा:

मुझे पता है कि सामग्री-ui _next_ एक कस्टम जेएसएस समाधान में भारी निवेश किया जाता है।
क्या किसी ने स्टाइल-घटकों पर जेएसएस का उपयोग करने का कोई गंभीर लाभ खोजा है?

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

स्टाइल-कॉम्प में प्रत्येक घटक पहले से ही स्टाइल है इसलिए शैलियों को पारित करने की कोई आवश्यकता नहीं है। और आप ऐसे प्रॉप्स पास करते हैं जिनका मूल्यांकन एक अलग शैली का निर्माण करने के लिए किया जा सकता है
कोई सेटअप नहीं (createJss)
कोई प्लगइन्स नहीं (उपसर्ग)
कोई JSON डीएसएल नहीं

किसी को यह धागा बंद करना होगा।

@rainice jss में डेकोरेटर नहीं हैं, एक HOC प्रतिक्रिया-jss का कार्यान्वयन विवरण है और यहाँ इसका उपयोग नहीं किया जाता है।

इसे क्यों बंद किया जाना चाहिए? यह एक समझदार चर्चा है IMO

क्योंकि यहां अंतिम उपयोगकर्ता आधारित सामग्री (लिबर मेंटेनर नहीं) अत्यधिक सतही है और यह समझ में आता है क्योंकि उन्होंने जो भी उपयोग किया है उसके पीछे कोड की एक भी पंक्ति नहीं पढ़ी है।

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

उम्मीद है कि लोग इतने परिपक्व हैं कि बंद थ्रेड पर पोस्ट करना जारी नहीं रखेंगे, लेकिन जरूरत पड़ने पर हम इसे लॉक कर सकते हैं।

काश हम उस धागे को कम युग्मित स्टाइलिंग समाधान के साथ आगे बढ़ा पाते!
हालाँकि, मुझे लगता है कि हमारी प्राथमिकता, अभी के लिए, घटकों के प्रवासन/समग्र सुधार को समाप्त करने के आसपास होनी चाहिए।

@mxstbr स्टाइल-घटकों के लिए धन्यवाद

यह तब तक काम करता है जब तक घटक क्लासनाम प्रोप को आंतरिक रूप से कुछ डोम नोड से जोड़ते हैं

जब मुई: अगला जारी किया जाता है तो यह आपके उपयोग मार्गदर्शिका में कहीं भी हाइलाइट करने योग्य हो सकता है। इस टिप्पणी ने मुझे बचा लिया।

IE10 के लिए फ्लेक्स शैलियाँ jss के साथ काम नहीं करती हैं, लेकिन स्टाइल-घटकों के साथ एक आकर्षण की तरह काम करती हैं

@yhaiovyi सामग्री-यूआई IE10 का समर्थन नहीं करता है।

विक्रेता उपसर्ग evtl। जेएसएस के लिए जल्द ही तय किया जाएगा, इसका मतलब यह नहीं है कि अगर आईई 10 पर कभी भी मुई का परीक्षण नहीं किया गया तो यह सभी मुद्दों को ठीक कर देगा

वैसे भी मुझे आईई 10 के साथ सीएसएस फ्लेक्स में अब तक कोई अन्य समस्या नहीं मिली है

ऐसा लगता है कि स्टाइल घटकों के साथ सामग्री UI शैलियों को ओवरराइड करने के लिए हमारे पास 3 तरीके हैं (आसान हो सकता है, लेकिन सब कुछ फूल नहीं है)। यहाँ मेरा सार है।

आप कोड की कुछ पंक्तियों के साथ स्टाइल-घटक API भी प्राप्त कर सकते हैं: https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

आप स्टाइल-जेएसएस का भी उपयोग कर सकते हैं, उदाहरण: https://codesandbox.io/s/32mvjyjyxq

सामान्य रूप से जेएसएस के साथ एकमात्र नकारात्मकता कोड संपादकों में स्वत: पूर्णता की कमी है, जैसा कि यहां भी कहा गया है , लेकिन लाभ हैं, स्टाइल-घटकों की तरह जेएस को जेएस को पार्स करना थोड़ा अधिभार है

संपादित करें: बस ऊपर संदर्भित मुद्दे पर ध्यान दिया, दिलचस्प

मुई का संदर्भ और withStyles एचओसी कोर प्रतिक्रिया-जेएसएस और स्टाइल-जेएसएस थीमप्रोवाइडर https://codesandbox.io/s/32mvjyjyxq (मैंने Typography डालने का प्रयास किया) के साथ अच्छा नहीं लगता है।

मुझे आश्चर्य है कि बाद में (पोस्ट v1 मुझे लगता है) यह src/styles/withStyles और MuiThemeProvider + JSSProvider डबल परत को सरल बनाने के लायक नहीं होगा, और कुछ और सरल है जैसे प्रतिक्रिया-जेएसएस और स्टाइल-जेएसएस कैसे हैं

इसके लिए पूरी तरह से!

मार्च 13, 2018 13:55 को, "सिरिल ऑबर्टिन" नोटिफिकेशन @github.com ने लिखा:

क्या कष्टप्रद है मुई का संदर्भ और स्टाइल्स के साथ एचओसी खेलने के लिए प्रतीत नहीं होता है
कोर प्रतिक्रिया-जेएसएस और स्टाइल-जेएसएस थीमप्रोवाइडर के साथ अच्छी तरह से
https://codesandbox.io/s/32mvjyjyxq

मुझे आश्चर्य है कि अगर बाद में (पोस्ट v1 मुझे लगता है) यह सरल करने के लायक नहीं होगा
src/styles/withStyles और MuiThemeProvider + JSSProvider डबल लेयर

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

स्टाइल-घटकों की तरह जेएस को पार्स करना थोड़ा अधिक अधिभार है

जैसे सीएसएस में ऑब्जेक्ट्स को पार्स करना है: विंक: पार्सिंग स्ट्रिंग्स एक ही गति के बारे में है, यह ईमानदारी से कोई फर्क नहीं पड़ता। https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

समाधान | सीएसएस का प्रयोग करें | इनलाइन-शैलियों का प्रयोग करें | माउंट टाइम (एमएस) | पुन: प्रस्तुत करने का समय (एमएस)
:--- | :--- | :--- | :--- | :---
...
स्टाइल-घटक | + | - | 182 | 146.84
स्टाइल-घटक-डीकपल-सेल | + | - | 213.53 | 152.39
...
प्रतिक्रिया-जेएसएस | + | - | 198.97 | 297.74

@mxstbr रनटाइम पर जेएस में लिखा गया एक पूर्ण सीएसएस पार्सर निश्चित रूप से एक कीमत है। वह बेंचमार्क इसकी लागत को नहीं माप रहा है।

रनटाइम पर जेएस में लिखे गए एक पूर्ण सीएसएस पार्सर की निश्चित रूप से कीमत है।

ज़रूर, लेकिन एक पूर्ण CSS पार्सर से अधिक नहीं जो स्ट्रिंग्स के बजाय ऑब्जेक्ट्स को हैंडल करता है। उस सीएसएस पार्सर्स के ऊपर जो वास्तविक सीएसएस स्ट्रिंग्स पर काम करते हैं, उन्हें लंबे समय तक अनुकूलित और एक्सप्लोर किया गया है, ऑब्जेक्ट्स को संभालने वाले लोगों के साथ बहुत कम। :शरमाना:

मैं आपके पार्सर बनाम बूटस्ट्रैप सीएसएस के साथ एक ऑब्जेक्ट के रूप में बूटस्ट्रैप सीएसएस बेंचमार्किंग के बारे में उत्सुक हूं, स्टाइलिस, हमारे पार्सर के साथ, लेकिन मुझे पूरा यकीन है कि अंतर सबसे अच्छा होगा।

मैं आपके पार्सर बनाम बूटस्ट्रैप सीएसएस के साथ एक ऑब्जेक्ट के रूप में बूटस्ट्रैप सीएसएस बेंचमार्किंग के बारे में उत्सुक हूं, स्टाइलिस, हमारे पार्सर के साथ, लेकिन मुझे पूरा यकीन है कि अंतर सबसे अच्छा होगा।

हां, यह एक उपयुक्त बेंचमार्क होगा, मैंने थोड़ा परीक्षण किया है, वस्तुओं के साथ काम करना बहुत तेज है, जैसे 10-20x तेज।

लेकिन फिर, यह इस बात पर निर्भर करता है कि आप कौन से jss प्लगइन्स शामिल करेंगे, हमारे पास बहुत सारे वाक्यात्मक चीनी प्लगइन्स हैं।

साथ ही टीबीएच. इससे कोई फर्क नहीं पड़ता कि हम सभी आईएसटीएफ में चले जाते हैं।

मैंने थोड़ा परीक्षण किया है, वस्तुओं के साथ काम करना बहुत तेज है, जैसे 10-20x तेज।

निश्चित रूप से लेकिन 10ms (यही कारण है कि स्टाइलिस पूरे बूटस्ट्रैप स्टाइलशीट को पार्स करने में कितना समय लेता है) बनाम किसी एप्लिकेशन के पूरे सीएसएस को पार्स करने के 1ms चीजों की भव्य योजना में कोई फर्क नहीं पड़ता, आप जानते हैं? यह किसी का ऐप नहीं बनाएगा या तोड़ेगा नहीं।

बहरहाल, आवश्यकता से अधिक सूचनाओं के साथ इस मुद्दे में लोगों को परेशान करना बंद करें।

बीटीडब्ल्यू। यह बेंचमार्क अधिक सटीक प्रतीत होता है: http://necolas.github.io/react-native-web/benchmarks/ मुझे यकीन नहीं है कि यह पहले पार्स के बाद कैश पर निर्भर नहीं है।

@mxstbr जबकि यह मुद्दा अब बंद है, थोड़ी स्वस्थ प्रतिस्पर्धा सभी के लिए अच्छी है। किसी भी समय वापस आएं - यदि कोई मुद्दा चर्चा के लिए उपयुक्त स्थान नहीं है तो आप हमें गटर चैट में ढूंढ सकते हैं।

यह मामला एक साल से ज्यादा पुराना है। दोस्तों, कृपया इस पर टिप्पणी करना बंद करें। हम चर्चा को नए सिरे से आगे बढ़ा सकते हैं। चर्चा शुरू होने के बाद से बहुत कुछ बदल गया है।

लेकिन आइए लॉकिंग मुद्दों से बचने की कोशिश करें। हमें बेहतर निर्णय लेने के लिए यथासंभव अधिक से अधिक फीडबैक एकत्र करते रहने की आवश्यकता है।

मुझे लगता है कि इसे स्पष्ट रूप से संप्रेषित करने के लिए एक उपकरण के रूप में लॉकिंग इश्यू ठीक है, इससे किसी को ठेस नहीं पहुंची और न ही अभिव्यक्ति की स्वतंत्रता ली गई। इस मामले में यह वास्तव में ठीक है।

मैं और प्रतिक्रिया एकत्र करने के लिए फिर से खोल रहा हूं, मैं उत्सुक हूं कि क्या यह कुछ ऐसा है जिसमें लोग अभी भी रूचि रखते हैं:

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

1. बंडल का आकार । हम चाहते हैं कि लोग इसके लिए 20 KB gzipped भुगतान किए बिना एकल घटक का उपयोग करने में सक्षम हों। रैंकिंग के अनुसार:
   
   
   
   1. भावना इस दिशा में सबसे अच्छा उम्मीदवार है: 10kB gzipped . हालाँकि, इसका उपयोग बहुत कम लोग करते हैं। अगर आप डाउनलोड के आंकड़ों को देखें, तो 80% स्टोरीबुक से आता है ?
   
   
   2. स्टाइल-घटकों का वजन लगभग 16 KB gzipped . उसका फायदा उन लोगों की संख्या से आता है जो इसका इस्तेमाल करते हैं। शायद 20% प्रतिक्रिया उपयोगकर्ता?
   
   
   3. जेएसएस एक प्रतिक्रिया आवरण वजन के साथ लगभग 15 केबी gzipped। यदि आप डाउनलोड के आंकड़ों को देखें, तो बहुत अधिक उपयोग सामग्री-यूआई से होता है।
   
   
2. प्रदर्शन । हम चाहते हैं कि लोग हमारे घटकों को अनुकूलित करने में सक्षम न हों। उन्हें जितनी जल्दी हो सके होना चाहिए। मैं जो बेंचमार्क कर सकता था वह निम्नलिखित रैंकिंग देता है:
   
   
   
   1. भावना
   
   
   2. जेएसएस
   
   
   3. स्टाइल-घटक
   
   
3. अनुकूलन एपीआई । एक प्रकार को अनुकूलित करना आसान होना चाहिए, एक नेस्टेड तत्व को अनुकूलित करना आसान होना चाहिए, एक नया संस्करण जोड़ना आसान होना चाहिए। अभी, हमारे पास classes API, एक theme.overrides API और वैश्विक नियतात्मक वर्ग नाम रखने की क्षमता है।
4. इंटरऑपरेबिलिटी । !important का उपयोग करना कोई समाधान नहीं है।
5. आरटीएल समर्थन

मैंने केवल स्टाइल-घटकों, भावनाओं और जेएसएस का उल्लेख किया है, लेकिन वे अलग-अलग विकल्प हैं: लिनेरिया, एसएएसएस, आदि।

मेरा मानना ​​​​है कि यह निम्नलिखित दो मुद्दों को जोड़ने लायक हो सकता है क्योंकि वे निर्णय को प्रभावित करने में मदद कर सकते हैं जब आपके पास CSS-in-JS लाइब्रेरी पर काम करने का समय होगा जो कि सामग्री-यूआई द्वारा उपयोग किया जाता है:

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  संक्षेप में, ये दो मुद्दे देव अनुभव को प्रभावित करने वाले जेएसएस की असंगति को कवर करते हैं।

@ ओ-अलेक्जेंड्रोव क्या जेएसएस स्टाइल-घटकों की तुलना में एक ही रणनीति का पालन कर रहा है? मुझे आपकी बात समझ में नहीं आ रही है। क्या आप स्पष्ट कर सकते हैं? क्या फर्क पड़ता है? यह कैसे बेहतर या लायक है?

@oliviertassinari
पिछले संदेश में, मैं styled-components के बारे में कुछ नहीं कहता, सिवाय इसके कि मैं styled-components या किसी अन्य सीएसएस-इन-जेएस पुस्तकालय के उपयोग का मूल्यांकन करने के विचार का स्वागत करता हूं जिसमें इसका सही संतुलन होगा:

• देव अनुभव (परिचित और लचीलापन, आगे योगदान, देवों द्वारा वास्तविक उपयोग, आदि)
• प्रदर्शन

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

व्यक्तिगत रूप से, मुझे पसंद है:

• अधिक व्यापक समुदाय अपनाने के लिए जेएसएस पर स्टाइल-घटक ।
  मेरा मानना ​​है कि समुदाय द्वारा अपनाना एक महत्वपूर्ण पहलू है जिस पर सामग्री यूआई को विचार करना चाहिए।

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

बंडल का आकार

styled-components में 12.3kB में @5.0.0-beta.8 में सुधार हुआ है।

अनुकूलन एपीआई

अगर वे https://github.com/styled-components/styled-components/pull/2625 या तो पैकेज या बाहरी पैकेज में पेश करते हैं, तो मेरा मानना ​​​​है कि एपीआई मुई को समानता देता है क्योंकि इसमें गैर-स्टाइल-घटक एपीआई की कमी है जिसे कभी-कभी हमें आवश्यकता हो सकती है , विशेष रूप से विरासत प्रणालियों में, लेकिन मुझे नहीं लगता कि आपको मुई में ही उस एपीआई की आवश्यकता होगी।

उसके बाहर,

मुझे यकीन नहीं है कि आप कौन सी जानकारी एकत्र करना चाहेंगे क्योंकि मेरे व्यक्तिगत अनुभव styled-components से हमें वे सुविधाएँ मिलती हैं जिनकी हमें आवश्यकता होती है।

इंटरऑपरेबिलिटी।

इस संदर्भ में आपके लिए यह क्या है? जहां तक ​​​​मुझे पता है आप किसी भी अन्य ढांचे के रूप में चीजों को styled-components में ओवरराइड कर सकते हैं।

आरटीएल समर्थन

क्या यह इस पर आधारित नहीं है कि हम घटकों को कैसे कोडित करते हैं? इसके styled-components या किसी CSS-in-JS लाइब्रेरी को वास्तव में क्या पेशकश करनी है?

मेरे विचार

स्पीड

यह अन्य समाधानों की तुलना में धीमा हुआ करता था लेकिन योगदानकर्ताओं के समर्थन और अद्भुत प्रयास ने इसे उस बिंदु तक पहुंचा दिया जहां यह जेएसएस से भी तेज होता जा रहा है।

आकार

v5 और भी दुबला होता जा रहा है जैसे मैंने कहा 12.3kB से 16.2kB जो इस विषय पर उनके प्रयास का प्रतिनिधित्व करते हैं।

सुपरिचय

लोग एपीआई से परिचित हैं क्योंकि यह सबसे लोकप्रिय है, वास्तव में, अधिकांश लोग वास्तविक पैकेज के बजाय एपीआई का जिक्र करते हुए styled-components कहते हैं, जब हमने अधिकांश भाग के लिए styled(...) ... एपीआई का उपयोग किया था।

प्रतिक्रिया मूल निवासी

यह मुई के लिए उतना ही वजन करता है जितना वेब है, लेकिन लोग इसकी वजह से styled-components को अपनाना जारी रखेंगे।

मूल समूह

मजबूत कोर टीम, आज तक 81 अंक और 14 पीआर खुले हैं, पैकेज का उपयोग करने वाले लोगों की संख्या के लिए ये अच्छे नंबर हैं।

साथ ही, @mxstbr जैसे लोग वास्तव में spectrum में पैकेज का उपयोग करते हैं, इसलिए उसके पास पैकेज का उपयोग करने का वास्तविक दुनिया का अनुभव है, जो आश्चर्यजनक है, इसका मतलब है कि वह वास्तव में जानता है कि पैकेज का उपयोग करना कैसा लगता है।

इसे ले लिया

खैर, बेहतर नहीं हो सकता https://www.styled-components.com/docs/tooling

यूआई लेखकों के लिए

आज की स्थिति में, डिज़ाइन सिस्टम घटकों के लिए styled-components को अपनाना बहुत बढ़ गया है; एटलसियन, गिटहब, ऑर्बिट और कई अन्य।

यह मुई के लिए अच्छा है क्योंकि आप अकेले नहीं होंगे, इसलिए शायद लोग पहले से ही संभावित स्थितियों से निपटते हैं जिनका आप सामना कर सकते हैं और उन्हें पता चल गया कि इससे कैसे निपटना है।

टीएल; डीआर

मैं styled-components समर्थन करता हूं।

मुझे जेएसएस पसंद है क्योंकि सीएसएस के लिए ऑब्जेक्ट सिंटैक्स मेरे लिए आसान हो गया है, कभी-कभी मैं आलसी हूं और मैं उन शैलियों को style={{styles.dialogTitle}} इनलाइन शैली के रूप में भी पास करता हूं, बाद में रिफैक्टर करना आसान है

और इसे अलग-अलग तरीकों से इस्तेमाल किया जा सकता है, स्टाइल-घटकों जैसे तत्व आवरण के साथ https://material-ui.com/styles/basics/#styled -components-api

@caub https://www.styled-components.com/docs/advanced#style -objects

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

सौभाग्य से इसके अधिकांश ट्री-शेकिंग मुद्दों को बैबेल-प्लगइन-स्टाइल-घटकों का उपयोग करके और pure: true सेट करके हल किया जाता है (देखें https://www.styled-components.com/docs/tooling#dead-code-elimination ) लेकिन अभी भी कुछ मुद्दे शेष हैं। उदाहरण के लिए:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

दूसरा यह है कि आपकी शैलियों के अंदर बाहरी सहायक फ़ंक्शन का उपयोग पेड़-हिलाने को तोड़ सकता है (जब तक कि आप उस विशिष्ट फ़ंक्शन को अनदेखा करने के लिए terser/uglify को कॉन्फ़िगर नहीं करते), उदाहरण के लिए:

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

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

@mbrowne मैं पेड़-हिलाने और स्टाइल घटकों के साथ किसी भी मुद्दे को पुन: पेश नहीं कर सका। इस मुद्दे में एक प्रतिलिपि प्रस्तुत करने योग्य उदाहरण शामिल नहीं है इसलिए मैंने इसे दोहराने की कोशिश की

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

डिफ़ॉल्ट create-react-app के साथ। MyComponent प्रोडक्शन बंडल में दिखाई नहीं देगा।

क्या यह केवल rollup के साथ समस्या है? मैं इस मुद्दे को समझने के लिए एक प्रतिलिपि प्रस्तुत करने योग्य उदाहरण की सराहना करता हूं।

@ eps1lon मुझे लगता है कि स्टाइल घटक पर स्थिर संपत्ति सेट करते समय समस्या दिखाई देती है, क्या आप इसे आजमा सकते हैं?

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbr हाँ हालांकि दोनों ही मामलों में स्टाइल-घटकों को बंडल किया गया है। डिस्प्लेनाम को MyComponent पर सेट करते समय बंडल में MyComponent शामिल नहीं था, इसमें अभी भी styled-components शामिल है। यह मूल रूप से MyComponent में किए गए कुछ भी हटा देता है, यही कारण है कि मैंने मूल रूप से इसे ठीक से पेड़-हिलाने के लिए सोचा था (बस FancyName के लिए खोजा गया था।

लेकिन इसमें अभी भी styled-components शामिल है। यहां तक ​​कि अगर आप styled कॉल को साइड-इफेक्ट्स मानते हैं तो भी मैं इस पर विचार करूंगा

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

{ OtherComponent } आयात करते समय साइड-इफ़ेक्ट मुक्त के रूप में लेकिन स्टाइल-घटक अभी भी बंडल में दिखाई देंगे (यह मैक्रो के बिना भी है)। तो या तो यह कुछ बग है या मुझे कुछ बड़ा याद आ रहा है। यहां तक ​​की

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

styled-components (https://github.com/eps1lon/styled-components-shake) शामिल होंगे।

प्रतिक्रिया-स्क्रिप्ट, वेबपैक या स्टाइल-घटकों में एक बग हो सकता है। किसी भी मामले में इन मुद्दों को डिबग करना बिना रेपो के अविश्वसनीय रूप से कठिन है।

समझ में आता है, इसकी जांच के लिए धन्यवाद।

इस उपयोग के मामले के लिए मुझे नहीं लगता कि यह मायने रखता है कि क्या styled-components बंडल में शामिल है (क्योंकि सभी घटकों को इसका उपयोग करना चाहिए), बल्कि यह कि क्या आपके द्वारा उपयोग नहीं किए जाने वाले घटक शामिल हैं-जो यह नहीं करता है ध्वनि की तरह यह मामला है, तो यह अच्छा है, है ना?

@mxstbr यह एक महत्वपूर्ण चिंता का विषय हो सकता है, हमारे पास कुछ ऐसे घटक हैं जो अस्थिर हैं, और सामान्य (मोडल, पॉपर, टेक्स्टारियाऑटोसाइज़, यूज़मीडियाक्वेरीज़, आदि), मान लें कि कोई व्यक्ति उपयोग करता है

import { Modal } from '@material-ui/core';

एसएएसएस के साथ हम +5kB gzipped वृद्धि (आज के अनुसार) की अपेक्षा करेंगे, न कि +20kB gzipped।

हालांकि, यह मानते हुए कि हम @material-ui/unstyled आगे बढ़ाते हैं, व्यवहार में, इससे कोई फर्क नहीं पड़ सकता है क्योंकि लोग इस पैकेज का उपयोग कर सकते हैं।

@ eps1lon क्षमा करें, मैंने सोचा था कि स्थिर गुणों के साथ समस्या दूसरों के लिए पुन: उत्पन्न करना आसान होगा क्योंकि ऐसा लगता है कि यह हमारे सभी घटकों को प्रभावित कर रहा है ... यह पता चला है कि इस मुद्दे को ट्रिगर करने वाली कई अलग-अलग चीजें हैं, लेकिन कम से कम में कुछ साधारण मामले यह काम करता है।

मैंने यहां एक प्रतिलिपि प्रस्तुत करने योग्य डेमो बनाया है:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

ध्यान दें कि कैसे केवल Component1 ट्री-हिलाता सही है।

अच्छी खबर यह है कि मुझे लगता है कि ये सभी मुद्दे हल करने योग्य हैं, और @mxstbr यहां बहुत व्यस्त है। मैं जल्द ही एक पीआर पर काम करूंगा जो कम से कम स्थिर प्रॉप्स मुद्दे को संबोधित करेगा (मेरे पास पहले से ही एक अलग बैबेल प्लगइन का उपयोग करके एक काम कर रहे पीओसी है जो मैंने लिखा था)।

मैंने ट्री-हिलाने वाले मुद्दों को हल करने के लिए बेबेल-प्लगइन-स्टाइल-घटकों में एक पीआर खोला। अगर यहां कोई भी इसका परीक्षण करने में मदद करना चाहता है, तो मुझे लगता है कि @mxstbr इसका स्वागत करेगा (और मैं भी निश्चित रूप से):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

हाय सब, अभी यह टिकट कहाँ है? मुझे इसमें शामिल होने और एमयूआई के लिए कुछ स्टाइल घटकों को लिखने में खुशी होगी यदि यह वास्तव में वह दिशा है जो परियोजना v5 में बढ़ रही है

मुझे लगता है कि जब तक हम इसे एक बार में नहीं करना चाहते (मुझे संदेह है कि हम ऐसा चाहते हैं)। हमें या तो स्टाइल-घटकों को जेएसएस से थीम पढ़ना शुरू करना चाहिए या जेएसएस स्टाइल घटकों से थीम को पढ़ना चाहिए। लक्ष्य यह होना चाहिए कि हम प्रति घटक के आधार पर शैलियों को स्थानांतरित कर सकें।

यह शायद दूसरी शाखा पर होना चाहिए। जबकि हम मास्टर पर सब कुछ एक बार में बदलना नहीं चाहते हैं, हमें शायद इसे एक बदलाव (v5 में) के साथ जारी करना चाहिए। नहीं तो यह बात और उलझ जाती है।

टिप्पणी हटाने का अनुरोध किया गया था।

हे दोस्तों, मैं भी योगदान करने के लिए तैयार हूँ... एक अलग शाखा हमारे लिए एक समझदारी की बात लगती है... चलो यह करते हैं...!

@ मकर-छह ऊर्जा के लिए धन्यवाद लेकिन एक नई शाखा आवश्यक नहीं है। हमें एक स्टाइल घटक संस्करण उत्तरोत्तर (+ जेएसएस और भावना) (v4 के दौरान अस्थिर) प्रदान करने में सक्षम होना चाहिए, और एक ही समय में अस्थिर कहानी को आगे बढ़ाना चाहिए। मेरे पास एक पीओसी है जिसे मुझे जमा करना है। स्टाइल-घटक (v5 बीटा) + डायनेमिक प्रॉप्स हमारे पास JSS और स्टैटिक स्टाइल की तुलना में थोड़ा धीमा है, लेकिन यह अभी भी स्वीकार्य होना चाहिए।

@oliviertassinari क्या कहीं हम इससे जुड़ सकते हैं? मैं किसी भी चीज़ में कूदने से पहले मुझे सही दिशा में इंगित करने के लिए एक अनुरक्षक की प्रतीक्षा कर रहा था

आप स्टाइल-घटकों पर भावना को प्राथमिकता क्यों नहीं देते? ऐसा लगता है कि इसका कारण यह है कि "[भावना] कुछ लोगों द्वारा उपयोग किया जाता है। यदि आप डाउनलोड आंकड़ों को देखते हैं, तो 80% स्टोरीबुक से आता है?", लेकिन यह गलत है। यह स्टाइल-घटकों ( तुलना ) की तुलना में अधिक उपयोग किया जाता है और मुझे नहीं पता कि 80% डाउनलोड स्टोरीबुक से क्यों आते हैं। यह स्पष्ट रूप से स्टोरीबुक की तुलना में बहुत तेजी से बढ़ रहा है।

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

यह हल्का, तेज और अधिक कार्यात्मकताएं हैं: संपत्ति अग्रेषण, टाइपस्क्रिप्ट आउट-ऑफ-द-बॉक्स (और स्टाइल-घटकों की तुलना में पूरी तरह से समर्थित), Next.js SSR आउट-ऑफ-द-बॉक्स (_app को अधिलेखित किए बिना। js और _document.js फ़ाइलें, पहली बार संभालने में मुझे एक घंटा क्या लगा)

और इसके अलावा, यह स्टाइल-घटकों की तुलना में अधिक उपयोग किया जाता है और इसमें स्पष्ट रूप से गति होती है।

@lcswillems मुझे लगता है कि हमें उन लोगों के लिए भी भावनाओं का समर्थन करना चाहिए जो इसे पसंद करते हैं। लेकिन मुझे नहीं लगता कि यह डिफ़ॉल्ट होना चाहिए।

• "हल्का": सटीक नहीं: https://bundlephobia.com/[email protected] (12.2 kB) बनाम https://bundlephobia.com/result?p=@emotion/ स्टाइल + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (साझा निर्भरता को ध्यान में रखे बिना 13.1 kB)
• "नेक्स्ट.जेएस एसएसआर आउट-ऑफ-द-बॉक्स": मुझे लगता है कि यह एक महत्वपूर्ण समस्या है, इनलाइनिंग

आपके उत्तर और मुझे सुधारने के लिए धन्यवाद।

• "हल्का": आप सही कह रहे हैं
• "नेक्स्ट.जेएस एसएसआर आउट-ऑफ-द-बॉक्स": अब मैं समझता हूं कि वे एसएसआर को आउट-ऑफ-द-बॉक्स क्यों बना सकते हैं और ऐसा करने का उनका तरीका अच्छा क्यों नहीं है।
• "स्टाइल-घटकों से अधिक उपयोग किया जाता है": मुझे यकीन नहीं है कि यह विश्वसनीय है या नहीं। लेकिन मेरा स्रोत भी विश्वसनीय नहीं हो सकता है।
• "तेज़": मैंने केवल पुराने बेंचमार्क देखे, इसलिए नहीं, मेरे पास एक नहीं है।

मेरे सामने मुख्य समस्या प्रोप फ़ॉरवर्डिंग/फ़िल्टरिंग है: https://github.com/styled-components/styled-components/issues/439 । यह मेरे साथ बहुत बार होता है और हर बार मैन्युअल रूप से फ़िल्टरिंग करने में दर्द होता है।

लेकिन आपकी टिप्पणियों के साथ, भावना कम एक अच्छा विकल्प लगती है।

"हल्का": सटीक नहीं: https://bundlephobia.com/[email protected] (12.2 kB) बनाम https://bundlephobia.com/result?p=@emotion/ स्टाइल + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (बिना लिए 13.1 kB

भावना के मामले में, सबसे अधिक संभावना है कि आप @emotion/styled पैकेज का उपयोग css प्रॉप्स + @jsx pragma के पक्ष में नहीं करेंगे। इसके अलावा आपको emotion-theming पैकेज की आवश्यकता नहीं हो सकती है, ThemeContext पहले से ही @emotion/core में शामिल है। तो यह 12.2KB बनाम 6.5KB है।

इनलाइन

बस जिज्ञासु: गैर-MUI घटकों के लिए @material-ui/styles लाइब्रेरी के उपयोगकर्ताओं के लिए इन अद्यतनों का क्या अर्थ है? मेरी कंपनी में हम इसे एक बड़े आंतरिक घटक पुस्तकालय के आधार के रूप में उपयोग कर रहे हैं, जानबूझकर इसे styled-components से अधिक चुना है, और हम इससे बहुत खुश हैं।

मैंने सोचा था कि अगर @material-ui/styles पैकेज के लिए किसी प्रकार के बहिष्करण की योजना है, तो मैं समय से पहले जांच करूंगा, ताकि मैं तदनुसार योजना बना सकूं।

वैसे भी, उन सभी बेहतरीन चीज़ों के लिए धन्यवाद जिन्हें आप प्रदान करना जारी रख रहे हैं!

@ निकजॉनसन-देव प्रतिक्रिया-जेएसएस में प्रवास सीधा होना चाहिए। क्या यह आपके संगठन के लिए काम करेगा?

@oliviertassinari मुझे लगता है कि यह संभावना है कि यह होगा। जब तक हम घटकों के सार्वजनिक एपीआई को अधिकतर समान रख सकते हैं ( classes प्रोप आधारित स्थानीय ओवरराइड, थीम में वैश्विक ओवरराइड संभव है), मुझे नहीं लगता कि यह कार्यान्वयन विवरण बदलने के लिए एक मुद्दा है।

क्या आप अनुमान लगाते हैं कि एमयूआई के और अधिक अलग होने के बाद @material-ui/styles से दूसरे स्टाइलिंग विकल्पों में माइग्रेट करने के लिए कोई आधिकारिक दस्तावेज है? पहली नज़र में मुझे react-jss में किसी भी विशेषता की कमी नहीं दिख रही है जिसका हम @material-ui/styles में लाभ उठा रहे हैं, लेकिन मुझे यकीन नहीं है कि मुझे कुछ विशेष याद आ रहा है जो एमयूआई पैकेज कर रहा है परदे के पीछे।

@ निकजॉनसन-देव हम अपनी तरफ से पूरी कोशिश करेंगे।

अगर मैं सही ढंग से समझूं तो निम्नलिखित समस्या होगी।
हमारे पास पुन: प्रयोज्य ComponentA है। हम ComponentB ComponentA उपयोग करता है।

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

ध्यान दें कि कैसे दोनों ComponentA और ComponentB में समान className='inner' वाले तत्व हैं। हम .inner तत्व को केवल ComponentB पर कैसे लक्षित करेंगे?

नमस्ते @oliviertassinari , सामग्री UI के अगले संस्करण के लिए स्टाइलिंग के पीछे की सारी सोच को साझा करने के लिए धन्यवाद।

और मटेरियल यूआई के लिए भी धन्यवाद। अभी मैं इसके ऊपर एक डिज़ाइन सिस्टम बना रहा हूँ।

styled-components अपनाने के संबंध में, ऐसा लगता है कि यह एक बना हुआ निर्णय है, और उस लक्ष्य की दिशा में काम शुरू हो चुका है।

हालांकि, मैं @croraf और @lcswillems . द्वारा की गई कुछ टिप्पणियों को साझा करता हूं

classes संपत्ति वर्तमान सामग्री UI स्टाइल से कुछ बढ़िया है।

यह एक सरल विचार है जो शैली अनुकूलन और रखरखाव में बहुत मदद करता है क्योंकि classes की टाइपिंग सार्वजनिक इंटरफ़ेस का हिस्सा है। उदाहरण के लिए, यदि मुझे कुछ अनुकूलित करने की आवश्यकता है और मैं & .Component-root जैसे चयनकर्ता का उपयोग करता हूं तो कुछ भी गारंटी नहीं है कि Component उस सीएसएस वर्ग को संस्करणों में बनाए रखेगा। कम से कम <Component classes={{root: ....}} /> होने से मुझे इंटरफ़ेस परिवर्तन के बारे में एक प्रकार की जांच त्रुटि (यदि टाइपस्क्रिप्ट का उपयोग कर रही है) मिल सकती है।

एक घटक लेखक के रूप में, मैं उन वर्गों को दस्तावेज करने का निर्णय ले सकता हूं जो सार्वजनिक (और समर्थित) हैं और दूसरों को अनियंत्रित छोड़ दें।

मैंने लगभग 2 वर्षों तक style-components उपयोग किया। यह सच है कि लोकप्रिय है और यह बहुत विकसित हुआ है। लेकिन, एमयूआई दस्तावेज उदाहरणों में, मुझे वही समस्या दिखाई देती है जिसका @croad उल्लेख करता है: वंशज चयनकर्ता का उपयोग करना & .inner बहुत नाजुक है क्योंकि आप शैलियों को उप-घटकों में प्रचारित कर सकते हैं (और मेरे अपने अनुभव से मैं कह सकता हूं यह कोई कोना मामला नहीं है... मेरे साथ ऐसा कई बार हुआ है)। दो संभावित समाधान हैं:

• &.inner का उपयोग करें और फिर हर जगह ${props.className}.inner का उपयोग करें। मैंने ऐसा कई बार किया है, और यह लिखना दर्दनाक है।
• > .inner का उपयोग करें लेकिन फिर यह घटक संरचना पर निर्भर करता है। बीच में कुछ अतिरिक्त div जोड़ें और यह टूट जाता है।

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

हालांकि, मैं आपको styled-components के बारे में इतना आश्वस्त देखता हूं कि मुझे classes प्रॉप्स का उपयोग करके शैली अनुकूलन को कैसे हल किया जाए, इसके और उदाहरण देखना अच्छा लगेगा। वर्तमान एमयूआई दस्तावेज़ों में उपलब्ध समस्याएं उन समस्याओं को साझा करती हैं जिनका मैंने ऊपर उल्लेख किया है।

क्लास प्रोप के साथ styled-components का उपयोग करने के अन्य तरीके हैं? इसके बारे में आपके क्या विचार हैं?

JSS काफी अच्छा है और उपयोग में बहुत आसान है। क्या दूर जाने का कोई मजबूत कारण है?

व्यक्तिगत रूप से मुझे लगता है कि स्टाइल-घटक एक तरह का कदम पीछे है और जेएसएस मेरे लिए इस पुस्तकालय का उपयोग ईमानदारी से शुरू करने का मुख्य कारण था।

@powerfulj आप स्टाइल-घटकों पर जेएसएस क्यों पसंद करते हैं? मुझे दोनों में से किसी एक को चुनना था और स्टाइल-घटक मेरे लिए बेहतर लगे।

@lcswillems
मुझे यह पसंद है क्योंकि मुझे लगता है कि यह एक नया घटक पेश नहीं करता है, और इसके बजाय आप केवल गुणों पर काम करते हैं। यदि आपको वास्तव में एक नए पुन: प्रयोज्य घटक की आवश्यकता है जिसे स्टाइल किया गया है तो आप इसे आसानी से JSS समाधान के साथ बना सकते हैं।

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

नकारात्मक पक्ष यह है कि यदि आपके पास कुछ CSS है (जैसे ब्राउज़र devtools से) और आपको इसे JSS में बदलने की आवश्यकता है तो आपको सिंटैक्स को समायोजित करने के लिए कुछ और समय बिताना होगा। स्टाइल-घटक के साथ यह तेजी से आगे बढ़ता है।

बस इस मुद्दे के बारे में अपनी खोज साझा करने के लिए।
मैंने कुछ डेमो को स्टाइल-घटकों में माइग्रेट करने का प्रयास किया जैसा कि # 16947 द्वारा आवश्यक था। समस्या डिफ़ॉल्ट विषय के साथ है। makeStyles उन विकल्पों को स्वीकार करता है जहां डिफ़ॉल्ट थीम को पारित किया जा सकता है। makeStyles रैपर है जो defaultTheme प्रदान करेगा। फिर useStyles हुक जांच करेगा कि क्या ThemeProvider थीम प्रदान करता है, और यदि नहीं, तो defaultTheme इंजेक्ट करें।

ऐसा लगता है कि स्टाइल-घटकों में ऐसी कोई कार्यक्षमता नहीं है। ThemeProvider के अभाव में defaultTheme को केवल .attrs विधि से इंजेक्ट किया जा सकता है। हम makeStyles रैपर के समान कुछ बना सकते हैं

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

लेकिन .attrs विधि केवल ThemeProvider द्वारा प्रदान की गई थीम को अधिलेखित कर देगी यदि कोई हो। और मैं वर्तमान में नहीं जानता कि इस समस्या को कैसे हल किया जाए।

एक और मुद्दा यह है कि makeStyles जेएसएस-प्लगइन-डिफॉल्ट-यूनिट प्रीसेट का उपयोग करता है और ऐसा लगता है कि स्टाइल-घटक नहीं हैं। इसलिए स्टाइल-घटक px को spacing() फ़ंक्शन के वापसी मूल्य में नहीं जोड़ते हैं।
अंतिम मुद्दे का संभावित समाधान स्टाइल-जेएसएस का उपयोग करना है, न कि स्टाइल-घटकों का।

आपके विचार/सुझाव यहां पाकर मुझे खुशी हो रही है।

@ fyodore82 .attrs एक फ़ंक्शन के रूप में काम करता है (देखें https://www.styled-components.com/docs/api#attrs), तो यह करेगा:

```जेएस
.attrs(({थीम = डिफॉल्टथीम, ...प्रोप्स}) => ({...प्रोप्स, थीम}))
````

@क्रोराफ

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

मुझे लगता है कि आपने स्टाइल-घटकों की एक बहुत अच्छी चीज को याद किया है: css प्रोप । यह आपको एक नया बनाने के बिना एक घटक में सीएसएस जोड़ने की अनुमति देता है।

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

CSS प्रोप के साथ, ध्यान दें कि CSS प्रोप वाले घटक में style विशेषता नहीं है, यह पहले से ही एक स्टाइल वाले घटक में परिवर्तित हो गया है और इसलिए इसमें class है। यदि CSS बड़ा हो जाता है और पुन: उपयोग किया जाता है, तो आप एक नया घटक भी बना सकते हैं।

नकारात्मक पक्ष यह है कि यदि आपके पास कुछ CSS है (जैसे ब्राउज़र devtools से) और आपको इसे JSS में बदलने की आवश्यकता है तो आपको सिंटैक्स को समायोजित करने के लिए कुछ और समय बिताना होगा। स्टाइल-घटक के साथ यह तेजी से आगे बढ़ता है।

मैं सहमत हूं। यही मुख्य कारण है कि मैंने इसका उपयोग नहीं किया। ऑनलाइन लिखे गए अधिकांश CSS CSS में लिखे जाते हैं, JSS में नहीं। इसलिए यदि आप StackOverflow से कुछ कोड का उपयोग करना चाहते हैं, तो आपको इसे पहले JSS में बदलना होगा, जो बहुत दर्दनाक है।

अन्य अतिरिक्त तर्क जिन्होंने मुझे स्टाइल-घटकों का उपयोग किया:

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

जेएसएस संस्करण:

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

स्टाइल-घटक संस्करण:

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

अंत में, मुझे जेएसएस का उपयोग करने का कोई फायदा नहीं मिला।

css संपत्ति बहुत अच्छी है, और मूल रूप से मेरे द्वारा बताए गए डाउनसाइड्स को हल करती है। (कॉपीकैट स्टाइल-घटक बनाते हैं: डी)

दो उदाहरणों की तुलना के संबंध में मुझे यह अधिक पठनीय नहीं लगता है और यह घटकों की संख्या को दोगुना कर देता है।

@lcswillems

एक या दूसरे समाधान के लिए बहस नहीं करना, बस अपने कुछ बिंदुओं को उठाना:

यदि आप StackOverflow से कुछ कोड का उपयोग करना चाहते हैं, तो आपको इसे पहले JSS में बदलना होगा, जो बहुत दर्दनाक है

CSS को CSS-in-JS में बदलने के लिए एक VSCode एक्सटेंशन है, हालांकि यह हमेशा पूरी तरह से काम नहीं करता है। भले ही, मैं इसे दर्दनाक नहीं कहूंगा।

आपके पास सिंटैक्स हाइलाइटिंग नहीं है

मैं इस तर्क को ठीक से नहीं समझता। यह सिर्फ एक JS ऑब्जेक्ट है, इसलिए किसी भी संपादक का सिंटैक्स हाइलाइटिंग काम करता है:

(लेकिन शायद आप कुछ और विशिष्ट खोज रहे हैं?)

दो उदाहरणों की तुलना के संबंध में मुझे यह और अधिक पठनीय नहीं लगता है। जबकि क्लासनाम प्रॉप्स की कमी यकीनन क्लीनर है, यह मुख्य JSX कोड ब्लॉक से स्पष्ट नहीं है कि क्या घटक MUI मूल घटकों को संदर्भित करते हैं, या styled() घटकों को क्रॉस-रेफरेंस किए बिना आराम करते हैं। एक बड़े घटक में इन्हें दूर किया जा सकता है।

styled() इनवोकेशन (मेरे लिए) JSS ऑब्जेक्ट की तुलना में कम पठनीय हैं (हालाँकि मेरी छवि आपको उनकी आदत है)।

@powerfulj आप स्टाइल-घटकों पर जेएसएस क्यों पसंद करते हैं? मुझे दोनों में से किसी एक को चुनना था और स्टाइल-घटक मेरे लिए बेहतर लगे।

क्योंकि मैं खुद एक टाइपस्क्रिप्ट डेवलपर हूं और मैं टाइपस्क्रिप्ट ऑब्जेक्ट में सब कुछ बनाना पसंद करता हूं। विशेष रूप से मुझे स्ट्रिंग्स से नफरत है।

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

मुझे लगता है कि लोगों ने इस बदलाव का दावा केवल इसलिए किया क्योंकि उनके पास अतीत में स्टाइल-घटक का अनुभव है। यह मुझे ऐसा महसूस कराता है जैसे "हम एक ऐसा पुस्तकालय क्यों नहीं चुनते जिससे हम परिचित हों लेकिन बिना किसी स्पष्ट लाभ के?"।

मेरे दृष्टिकोण से जेएसएस बस आसान है, हम सभी जावास्क्रिप्ट तरीकों का उपयोग करके ऑब्जेक्ट को व्यवस्थित कर सकते हैं जैसे:

{
...साझाJSS1,
...साझाJSS2,
जो भी हो
}

इसके अलावा, हमारे पास निर्बाध गतिशील थीम हैं जो प्रकारों के साथ एकीकृत हैं और हमें क्लासनाम और सीएसएस दोनों प्रकारों से सभी प्रकार के संकेत मिले हैं।

नए डेवलपर्स के लिए विशेष रूप से टाइपस्क्रिप्ट डेवलपर्स केवल JSS को पसंद करेंगे।

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

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

अधिक विवरण के लिए https://www.styled-components.com/docs/faqs#can -i-nest-rules देखें।

कोडिंग शैली वरीयताओं के बारे में चर्चा हमेशा के लिए जारी रह सकती है।

थोड़ी देर के लिए styled-components का उपयोग करने के बाद, मुझे जेएसएस दृष्टिकोण अधिक पसंद है, क्योंकि:

• जब शैलियाँ लंबी हो जाती हैं तो मैं आमतौर पर उन्हें एक अलग फ़ाइल में ले जाता हूँ।
  मैंने इसे styled-components के साथ भी किया है, और मुझे useStyles / makeStyles लिखना, पढ़ना और बनाए रखना आसान लगता है। उदा. import useStyles from './MyComp.styles' बनाम import {XStyled, YStyled,...} from './MyComp.styles' ... TS में अपनी टाइपिंग के साथ उन ...Styled विविधताओं को बनाए रखना कष्टप्रद है।
• मैं चीजों को प्रगतिशील तरीके से करता हूं: पहले मैं डिव और क्लासेस का उपयोग करके एक ड्राफ्ट के साथ शुरू करता हूं, और फिर मैं उन्हें घटकों में रिफैक्टर करता हूं। styled-components का उपयोग करते समय मैं आंतरिक कक्षाओं (जैसे @mbrowne से उदाहरण में) का उपयोग करके ऐसा करता हूं, लेकिन इसके लिए अधिक रिफैक्टरिंग कार्य की आवश्यकता होती है। मैंने उस वर्कफ़्लो के साथ काम करने के लिए useStyles दृष्टिकोण को और अधिक आरामदायक पाया।
• सीएसएस कोड पेस्ट करने के लिए टेम्पलेट अक्षर अच्छे हैं, लेकिन जब आपको थीम/प्रोप चर का उपयोग करना पड़ता है तो भयानक होता है। एक प्लगइन के साथ पेस्ट कोड समस्या को हल करना आसान है, लेकिन टेम्पलेट के अंदर चर और कार्यों के साथ संपादन शाब्दिक रूप से इतना नहीं है।

लेकिन ये मेरी निजी प्राथमिकताएं हैं, आपकी अलग हो सकती हैं।

मेरा सबसे बड़ा खुला प्रश्न परिवर्तन के बारे में है classes उपयोग।

className और आंतरिक कक्षाओं का उपयोग करने के उदाहरणों में समस्याएं हैं (मेरी पिछली टिप्पणी देखें)। css में styled-components $ प्रोप उन समस्याओं को हल करने का विकल्प नहीं है। भावना में css फ़ंक्शन के विपरीत, css प्रोप एक घटक से जुड़े होने पर निर्भर करता है (जिसका अर्थ है कि आप इसे useStyle/makeStyles/classes कोड शैली में उपयोग नहीं कर सकते हैं)।

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

एमयूआई पर वापस, मैं इस धारणा के तहत हूं कि स्टाइल घटकों को अपनाने का मतलब शैलियों को अनुकूलित करने के एकमात्र तरीके के रूप में className और आंतरिक कक्षाओं का उपयोग करना है। स्टाइलिंग पूरे ढांचे में अधिक सुसंगत हो जाती है: आप styled या css प्रोप का उपयोग कर सकते हैं, जब तक कि घटक className का उपयोग करता है, आप अच्छे हैं।

लेकिन मेरे लिए classes प्रोप को हटाना एक कदम पीछे है। वह प्रोप चेक स्टाइल कस्टमाइज़ेशन को दस्तावेज़ और टाइप करने में मदद करता है। शायद एक मध्यम रास्ता खोजना संभव है, जैसे स्टाइल-घटकों का उपयोग करना लेकिन classes के लिए समर्थन रखना (आंतरिक वर्ग हैक की आवश्यकता के बिना)। मुझे स्टाइल-घटक एपीआई में कुछ भी नहीं मिला जो उस मामले में मदद करता है। इसलिए जेएसएस की तकनीकी समस्याएं क्या हैं, इसका मूल्यांकन करना अच्छा हो सकता है। क्योंकि यदि लोकप्रियता मुख्य मुद्दा है, तो भावना भी लोकप्रिय हो रही है (देखें https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview), और यह एक तरीके के रूप में आसान हो सकता है makeStyles फिर से लिखें।

@ dfernandez-asapp आपने इस fwiw के एक छोटे से हिस्से का जवाब देते हुए कुछ उत्कृष्ट बिंदु बनाए हैं @ स्टाइल-घटक एक स्ट्रिंग के बजाय jss के समान ऑब्जेक्ट का उपयोग करने का समर्थन करते हैं https://www.styled-components.com/docs/advanced# स्टाइल -ऑब्जेक्ट्स

यद्यपि यह बहुत निराशाजनक स्टाइल-घटकों ने प्रथम श्रेणी टाइपस्क्रिप्ट समर्थन को हटा दिया है और कुल मिलाकर आपसे सहमत हैं कि यह आपके द्वारा वर्णित अन्य तरीकों से एक कदम पीछे जैसा लगता है

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

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

अधिक विवरण के लिए https://www.styled-components.com/docs/faqs#can -i-nest-rules देखें।

इसके लिए किसी प्रकार का समर्थन? या हमें हर जगह तार लगाना है?

मुझे समझ में नहीं आता कि स्टाइल-घटकों के लिए इतना प्रचार क्यों है। यह ईमानदार होने के लिए एक कदम पीछे की तरह लगता है। टाइपस्क्रिप्ट के साथ जेएसएस के टाइप किए गए सीएसएस गुण कहीं अधिक सुविधाजनक और बनाए रखने में आसान हैं, साथ ही जेएस के हिस्से के रूप में सिंटैक्स जांच भी है - कोई भी आधुनिक/कॉन्फ़िगर किया गया संपादक आपको बताएगा कि क्या आप कभी टाइपो बनाते हैं और यदि वांछित है तो ऑटो पूर्णता में भी आपकी सहायता करते हैं।

संपादित करें: यह टाइप किया गया है, नीचे दक्षिण-पाव का उत्तर देखें।

@martinjlowm ऐसा लगता है कि इसमें मेरे लिए टाइपिंग है?

देखें: https://styled-components.com/docs/advanced#style -objects

आप कहते हैं कि आप प्रचार को नहीं समझते हैं ... लेकिन मुझे वह सारी नफरत भी नहीं मिलती जो इसे मिलती है। ‍

सीएसएस स्टाइल ऑब्जेक्ट्स आईएमओ पर भावना और स्टाइल-घटक व्यापक सुधार हैं

@martinjlowm ऐसा लगता है कि इसमें मेरे लिए टाइपिंग है?

...

देखें: https://styled-components.com/docs/advanced#style -objects

आप कहते हैं कि आप प्रचार को नहीं समझते हैं ... लेकिन मुझे वह सारी नफरत भी नहीं मिलती जो इसे मिलती है। ‍

सीएसएस स्टाइल ऑब्जेक्ट्स आईएमओ पर भावना और स्टाइल-घटक व्यापक सुधार हैं

समझा! मुझे पता नहीं था कि यह इस तरह की वस्तुओं का समर्थन करता है। मेरी चिंता टेम्पलेट स्ट्रिंग्स में सीएसएस से संबंधित थी - लेकिन अगर ऑब्जेक्ट एक विकल्प हैं, तो मेरे पास इसके खिलाफ कुछ भी नहीं है!

जाहिर है, जेएसएस या तो सही नहीं है, मुझे पता है - पुन: प्रयोज्य सर्वर जेनरेट की गई चादरें एक हत्यारा विशेषता होगी - क्या स्टाइल-घटक किसी भी तरह इसका समर्थन करते हैं? क्या कोई जानता है?

अभी, सर्वर जेनरेट की गई स्टाइलशीट को हटाना बेवकूफी है और क्लाइंट को सभी शैलियों को फिर से प्रस्तुत करने के लिए मजबूर करना :(

@martinjlowm ऐसा लगता है कि इसमें मेरे लिए टाइपिंग है?
...
देखें: https://styled-components.com/docs/advanced#style -objects
आप कहते हैं कि आप प्रचार को नहीं समझते हैं ... लेकिन मुझे वह सारी नफरत भी नहीं मिलती जो इसे मिलती है। ‍
सीएसएस स्टाइल ऑब्जेक्ट्स आईएमओ पर भावना और स्टाइल-घटक व्यापक सुधार हैं

समझा! मुझे पता नहीं था कि यह इस तरह की वस्तुओं का समर्थन करता है। मेरी चिंता टेम्पलेट स्ट्रिंग्स में सीएसएस से संबंधित थी - लेकिन अगर ऑब्जेक्ट एक विकल्प हैं, तो मेरे पास इसके खिलाफ कुछ भी नहीं है!

जाहिर है, जेएसएस या तो सही नहीं है, मुझे पता है - पुन: प्रयोज्य सर्वर जेनरेट की गई चादरें एक हत्यारा विशेषता होगी - क्या स्टाइल-घटक किसी भी तरह इसका समर्थन करते हैं? क्या कोई जानता है?

अभी, सर्वर जेनरेट की गई स्टाइलशीट को हटाना बेवकूफी है और क्लाइंट को सभी शैलियों को फिर से प्रस्तुत करने के लिए मजबूर करना :(

मैं यह भी स्पष्ट करना चाहूंगा कि टैग किए गए टेम्पलेट अक्षर भी टाइप किए जा सकते हैं। टाइपस्क्रिप्ट उन्हें अमान्य होने के रूप में सही ढंग से चिह्नित करेगा और भाषा सेवा स्वतः पूर्ण सुझाव आदि प्रदान करेगी।

@ दक्षिण-पाव

सीएसएस स्टाइल ऑब्जेक्ट्स आईएमओ पर भावना और स्टाइल-घटक व्यापक सुधार हैं

मैं अभी भी उलझन में हूं कि कोई रिएक्ट डेवलपर इसमें क्यों होगा। यदि आप अपने CSS को टेम्प्लेट स्ट्रिंग्स में रखना चाहते हैं, तो आप केवल Angular का उपयोग क्यों नहीं करते हैं और अपने HTML को टेम्प्लेट स्ट्रिंग्स में भी डालते हैं? रिएक्ट की ताकत यह है कि JSX तत्व वास्तव में सिर्फ JS ऑब्जेक्ट हैं जिन्हें जांचने और बदलने के लिए आपके पास बहुत सारी शक्ति है, और वही JSS के लिए जाता है।

जेएस आंदोलन में सीएसएस को चलाने वाली पूरी बात यह है कि जेएस गतिशील चीजों को करने के लिए सीएसएस से काफी बेहतर है, और जेएस वस्तुओं की शक्ति इसका कोई छोटा हिस्सा नहीं है।

तथ्य यह है कि styled-components वस्तुओं का समर्थन करता है एक लाल हेरिंग की तरह है:

• यह उनका समर्थन करता है, लेकिन किसी कारण से "यह विशेष रूप से उपयोगी होता है जब आपके पास मौजूदा स्टाइल ऑब्जेक्ट होते हैं और धीरे-धीरे स्टाइल-घटकों में जाना चाहते हैं।" वे स्पष्ट रूप से वस्तुओं में हेरफेर करने में सक्षम होने में मूल्य नहीं देखते हैं और ऐसा लगता है कि स्टाइल ऑब्जेक्ट्स को हमेशा उनके एपीआई में द्वितीय श्रेणी के नागरिक के रूप में माना जाएगा।
• दस्तावेज़ यह स्पष्ट नहीं करते हैं कि यह वास्तविक दुनिया सीएसएस चयनकर्ताओं का समर्थन करता है जैसे जेएसएस के साथ:

{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

यहां तक ​​​​कि इमोशन शैली की वस्तुओं के मूल्य के लिए उचित सम्मान देता है और उन्हें प्रथम श्रेणी के नागरिक के रूप में मानता है:

वस्तुओं के साथ लेखन शैली एक शक्तिशाली पैटर्न है जिसे सीधे भावना के मूल में बनाया गया है।

@lcswillems आप कम करके आंक रहे हैं कि इन सभी छोटे HOCs को हर समय बनाना कितनी बड़ी परेशानी है (और यह तथ्य कि अधिकांश ऑटोइम्पोर्ट सिस्टम यह जानने के लिए पर्याप्त स्मार्ट नहीं हैं कि क्या आप @material-ui/core/Card को Card के रूप में आयात करना चाहते हैं। MuiCard (और यदि आप अभी भी हाथ से आयात विवरण लिख रहे हैं, तो आप अपना समय गंभीर रूप से बर्बाद कर रहे हैं))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

इस तरह की चीजें भयानक निर्णय थकान का कारण बनती हैं क्योंकि आपको लगातार यह तय करना पड़ता है कि प्रत्येक रैपर और लिपटे घटक का नाम कैसे रखा जाए।

यह वही है जो @ dfernandez-asapp बात कर रहा है जब वह कहता है:

(थोड़ी देर के बाद हर जगह स्टाइल एचओसी होने से बहुत अधिक अतिरिक्त काम जुड़ जाता है और मैं उन एचओसी से नफरत करने लगा ... कम से कम यह मेरा व्यक्तिगत अनुभव है)

एचओसी को मरने की बहुत जरूरत है। यह एक अप्रचलित पैटर्न है। उदाहरण के लिए, react-redux useSelector हुक के साथ आया जो connect HOC से 100 गुना अधिक सुविधाजनक है, अपोलो HOCs से हुक में चला गया, वही useStyles के लिए जाता है इस पुस्तकालय में withStyles से अधिक सुविधाजनक है।

कॉपी-पेस्ट किए गए CSS को JSS में बदलने की परेशानी बहुत अधिक हल करने योग्य समस्या है, यदि रुचि है तो मैं इसे या वेबसाइट को स्वचालित करने के लिए VSCode एक्सटेंशन भी बनाऊंगा।

अगर कोई दिलचस्पी है तो मैं इसे स्वचालित करने के लिए एक VSCode एक्सटेंशन भी बनाऊंगा

@ jedwards1211 paulmolluzzo.convert-css-in-js है, लेकिन अगर आप JSS के लिए इसमें सुधार कर सकते हैं, तो मुझे यकीन है कि इसका स्वागत किया जाएगा।

हाँ ऐसा लगता है कि मैं निश्चित रूप से इसमें सुधार कर सकता हूं, यह केवल सीएसएस गुणों को परिवर्तित करता है, नियम और चयनकर्ता नहीं।

@ jedwards1211 मैंने पढ़ा कि आपने क्या कहा, और इस सब से एक पल के लिए एक कदम पीछे हटते हुए - यह मुझे उन लोगों की टिप्पणियों की याद दिलाता है जो रिक्त स्थान पर टैब के उपयोग के बारे में बहस करते हैं। वास्तविकता यह है कि इससे वास्तव में कोई फर्क नहीं पड़ता कि आप क्या उपयोग करते हैं जब तक कि यह अंत में एक उपयोगी उत्पाद का उत्पादन करता है।

ट्विटर या रेडिट पर अपनी राय/हॉट टेक छोड़ें और हम उन पर वहां चर्चा कर सकते हैं - लेकिन आइए इस मुद्दे को सीएसएस के लिए टेम्प्लेट स्ट्रिंग्स बनाम ऑब्जेक्ट्स पर व्यर्थ लौ युद्धों के साथ जारी न रखें ... मुझे लगता है कि हम सभी सहमत हो सकते हैं कि हम बेहतर हैं उस से

यह इंगित करने के लिए धन्यवाद कि एमयूआई में यथास्थिति को बदलना उचित नहीं है? मैं

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

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

@ jedwards1211 भले ही आपको स्टाइल वाले घटकों का उपयोग करने के लिए मजबूर किया गया हो, $#$ v4 $#$ में एक वैकल्पिक css prop सिंटैक्स पेश किया गया है जिसे आप नियोजित कर सकते हैं - कम से कम, इस तरह आपको चिंता करने की आवश्यकता नहीं होगी स्टाइल घटकों (MuiCard, StyledCard आदि) को उपसर्ग देना।

import { Avatar } from '@material-ui/core';

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@ jedwards1211 यदि आप स्टाइल वाले घटकों का उपयोग कर रहे थे तो आपके उदाहरण को भी सरल बनाया जा सकता है

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya css प्रोप एक तरह से अच्छा है, हालांकि एक महत्वपूर्ण चेतावनी यह है कि इसे बैबेल प्लगइन के साथ लागू किया गया है, इसलिए यह सभी के लिए नहीं है, विशेष रूप से वे लोग जो अपनी tsx फ़ाइलों को संकलित करने के लिए tsc का उपयोग करते हैं। इसके अलावा, मुझे लगता है कि यह टाइपस्क्रिप्ट या कम से कम फ्लो को शिकायत करने का कारण बनेगा कि घटक के पास css प्रोप नहीं है।

मुझे लगता है कि मैं अपने ऐप में होने वाले संभावित व्यवधान से मुख्य रूप से नाखुश हूं। @oliviertassinari ने दूसरे दिन उल्लेख किया कि वह styled-components को MUI v5 में डिफ़ॉल्ट बनाने के बारे में सोच रहा है। और उम्मीद है कि यह वैकल्पिक होगा और JSS का अभी भी उपयोग किया जा सकता है, लेकिन हम देखेंगे कि क्या वे इसे दूर कर सकते हैं, आप जानते हैं। यह एक झटके के रूप में आया - क्या वास्तव में संपूर्ण उपयोगकर्ता आधार की प्राथमिकताओं पर एक संपूर्ण जनमत संग्रह हुआ है? मैं इमोशन की उम्मीद करता अगर कुछ भी क्योंकि यह अब बहुत अधिक लोकप्रिय है।

साथ ही मुझे लगता है कि यह टाइपस्क्रिप्ट या कम से कम फ्लो को शिकायत करने का कारण बनता है कि घटक में कोई सीएसएस प्रोप नहीं है।

कॉन्फ़िगर किया जा सकता है।

क्या वास्तव में संपूर्ण उपयोगकर्ता आधार की प्राथमिकताओं पर एक संपूर्ण जनमत संग्रह हुआ है?

यह असंभव है। हम वास्तव में केवल यह मान सकते हैं कि GitHub पर संलग्न लोग "हमारे" उपयोगकर्ता हैं। यह मुद्दा अब तक का सबसे अधिक वोट वाला मुद्दा है।

मैं इमोशन की उम्मीद करता अगर कुछ भी क्योंकि यह अब बहुत अधिक लोकप्रिय है।

आपने लोकप्रियता को कैसे मापा?

️ स्टाइल-घटकों की तुलना में डेवलपर्स द्वारा भावनाओं को काफी कम चुना जाता है (/6 जो मुझे याद है)। यदि आप npm पर डाउनलोड पर विचार करते हैं, तो स्टोरीबुक को हटा दें और प्रतिक्रिया-चयन डाउनलोड मायने रखता है (यह बहुत बड़ा है)।

@ eps1lon यहाँ वही है जो मैं देख रहा था: https://2019.stateofcss.com/technologies/css-in-js/

हालांकि मैं गलत था, दुर्भाग्य से मुझे जो कुछ भी याद आया वह ऊपर की ओर प्रतीत होने वाला रुझान था, भले ही यह समय के साथ लोकप्रियता का चार्ट नहीं है (बहुत ही संदिग्ध चार्ट डिजाइन):

कॉन्फ़िगर किया जा सकता है

क्या वास्तव में टाइपस्क्रिप्ट को यह मानने का कोई तरीका है कि सभी JSX तत्व css प्रोप का समर्थन करते हैं? मुझे ऐसा करने के लिए फ़्लो को कॉन्फ़िगर करने का कोई तरीका नहीं पता है।

संपादित करें : सौभाग्य से मुझे टाइपस्क्रिप्ट के लिए एक रास्ता मिल गया, सुनिश्चित नहीं है कि फ्लो के लिए कोई रास्ता है या नहीं।

यह मुद्दा अब तक का सबसे अधिक वोट वाला मुद्दा है।

समझा। विलाप

FWIW, styled-components के मुख्य योगदानकर्ताओं में से एक टाइप सिस्टम के प्रति एक अमित्र रवैया रखता है:

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

स्टाइल-घटकों में माइग्रेट करने के विचार के बारे में मैं बहुत अधिक आश्वस्त महसूस करूंगा यदि वे टीएस/फ्लो उपयोगकर्ताओं के देव अनुभव की परवाह करते हैं ...

@ jedwards1211 अगर मदद करता है तो css के लिए एक बैबेल मैक्रो है। विशेष रूप से सीएसएस/एससीएसएस/कम से आ रहा है मुझे नहीं लगता कि हर कोई "स्टाइल" तरीके से आगे बढ़ना पसंद करता है।

हालांकि लक्ष्य क्या हैं? प्रदर्शन के बारे में क्या? जैसे कुछ सिस्टम परमाणु सीएसएस का समर्थन करते हैं। टेलविंड्स से आने से यह चीजों को ज्यादा साफ और शायद तेज बनाता है।

@ hc-codersatlas आप packages/material-ui-benchmark में कुछ बेंचमार्क पा सकते हैं।

@koistya अगर मैं इसे सही ढंग से पढ़ता हूं तो भावना बाकी की तुलना में बहुत तेज दिखती है।

@oliviertassinari अधिकांश डेवलपर्स वास्तव में इस विकल्प को "बनाना" करते हैं? प्रतिक्रिया-चयन और स्टोरीबुक के आपके उल्लेख के अनुसार, अधिकांश डेवलपर्स संभवतः यूआई घटकों और सामग्री-यूआई के साथ जो कुछ भी बंडल किया गया है उसका उपयोग करने जा रहे हैं। UI फ्रेमवर्क जो पहले से उपयोग कर रहा है, उसके शीर्ष पर एक अलग सिस्टम के साथ अधिक प्रयास।

इनमें से अधिकांश UI फ्रेमवर्क बड़े कोर से हैं, यानी कुछ लोग वास्तव में इसे "पसंद" कर रहे हैं।

उदाहरण के लिए ग्रोमेट स्टाइल-घटकों का उपयोग करता है, जो कि बहुत सी कंपनियां 1 बिंदु पर उपयोग कर रही हैं।

और उस नोट पर npm डाउनलोड का क्या मतलब है? कॉर्पोरेट उपयोग की संभावना का मतलब फायरवॉल और आंतरिक एनपीएम कैशिंग है, जो इन मेट्रिक्स को छोड़ देता है।

यदि कोई परिवर्तन होने वाला है तो कृपया तकनीकी योग्यता के आधार पर सर्वश्रेष्ठ 1 में बदलें न कि लोकप्रियता जैसी किसी चीज़ के आधार पर। मैं भविष्यवाणी करता हूं कि यदि सामग्री-यूआई किसी भी पुस्तकालय का उपयोग करता है तो यह लोकप्रिय 1 होगा क्योंकि मुई स्वयं सबसे लोकप्रिय यूआई ढांचे में से 1 है।

@ South-Paw आपका प्रस्तावित सरलीकरण काम नहीं करेगा, आप अपने उदाहरण में ${MuiCardContent} का उपयोग नहीं कर सकते क्योंकि MuiCardContent एक स्टाइल घटक नहीं है।

https://styled-components.com/docs/advanced#referring -to-other-components

अनिवार्य रूप से सभी व्यक्तिगत एचओसी रैपर से बचने का कोई तरीका नहीं है। हालांकि कुछ समय के लिए इसके बारे में सोचने के बाद मुझे एहसास हुआ कि यह मूल रूप से टाइपिंग/नामकरण निर्णयों की उतनी ही मात्रा है जितना किसी को जेएसएस के साथ करना है।

@mbrookes @oliviertassinari सशर्त शैलियों और आंतरिक घटक शैलियों को कैसे संभाला जाएगा?
उदाहरण के लिए निम्नलिखित में से एक styled-components -आधारित समतुल्य क्या होगा?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

मैं styled-components पर स्विच करने के विचार के बारे में शांत हो गया हूं, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि इस प्रकार के उपयोग के मामलों को संभालने के लिए एक ठोस योजना है, क्योंकि मुझे लगता है कि एपीआई को बहुत अलग होना होगा या भरोसा करना होगा बीईएम शैली वर्ग के नाम पर।

@ jedwards1211 आह मेरी गलती। मैं इस धारणा के तहत था कि उदाहरण यह था कि वे स्टाइल वाले घटक थे - लेकिन वास्तव में यह काम नहीं करेगा यदि वे नहीं हैं

@ jedwards1211 clsx कुछ ऐसा है जिसे मैंने अतीत में सशर्त वर्गों के लिए स्टाइल-घटकों के साथ जोड़ा है - क्या आप इसका मतलब है?

प्रोजेक्ट जो मैं इस समय कर रहा हूं, स्टाइल-घटकों का उपयोग एमयूआई घटकों को लपेटने के लिए आवश्यक है, इसलिए मैंने किसी भी एमयूआई सशर्त स्टाइल का उपयोग नहीं किया है

@ South-Paw कि (या classnames ) समाधान का आंतरिक विवरण हो सकता है, लेकिन मेरा मतलब यह है कि styled-components रैपर केवल एक className AFAICT इंजेक्ट करते हैं, वहां होगा एक घटक में कई ओवरराइड वर्ग नामों को पारित करने का वास्तव में एक सुविधाजनक तरीका नहीं हो सकता है। इसके बजाय हमें <Dialog Paper={StyledPaper}>...</Dialog> जैसा कुछ करना पड़ सकता है, और मुझे यह भी पता नहीं है कि चयनित MenuItem वर्ग उदाहरण के लिए क्या है।

@ jedwards1211 क्या आपके पास एक त्वरित उदाहरण करने का समय होगा ताकि मैं बेहतर ढंग से समझ सकूं कि आप जिस उपयोग के मामले का वर्णन कर रहे हैं वह क्या है और आपको लगता है कि समस्या कहां है? मैं एक समाधान के साथ मदद की कोशिश करने में सक्षम होना चाहता हूं लेकिन मुझे समझ में नहीं आता कि यह अभी तक क्या लागू होता है

हाँ मैं आज रात समय से बाहर हूँ लेकिन कल मैं करूँगा।
इसके अलावा मुझे jss-codemorphs पर काम प्रगति पर है, अंत में चिपकाए गए सीएसएस को जेएसएस में परिवर्तित करने के लिए वीएससीओडी एक्सटेंशन बनाने की योजना बना रहा है।

स्टाइल घटकों के सिंटैक्स या पैकेज को बनाए रखने के तरीके के प्रशंसक कभी नहीं रहे, इस प्रस्ताव के प्रशंसक नहीं। सामग्री ui के बारे में मुझे जो चीजें सबसे ज्यादा पसंद हैं उनमें से एक वर्तमान स्टाइलिंग समाधान है।

यह ध्यान रखना दिलचस्प है कि मैंने पढ़ा है कि फेसबुक एक सीएसएस-इन-जेएस समाधान भी ओपन-सोर्सिंग कर सकता है। जब यह बाहर आता है तो उस पर भी एक नज़र डालना मूल्यवान हो सकता है।

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

यह ध्यान रखना दिलचस्प है कि मैंने पढ़ा है कि फेसबुक एक सीएसएस-इन-जेएस समाधान भी ओपन-सोर्सिंग कर सकता है।

@venikx ऐसा होने की कितनी संभावना है? पिछली बार जब मैंने किसी ऐसी चीज़ के बारे में सुना है जो यह सुझाव दे सकती है कि वह https://reactpodcast.simplecast.fm/75 में थी, तो यह 5 साल का लंबा उद्देश्य लग रहा था।

वाह वाकई? मुझे नहीं पता था कि उन्होंने पहले ही "टाइमलाइन" दे दी है। किसी कारण से मैंने मान लिया कि यह लगभग उसी समय समवर्ती मोड के साथ आएगा। बहुत बुरा।

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

एक और कष्टप्रद बात (लेकिन यह शायद फिर से व्यक्तिगत पसंद है) यह है कि आप किसी घटक के लिए गतिशील रूप से लागू शैलियों से कैसे निपटते हैं। मैं उस तर्क को स्टाइल-घटक में एम्बेड करने पर क्लासनाम जोड़ने या हटाने को बहुत पसंद करता हूं।

सामग्री-यूआई एपीआई इस समय इम्हो में वास्तव में साफ है।

टाइपस्क्रिप्ट अनुभव बहुत अच्छा नहीं होने के कारण मैं स्टाइल-घटकों को नापसंद करता हूं।

मैंने अब तक कम से कम 4 बड़ी परियोजनाओं में स्टाइल-घटकों और टाइपस्क्रिप्ट का एक साथ उपयोग किया है और प्रकारों के साथ कोई समस्या नहीं है - घटक पुस्तकालय में चीजें करते समय वे थोड़े बालों वाले हो सकते हैं, लेकिन यह एमयूआई अंत पर होगा - उपभोक्ताओं के अंत पर नहीं।

धीमी संकलन समय

मैंने किसी भी परियोजना में इसका अनुभव नहीं किया है जिस पर मैंने काम किया है - क्या आपके पास इसका मतलब है कि कहीं और उदाहरण है?

पागल इंटरफेस (यह समझने की कोशिश कर रहा है कि इंटरफ़ेस के माध्यम से स्टाइल-घटक कैसे काम करते हैं, उन सभी नेस्टेड पिक जादू के कारण एक दुःस्वप्न है)

आप इसके लिए @types प्रोजेक्ट में योगदान करने पर भी विचार कर सकते हैं यदि आपको लगता है कि आप उन्हें किसी तरह सुधार सकते हैं - मुझे यकीन है कि हर कोई वहां किसी भी काम की सराहना करेगा यदि यह अब वहां क्या सुधार है!

मैं उस तर्क को स्टाइल-घटक में एम्बेड करने पर क्लासनाम जोड़ने या हटाने को बहुत पसंद करता हूं।

स्टाइल-घटकों के साथ कक्षाओं का उपयोग करने से आपको कोई रोक नहीं सकता है:

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

ध्यान देने योग्य बात यह है कि कुछ टिप्पणियों का अन्यथा दावा करने के बावजूद, मूल मुद्दे पर 150 और 27 हैं और केवल 18 और 9 हैं। ऐसा लगता है कि एक मुखर अल्पसंख्यक है जो इस चर्चा को पसंद नहीं करता है और बहुसंख्यकों को लगता है कि यह एक सकारात्मक कदम है ‍♂

@ South-Paw मतदान के साथ समस्या यह है कि एकमात्र विकल्प है: JSS बनाम स्टाइल-घटक। मुखर हिस्सा स्टाइल वाले घटकों को पसंद नहीं करने के बारे में है और यह नहीं कि वे जेएसएस को पसंद करते हैं। शायद अगर वोट

दिन के अंत में जेएसएस से कुछ भी बेहतर होता है। यह पुराना है। यह धीमा और भारी है (बंडल आकार) और इसे आगे बढ़ाया जाना चाहिए। इसलिए वोट आपके निष्कर्ष का बिल्कुल भी समर्थन नहीं करते हैं।

क्या आप सभी स्पेक्ट्रम चैट या ऐसा कुछ करने के लिए आगे बढ़ सकते हैं जो इस मुद्दे को शोर से नहीं भरता है कि लोग एक-दूसरे से लड़ रहे हैं यह देखने के लिए कि कौन तर्क जीतता है?

मैं कोर टीम से इस विषय पर चर्चा के लिए सूत्र का अनुसरण कर रहा हूं।

मुझे लगता है कि आप कोर टीम के फैसले को कम करके आंक रहे हैं, और व्यक्तिगत रूप से मुझे लगता है कि आपको इस विषय पर बहस करना बंद कर देना चाहिए और कोर टीम पर अधिक भरोसा करना चाहिए; दिन के अंत में, यह सामग्री UI की दिशा तय करने के लिए कोर टीम पर निर्भर है।

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

लेकिन, कृपया, मैं आपसे विनती करता हूं, कोर टीम को अपना काम करने दें, उन पर भरोसा करें, क्योंकि वे वास्तव में अद्भुत कौशल वाले सक्षम लोग हैं।

यहाँ देखने के लिए कुछ सुंदर है

दिन के अंत में जेएसएस से कुछ भी बेहतर होता है। यह पुराना है।

@ hc-codersatlas पुराना == परिपक्व - क्या आप कृपया विस्तार से बता सकते हैं कि यह एक समस्या क्यों है?

ठीक है एक गर्म मुद्दा की तरह लगता है, लेकिन क्या कोई कृपया इस सरल जानकारी की पुष्टि कर सकता है: क्या वर्तमान में styled-components -समान सिंटैक्स का उपयोग करना संभव है, टैग किए गए टेम्पलेट शाब्दिक के साथ जो वर्तमान मुई संस्करणों (4 या 5) में सीएसएस की तरह दिखता है। ?
मुझे इस प्रश्न का कोई स्पष्ट हाँ या ना में उत्तर नहीं मिला। मुझे वास्तव में अंतर्निहित तकनीक की परवाह नहीं है, केवल डेवलपर सुविधा के बारे में। इनविज़न से सीएसएस को कॉपी-पेस्ट करना मूल रूप से कुछ मामलों में काफी उपयोगी है।

यह समस्या सामग्री-यूआई में उपयोग किए जाने वाले स्टाइलिंग समाधान के बारे में है, आपका प्रश्न इस बारे में प्रतीत होता है कि आप अपने ऐप को कैसे स्टाइल करते हैं / घटकों को पुनर्स्थापित करते हैं, जिसके लिए आप किसी भी समाधान का उपयोग कर सकते हैं:

https://material-ui.com/guides/interoperability/

जेएसएस के पास प्लग-इन के रूप में टेम्प्लेट लिटरल्स के लिए बुनियादी समर्थन है।

मैंने अभी-अभी JSS कनवर्टर के लिए एक बहुत व्यापक CSS लागू करना समाप्त किया है:

• https://codemodsquad.github.io/jss-codemorphs/
• VSCode एक्सटेंशन: https://marketplace.visualstudio.com/items?itemName=vscodeshift.jss-codemorphs

उम्मीद है कि सीएसएस को जेएसएस शैलियों में कॉपी और पेस्ट करने की परेशानी दूर हो जाएगी।

@jedwards1211 इसे देखें
https://css2js.dotenv.dev/

@nainardev मैंने देखा है कि और अन्य उपयोगिताओं बहुत सीमित हैं, वे सीएसएस विशेषताओं को परिवर्तित करते हैं, लेकिन चयनकर्ताओं, नेस्टेड चयनकर्ताओं, एनीमेशन कीफ्रेम, मीडिया क्वेरी इत्यादि को परिवर्तित नहीं करते हैं। इसके कारण मैंने अपना टूल बहुत व्यापक बना दिया है, यह परिवर्तित कर सकता है उम्मीद है कि कोई भी पूर्ण विकसित सीएसएस आप इसे फेंक देंगे।

हो सकता है कि यह उत्तर कहीं छूट गया हो, लेकिन इसे वैसे भी उठाना चाहते हैं। हम सामग्री UI घटकों में माइग्रेट करने के साथ-साथ अपने स्टाइलिंग समाधान ( less बनाम makeStyles बनाम styled-components ) का मूल्यांकन करने की प्रगति में हैं, हमारी अधिकांश स्टाइलिंग कम के माध्यम से की जाती है फ़ाइलें और अधिकांश नए एमयूआई कोड makeStyles का उपयोग कर रहे हैं, मैं जो जानना चाहता हूं वह स्पष्ट है क्योंकि यह v5 का हिस्सा होगा, स्टाइल के आसपास तकनीकी ऋण को कम करने के लिए हम क्या कर सकते हैं?

1. क्या makeStyles लगभग v5 में होगा? यह styled-components और थीम के साथ कैसे काम करेगा? उदाहरण के लिए, यह styled-components के साथ कैसा दिखेगा:

const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));

1. (v4) क्या स्टाइल टेम्पलेट स्ट्रिंग में theme ऑब्जेक्ट को पुनः प्राप्त करने का इससे बेहतर तरीका है, इसलिए मैं इसे कई बार उपयोग कर सकता हूं?

const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;

1. मान लें कि makeStyles v5 में मौजूद है, क्या हमें किसी बड़े कोडबेस के लिए styled-components थीम प्रदाता और सामग्री UI थीम प्रदाता दोनों का उपयोग करने पर किसी भी प्रदर्शन हिट की उम्मीद करनी चाहिए?

मटेरियल यूआई का उपयोग करना पसंद है, कड़ी मेहनत के लिए धन्यवाद!

@egilsster

1. हां, या तो @ सामग्री-यूआई/शैलियों या प्रतिक्रिया-जेएसएस से, देखेंगे।
2. हाँ https://material-ui.com/guides/interoperability/#theme ,

const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;

1. मुख्य मुद्दे हैं 1. कॉन्फ़िगरेशन ओवरहेड, एक बार की लागत, 2. दो सीएसएस-इन-जेएस रनटाइम लोड करना, जिसमें ~ 15 kB gzipped ओवरहेड है, एक समान लागत, कहने के लिए, संतरी सहित: https://bundlephobia.com /result?p=@sentry/browser.

त्वरित उत्तर के लिए धन्यवाद, बहुत सराहना की।

1. हाँ सामग्री-ui.com/guides/interoperability/#theme

यह बहुत अच्छा है। टूलिंग के आसपास कुछ काम शायद इसका पालन करेंगे, जिस प्रोजेक्ट को मैं माइग्रेट कर रहा हूं वह टीएस का उपयोग नहीं कर रहा है लेकिन वीएससीओडी/भाषा सर्वर को कोई विचार नहीं है कि इस मामले में theme क्या है और मैं styled-components खो देता हूं सिंटैक्स हाइलाइटिंग भी।

फिर से धन्यवाद, इस विकास का अनुसरण करना जारी रखेंगे।

@oliviertassinari अगर स्टाइल-घटकों में माइग्रेशन है, तो क्या इसका मतलब यह होगा कि हम अब सीएसएस एपीआई जैसे <ListItem classes={{ selected: myCustomClassName}}> पर भरोसा नहीं कर सकते हैं?

@ jedwards1211 classes API बना रहेगा।

ठीक। मैं थोड़ा उलझन में हूं कि एमयूआई स्टाइल-घटकों का आंतरिक रूप से उपयोग कैसे करेगा, क्योंकि स्टाइल-घटक केवल एक वर्ग को मूल तत्व पर लागू कर सकते हैं।

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

क्या इसका कोई मतलब है @ jedwards1211 ?

@yordis मुझे पता है कि यह इतना आसान लगता है, लेकिन आप यौगिक चयनकर्ताओं जैसे https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js को कैसे रिफलेक्टर करेंगे

मैं वास्तव में इस मौजूदा व्यवहार को styled-components के साथ संरक्षित करने के तरीके के बारे में नहीं सोच सकता, इसलिए इससे लोगों की अपेक्षा से अधिक ब्रेकिंग परिवर्तन हो सकते हैं।

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

मौजूदा कोड और लोगों के कस्टम ओवरराइड शायद कुछ मामलों में सीएसएस विशिष्टता पर भी निर्भर करते हैं।

शायद यह? मुझे इसका पालन करना निश्चित नहीं है क्योंकि यह मेरे लिए बुनियादी लगता है, मुझे शायद कुछ संदर्भ और/या जानकारी याद आ रही है।

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordis संभवतः। जैसा कि मैंने कहा, हालांकि लोग शायद इस बारे में नहीं सोच रहे हैं कि इससे उपयोगकर्ताओं के लिए कितने ब्रेकिंग परिवर्तन होंगे, मुझे नहीं लगता कि उदाहरण ब्रेकिंग परिवर्तनों को रोक देगा।

क्या आप वास्तविक उदाहरण, और वास्तविक संभावित ब्रेकिंग परिवर्तन साझा करना चाहेंगे?

जब आप मजबूत मामलों को साझा नहीं करते हैं तो आपका अनुसरण करना कठिन होता है। आपके संदेशों के आधार पर मुझे लगता है कि आप इस विषय को पूरी तरह से नहीं समझते हैं, या मैं गलत निर्णय ले रहा हूं। कृपया मुझे समझने में मदद करें, मैं गलत हो सकता हूं।

@oliviertassinari विषय ओवरराइड अभी भी v5 में संशोधन के बिना काम करेगा? काम करने के लिए निम्नलिखित ओवरराइड उदाहरण के लिए, ऐसा लगता है कि एमयूआई को अभी भी styled-components -जेनरेटेड रूट क्लास नाम के अतिरिक्त जेएसएस-जेनरेटेड क्लास नामों को लागू करना होगा।

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordis ने इसके बारे में और सोचा, मुझे एहसास हुआ कि classes प्रोप के माध्यम से पारित शैलियों के लिए यौगिक चयनकर्ता अभी भी काम करने के लिए होंगे, सौभाग्य से। हालांकि थीम ओवरराइड शैलियों के बारे में निश्चित नहीं है।

मुझे स्टाइल = {ऑब्जेक्ट} का उपयोग करके केवल सादे एमयूआई स्टाइल के साथ एमयूआई पर स्टाइल-घटक दोनों का उपयोग करने का आनंद मिला है।

एक परिणाम सूची पृष्ठ लें, जिसमें 50 कार्ड हों, प्रत्येक में मीडिया हिंडोला, जानकारी, क्लिक हैंडलर, बटन आदि हों।

स्टाइल घटकों का उपयोग करके रेंडर समय में लगभग आधा सेकंड जोड़ा गया; const useStyles = makeStyles या शैली={ऑब्जेक्ट} की तुलना में।

मुझे इस रोडमैप योजना के परिणाम को स्वीकार करना होगा; लेकिन यह निश्चित रूप से यूआई अपनाने के लिए हमारी योजनाओं में एक किंक फेंक देगा अगर यह पूरी तरह से टॉप-डाउन किसी और चीज के साथ ओवरराइड करने योग्य नहीं है।

@Icehunter क्या आप लोगों को इसे देखने के लिए अपने परिणाम और नमूना परियोजना ऑनलाइन पोस्ट कर सकते हैं?

@Icehunter क्या आप लोगों को इसे देखने के लिए अपने परिणाम और नमूना परियोजना ऑनलाइन पोस्ट कर सकते हैं?

नमूना परियोजना कठिन होगी क्योंकि यह कंटेनर मालिकाना कोड होगा। मैं जल्द ही प्रदर्शन टैब का एक प्रदान की गई छवि और समय परिणाम अनुभाग पोस्ट करूंगा।

एक परिणाम सूची पृष्ठ लें, जिसमें 50 कार्ड हों, प्रत्येक में मीडिया हिंडोला, जानकारी, क्लिक हैंडलर, बटन आदि हों।

@Icehunter क्या आप उन शैलियों के लिए कोई सहारा भेज रहे हैं? चाहे वह 50 कार्ड हों या 500 कार्ड, उत्पन्न वर्गों की संख्या समान होनी चाहिए। ऐसा लगता है कि आपके विशिष्ट उदाहरण में मालिकाना कोड है जिसे साझा नहीं किया जा सकता है, लेकिन क्या आपके लिए इस समस्या को कोड के साथ पुन: उत्पन्न करना संभव होगा जिसे आप साझा कर सकते हैं?

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

मैंने एक कोडसैंडबॉक्स उदाहरण एक साथ रखा है ताकि यह स्पष्ट किया जा सके कि स्टाइल घटकों पर निर्भर समाधान styled MUI makeStyles की तुलना में 3-4x धीमा हो सकता है:

styled एपीआई सुविधा के लिए अच्छे हैं, लेकिन मैं @Icehunter की भावना को प्रतिध्वनित करता हूं कि सूचियों/तालिकाओं में भारी उपयोग किए जाने पर यह एक प्रदर्शन चिंता का विषय हो सकता है। बैकअप के रूप में makeStyles होना अच्छा है।

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

@tuxracer क्षमा याचना - अद्यतन।

@Icehunter मुझे समझ में नहीं आता कि आपका क्या मतलब है, आपने एससी या जेएसएस के साथ सामान्य शैलियों का उपयोग किया है?

@Icehunter मुझे समझ में नहीं आता कि आपका क्या मतलब है, आपने एससी या जेएसएस के साथ सामान्य शैलियों का उपयोग किया है?

दोनों वास्तव में। हमने मेक स्टाइल के साथ जाना समाप्त कर दिया, लेकिन या तो स्टाइल = {ऑब्जेक्ट} का उपयोग करके हमें वही पूर्ण परिणाम मिले।

हम संपूर्ण घटक पुस्तकालय और मुख्य साइट पर बेहतर प्रदर्शन प्राप्त करने के लिए माइग्रेशन प्रक्रिया में हैं।

स्टैक वार यह नेक्स्टज में लिखा है।

बस स्पष्ट होने के लिए (संपादित करें):

मैंने एससी का उपयोग इरादा के अनुसार किया है, मुई घटकों को लपेटकर। बहुत धीमी गति से निकला।

फिर मैंने एक साझा फ़ाइल सेटअप, और स्थानीय (सिम्युलेटेड कैस्केडिंग) से मेक स्टाइल और/या शैली = {ऑब्जेक्ट} का उपयोग करके एमयूआई घटकों का उपयोग किया। बहुत ज्यादा तेज।

मैं इस विचार को बिल्कुल भी अवरुद्ध नहीं करना चाहता; लेकिन अगर यह डिफ़ॉल्ट है; तो वैश्विक स्तर पर डिफ़ॉल्ट विकल्प को ऊपर-नीचे ओवरराइड करने और खुद को इंजेक्ट करने का एक तरीका होना चाहिए।

शायद यह? मुझे इसका पालन करना निश्चित नहीं है क्योंकि यह मेरे लिए बुनियादी लगता है, मुझे शायद कुछ संदर्भ और/या जानकारी याद आ रही है।

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

शायद इस खेल के लिए देर हो चुकी है। लेकिन मुझे लगता है कि @ jedwards1211 इस बात की तलाश में है कि इसे SC के साथ कैसे व्यक्त किया जा सकता है: https://codesandbox.io/s/magical-snow-5bzd8

मेरे पास यह कुछ जगहों पर है। तो अच्छा होगा यदि उस दिन आने पर v5 पर माइग्रेट करना आसान हो

असल में मुझे यकीन नहीं है कि स्टाइल-घटकों का उपयोग करके ऐसा कुछ कैसे काम करेगा।

उदाहरण के लिए, यदि सामग्री UI भविष्य में Typography के डिफ़ॉल्ट वेरिएंट को ओवरराइड करने का समर्थन करेगा, तो मुझे लगता है कि JSS स्टाइल-घटकों की तुलना में आसान है।

@ heb-mm यहां एक विस्तृत RFC है जिसका @oliviertassinari ने 7 मार्च को इस सूत्र का उल्लेख किया है।

मुझे ऊपर स्क्रॉल करने और उल्लेख देखने में एक मिनट से भी कम समय लगा।

संपादित करें: सोच रहे लोगों के लिए, हेब-एमएम ने अब अपनी टिप्पणी हटा दी है।

मैंने एक कोडसैंडबॉक्स उदाहरण एक साथ रखा है ताकि यह स्पष्ट किया जा सके कि स्टाइल घटकों पर निर्भर समाधान styled MUI makeStyles की तुलना में 3-4x धीमे हो सकते हैं:

@schnerd मैंने सामग्री-यूआई इनहाउस styled एपीआई को शामिल करने के लिए आपके बेंचमार्क को अपडेट किया है जो styled-components की नकल करनी चाहिए। मुझे यह देखकर आश्चर्य हुआ कि अन्य विकल्पों की तुलना में यह कितना अविश्वसनीय रूप से धीमा है। देखें https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js

क्या किसी को पता है कि @emotion/styled (जिसमें मूल रूप से स्टाइल-घटकों के समान एपीआई है) समान रूप से धीमा होगा? मैं बस सोच रहा हूं कि उनके कार्यान्वयन के बारे में कुछ ऐसा है जिसे बेहतर अनुकूलित किया जा सकता है।

क्या किसी को पता है कि @emotion/styled (जिसमें मूल रूप से स्टाइल-घटकों के समान एपीआई है) समान रूप से धीमा होगा? मैं बस सोच रहा हूं कि उनके कार्यान्वयन के बारे में कुछ ऐसा है जिसे बेहतर अनुकूलित किया जा सकता है।

https://codesandbox.io/s/css-in-js-comparison-sej1m

स्टाइल घटकों के रूप में तेज़ के बारे में। अभी भी मेकस्टाइल जितना तेज़ नहीं है। जिस मुद्दे को मैं सबसे अधिक भाग के लिए देखता हूं वह वस्तु निर्माण और वस्तु कैशिंग/संस्मरण अंतर है।

हम्म, यह एमयूआई में हमारी माइग्रेशन योजनाओं को काफी हद तक परेशान कर सकता है। अपने CSS, थीमिंग और प्रदर्शन को प्रबंधित करने में बहुत परेशानी होने के बाद हम वर्तमान में सामग्री UI स्टाइलिंग सिस्टम के पक्ष में styled-components से दूर जा रहे हैं। styled components पहले तो ठीक था, हमने इसके ऊपर अपना खुद का थीमिंग समाधान बनाया, लेकिन जब UI बड़ा हुआ, तो CSS ने भी ऐसा ही किया। हम टाइपस्क्रिप्ट का उपयोग करते हैं, इसलिए तथ्य यह है कि हम इनलाइन सीएसएस स्ट्रिंग के बजाय जेएस ऑब्जेक्ट को आसानी से दोबारा कर सकते हैं, यह एक बड़ा विक्रय बिंदु था। मैं

इसलिए मैं मटेरियल यूआई के लिए काफी नया हूं और मैंने अभी-अभी v5 की अल्फा रिलीज देखी है। @ ldiego08 आपने कहा:

हम वर्तमान में सामग्री UI स्टाइलिंग सिस्टम के पक्ष में स्टाइल-घटकों से दूर जा रहे हैं

प्रतिक्रिया के साथ काम करते समय मैं आमतौर पर स्टाइल घटकों का उपयोग करता हूं। मटेरियल यूआई स्टाइलिंग सिस्टम क्या है और आगे चलकर मटीरियल यूआई में स्टाइल और सीएसएस का उपयोग करने का अनुशंसित तरीका क्या है? मैंने इस पृष्ठ को पढ़ा है और यह मेरे लिए स्पष्ट नहीं है कि आप CSS-IN-JS के पक्ष में हैं या नहीं: https://material-ui.com/system/basics/। मैं आमतौर पर सीएसएस को ऑब्जेक्ट सिंटैक्स में नहीं लिखना पसंद करता हूं, और मैंने सीएसएस-इन-जेएस का उपयोग करने के लाभों का आनंद लिया है, क्योंकि आपको "सामान्य सीएसएस सिंटैक्स" का उपयोग करने को मिलता है, लेकिन जेएस की शक्ति भी हाथ में है।

जाने के लिए किसी भी मदद के लिए धन्यवाद!

मुझे नहीं पता कि स्टाइल-घटक API I इतना लोकप्रिय क्यों है। यह धीमा है, आपको केवल वर्ग नाम उत्पन्न करने के बजाय सब कुछ घटक में लपेटना होगा। और साथ ही, टैग किए गए टेम्पलेट अक्षर के साथ क्या बात है? हम सीएसएस फाइलों में सीएसएस लिखना नहीं चाहते थे, क्योंकि इसे जावास्क्रिप्ट स्ट्रिंग में लिखना बेहतर है? :D ऑब्जेक्ट सिंटैक्स अधिक शक्तिशाली होता है जब यह कंपोज़िशन और रीफैक्टरिंग आदि की बात आती है। मेरे लिए, प्लेन इमोशन css और cx फंक्शन जो css ऑब्जेक्ट लेते हैं और रिटर्न क्लास का नाम सबसे लचीला और शक्तिशाली API है। तो बस भावनाओं के साथ वर्ग के नाम उत्पन्न करना और कक्षा एपीआई का उपयोग करना सुपर लचीला और शक्तिशाली है। तो मुझे समझ में नहीं आता कि आप "अधिक सुविधाजनक डेवलपर एपीआई" के लिए प्रदर्शन और लचीलेपन का व्यापार क्यों करेंगे (कुछ लोगों के लिए, मेरे लिए, यह भयानक एपीआई है)।

मुझे नहीं पता कि स्टाइल-घटक API I इतना लोकप्रिय क्यों है। यह धीमा है, आपको केवल वर्ग नाम उत्पन्न करने के बजाय सब कुछ घटक में लपेटना होगा। और साथ ही, टैग किए गए टेम्पलेट अक्षर के साथ क्या बात है? हम सीएसएस फाइलों में सीएसएस लिखना नहीं चाहते थे, क्योंकि इसे जावास्क्रिप्ट स्ट्रिंग में लिखना बेहतर है? :D ऑब्जेक्ट सिंटैक्स अधिक शक्तिशाली होता है जब यह कंपोज़िशन और रीफैक्टरिंग आदि की बात आती है। मेरे लिए, प्लेन इमोशन css और cx फंक्शन जो css ऑब्जेक्ट लेते हैं और रिटर्न क्लास का नाम सबसे लचीला और शक्तिशाली API है। तो बस भावनाओं के साथ वर्ग के नाम उत्पन्न करना और कक्षा एपीआई का उपयोग करना सुपर लचीला और शक्तिशाली है। तो मुझे समझ में नहीं आता कि आप "अधिक सुविधाजनक डेवलपर एपीआई" के लिए प्रदर्शन और लचीलेपन का व्यापार क्यों करेंगे (कुछ लोगों के लिए, मेरे लिए, यह भयानक एपीआई है)।

मुझे एक ही चिंता थी :) शायद यह चीजों को थोड़ा सा साफ़ कर देता है:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm हाँ, हम एक ही पृष्ठ पर हैं :) मुझे लगता है कि सामग्री UI टीम के लिए जाने का सबसे बढ़िया तरीका किसी प्रकार के प्लग करने योग्य समाधान को लागू करना है, न कि किसी भी सीएसएस के साथ जेएस समाधान में जोड़े, लोगों को यह चुनने देना कि क्या उपयोग करना है और इस तरह कुछ बंडल आकार बचाएं। और कक्षाओं को भी रखते हुए और MuiTheme API बनाते हैं, क्योंकि यह इसका सबसे शक्तिशाली हिस्सा है। मेरे लिए, जेएस में सीएसएस घटक स्थिति के आधार पर आसान गतिशील स्टाइल के बारे में है, सीएसएस या पूरे घटकों को रिफैक्टरिंग या हटाते समय आत्मविश्वास (जहां ऑब्जेक्ट दृष्टिकोण बेहतर है), प्रदर्शन (बाहरी स्टाइलशीट के समूह से अप्रयुक्त शैलियों का एक गुच्छा डाउनलोड नहीं करना) , आदि.. और फिर, मुझे समझ में नहीं आता कि लोग कुछ संपादक हाइलाइटिंग के साथ स्ट्रिंग लिखना क्यों पसंद करते हैं। मेरा मतलब है, आपको संदर्भ से प्रॉप्स तक पहुंचने के लिए ${} का उपयोग करना होगा। पृष्ठभूमि ओडी div तत्व सेट करने से कहीं अधिक जटिल के लिए, वह दृष्टिकोण गन्दा है और मेरी राय में पठनीय नहीं है। मैं इसे कोस नहीं रहा हूं, बस यह कह रहा हूं कि मैं क्या सोचता हूं और यह साबित करने की कोशिश कर रहा हूं कि हर डेवलपर स्टाइल-घटकों को पसंद नहीं करता है, और यहां तक ​​​​कि अगर उन्होंने किया, तो मैं नहीं देखता कि व्यापार प्रदर्शन और लचीलेपन के लिए यह एक अच्छा सौदा कैसे है। :)

@vdjurdjevic दरअसल, जेएस समाधान में एक सीएसएस में सामग्री-यूआई को जोड़ना संघर्ष के लिए लगभग एक गारंटीकृत नुस्खा है जब सीएसएस-इन-जेएस अभ्यास अनिवार्य रूप से विभिन्न दिशाओं में बढ़ते हैं।

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

की तर्ज पर कुछ:

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevic मैं https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320 पर आपके विचारों से काफी हद तक सहमत हूं। आप जिस दिशा में ले जा रहे हैं उसका यह सारांश आपको पसंद आ सकता है जिसे मैंने हाल ही में https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178 में साझा किया है।

मुझे समझ में नहीं आता क्यों लोग कुछ संपादक हाइलाइटिंग के साथ स्ट्रिंग लिखना पसंद करते हैं

मेरे दृष्टिकोण से कुछ कारण:

• हम React.createElement('div', {}) क्यों नहीं लिखते हैं, इसके करीब।
• वेब देव में सीमित अनुभव वाले लोग (वे कई हैं) जावास्क्रिप्ट एपीआई सीखने के लिए संघर्ष करते हैं, यह सीएसएस सिंटैक्स के साथ आसान लगता है। एक उदाहरण के रूप में डिजाइनरों को लें, अपनी टीम के लोगों से पूछें कि वे इसके बारे में क्या सोचते हैं :)।
• देव उपकरण और स्रोत के बीच कॉपी और पेस्ट नहीं कर सकता (मुझे इससे नफरत है)।

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

पुनश्च. मैं JSX का बहुत बड़ा प्रशंसक नहीं हूं :) यह जल्दी से गड़बड़ हो जाता है, आप तीर कोड के साथ समाप्त हो जाते हैं और उन घटकों के लिए जो गतिशील तत्वों को प्रस्तुत करना चाहिए, आपके पास createElement का उपयोग करने के अलावा कोई विकल्प नहीं है। यह नहीं कहना कि createElement के साथ सीधे काम करना बेहतर है, केवल यह कहना कि JSX आदर्श नहीं है। मेरी राय में, फ़्लटर के पास सबसे अच्छा डीएक्स है, मुझे उम्मीद है कि यह किसी दिन वेब प्लेटफॉर्म को अच्छी तरह से संभालने में सक्षम होगा।

@oliviertassinari हमारे चल रहे पूर्ण परीक्षण के अनुसार जैसा कि https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 में उल्लेख किया गया है, मुझे उम्मीद है कि सामग्री टीम केवल स्टाइल घटकों का चयन नहीं करेगी क्योंकि यह लोकप्रिय है। ये धीमा है। हमेशा रहा है। व्यक्तिगत रूप से यह एक देव होने की बात है कि आपको सीएसएस के जेएस नोटेशन जैसी चीजें सीखने की जरूरत है।

यह नौकरी का हिस्सा है।

पैकेज मेंटेनर के रूप में देवों के जीवन को आसान बनाना हमारे काम का हिस्सा है (मैं अपनी खुद की परियोजनाओं के लिए बोल रहा हूं) लेकिन इसे आसान बनाने और इसे प्रदर्शन करने के बीच एक रेखा आती है।

यही कारण है कि मैं केवल मेक स्टाइल का उपयोग करता हूं और इसे पेश किए जाने के बाद से हमेशा होता है।

मेरी पिछली टीम के आर्किटेक्ट ने स्टाइल वाले घटकों के साथ नहीं सुना और आगे की जुताई की और अब साइट धीमी है। मैंने एक परीक्षण शाखा में मेक स्टाइल के लिए स्विच किया और मोबाइल उपकरणों पर टीटीआई पर 50% (10 सेकंड) बचाया, लेकिन जैसा आपने उस टिप्पणी में कहा था, जेएस नोटेशन हर किसी के द्वारा ज्ञात नहीं है, इसलिए इसे स्वीकार नहीं किया गया था।

आंतरिक रूप से सामग्री जो चाहे चुन सकती है लेकिन कृपया इसे डिफ़ॉल्ट रूप से प्रदर्शनकारी बनाएं।

[प्रश्न स्टैक ओवरफ्लो में ले जाया गया।]

@haysclark कृपया RFC से निपटने के बजाय समर्थन प्रश्नों के लिए StackOverflow का उपयोग करें।

@haysclark कृपया RFC से निपटने के बजाय समर्थन प्रश्नों के लिए StackOverflow का उपयोग करें।

@mbrookes हेड-अप के लिए धन्यवाद!

क्या किसी को पता है कि @emotion/styled (जिसमें मूल रूप से स्टाइल-घटकों के समान एपीआई है) समान रूप से धीमा होगा? मैं बस सोच रहा हूं कि उनके कार्यान्वयन के बारे में कुछ ऐसा है जिसे बेहतर अनुकूलित किया जा सकता है।

https://codesandbox.io/s/css-in-js-comparison-sej1m

स्टाइल घटकों के रूप में तेज़ के बारे में। अभी भी मेकस्टाइल जितना तेज़ नहीं है। जिस मुद्दे को मैं सबसे अधिक भाग के लिए देखता हूं वह वस्तु निर्माण और वस्तु कैशिंग/संस्मरण अंतर है।

मैं सोच रहा था कि बॉक्स घटक के प्रदर्शन की तुलना आपकी प्रोफाइलिंग से की जाएगी, और अच्छे माप के लिए चक्र-यूआई के बॉक्स को जोड़ा, और परिणाम आश्चर्यजनक थे: पी
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen क्या आपने चक्र-यूआई v1 की कोशिश की है? इसे फिर से लिखा गया है और उम्मीद है कि बेहतर होना चाहिए। इमोशन v11 भी है, हालांकि अभी भी बीटा में है।

@Nvveen क्या आपने चक्र-यूआई v1 की कोशिश की है? इसे फिर से लिखा गया है और उम्मीद है कि बेहतर होना चाहिए। इमोशन v11 भी है, हालांकि अभी भी बीटा में है।

नवीनतम आरसी के साथ बस कोशिश की, लेकिन कोई ध्यान देने योग्य अंतर नहीं; यह अभी भी नियमित SC की तरह लगभग 1.5x से 2x धीमा है। मेरे लिए सबसे बड़ा सवाल यह है कि एमयूआई बॉक्स इतना धीमा क्यों है।

@Nvveen क्या आपने चक्र-यूआई v1 की कोशिश की है? इसे फिर से लिखा गया है और उम्मीद है कि बेहतर होना चाहिए। इमोशन v11 भी है, हालांकि अभी भी बीटा में है।

नवीनतम आरसी के साथ बस कोशिश की, लेकिन कोई ध्यान देने योग्य अंतर नहीं; यह अभी भी नियमित SC की तरह लगभग 1.5x से 2x धीमा है। मेरे लिए सबसे बड़ा सवाल यह है कि एमयूआई बॉक्स इतना धीमा क्यों है।

यह जेएस का उपयोग करता है। एससी कम से कम कुछ हद तक बेहतर है।

मेरी मशीन पर, जिस क्रम में परीक्षण मामले चलाए जाते हैं वह परिणामों को प्रभावित करता है। तुलना करना

1. पहले बॉक्स https://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
   

2. अंतिम बॉक्स https://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
   

@oliviertassinari कचरा संग्रह और वी 8 से जीआईटी इसका कारण बन रहा है। टेस्ट रन को वास्तव में अलग/अलग करना बेहतर है। बाद के परीक्षणों में बेहतर जिट है, लेकिन कभी-कभी यह कचरा संग्रह को ट्रिगर करेगा।

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

@ jedwards1211 अगर यह डीएक्स रखने के बारे में है, तो एटलसियन ने एक ऐसा काम किया जो इसे सीएसएस में संकलित करता है, जिसे संकलित कहा जाता है