Material-ui: [RFC] v5 स्टाइलिंग समाधान 5

बस कुछ सुधारों के लिए:

रिएक्ट समुदाय, बड़े पैमाने पर, जेएसएस के पैमाने पर उपयोग करने के खिलाफ मतदान किया है।

मैं इसके बजाय सुझाव दूंगा कि रिएक्ट समुदाय ने _for_ JSS को वोट नहीं दिया। शायद यह "विपणन" के साथ-साथ अन्य समाधान नहीं था?

हमने सही घोड़े पर दांव नहीं लगाया।

हमने एकमात्र घोड़े पर शर्त लगाई - यह एक घोड़े की दौड़ थी। समय पर उपलब्ध अन्य समाधानों में से कोई भी सभी बक्से को टिक नहीं करता है।

भावना को बहुत अच्छा लगता है! मुझे TS समर्थन प्राप्त करना पसंद है, जैसे, स्वत: पूर्ण और टाइपिंग के सभी लाभ - सीएसएस-इन-जेएस के साथ - जब यूआई या स्टाइलिंग घटकों का निर्माण होता है, तो क्या यह अभी भी संभव होगा?

अंतिम बिट मुझे मिल गया! मुझे बीटा फ्लैग के पीछे ऐसा करने में मदद मिलेगी या कुछ विशेषताओं पर विकास करना पसंद करेंगे:

भावना (सभी रेंडर-टाइम या डेफिनिशन-टाइम कंपोजिशन) का उपयोग करने वाली सभी रचनाएं तत्व पर एकल वर्ग में परिणाम करती हैं।
स्टाइल-कंपोनेंट्स इस तरह से रेंडर-टाइम कंपोजीशन (डेफिनिशन-टाइम कंपोजिशन को सिंगल क्लास में मिला देते हैं) से काम नहीं चलता।

मैंने यह भी नोट किया कि थीम ऑब्जेक्ट वही रहने वाला है, - मेरी राय में - किसी एप्लिकेशन को थीम देने का सबसे अच्छा तरीका! मेरे पास कहने के लिए और कुछ नहीं है: चकित:

एम-यूआई पर शानदार काम के लिए धन्यवाद। मुझे प्रोजेक्ट से जो दिशा मिल रही है, उससे प्यार है।

स्टाइलिंग के अधिक मानकीकृत तरीके से जाना एक तरीका है। मुझे पता है कि टीम और समुदाय किंक से बाहर काम करेंगे, और v5 - इसकी आवाज़ से - और भी भयानक होने वाला है! : रॉकेट:

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

+ भावना अधिक प्रकार के अनुकूल है

भावना के अनुचर के रूप में बोलते हुए - यह बहुत अच्छा लगता है

हमें जल्द ही एक नया प्रमुख-ईश जारी करने में सक्षम होना चाहिए, जिसमें कोई क्रांति नहीं होगी, बस कुछ क्लीनअप, समग्र सुधार, हुड के नीचे हुक और टीएस प्रकार के सुधार (बेहतर अनुमान और प्रदर्शन)।

ओह, और लिखित पार्सर! भावना और स्टाइल-कंपोनेंट्स में कुछ एज बग्स को खत्म करता है (वर्तमान में, वे दोनों एक ही पार्सर का उपयोग कर रहे हैं)। यह छोटा और तेज दोनों है।

ब्रेकिंग परिवर्तनों के बारे में क्या, कौन सा विकल्प अधिक ब्रेकिंग परिवर्तनों (यदि कोई हो) का परिचय देता है?

यकीन नहीं होता अगर इससे कोई फर्क पड़ता है लेकिन क्या बेंचमार्क भावनाओं और / या शैली-घटक के बैबल प्लगइन्स के साथ किया गया था? वे चीजों को और अधिक अनुकूलित करने में मदद करते हैं।

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

@ ee0pdt इमोशन बहुत है, स्टाइल बहुत पसंद है। मुझे लगता है कि स्टाइल-कंपोनेंट्स को लेकर इमोशन के लिए यह पूरी पसंद है। स्पष्ट लाभ हैं, और प्रवासन ऋण बहुत कम है।

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

स्टाइलट्रॉन-रिएक्शन से इंकार क्यों किया गया? यह एक संपूर्ण मीट्रिक छोड़ता है जिसे माना नहीं गया था, जो कि मेमोरी खपत है। डिफ़ॉल्ट स्टाइलट्रॉन इंजन (और फेला) परमाणु है। जबकि थोड़ा धीमा यह बहुत सारी मेमोरी को बचाता है। बहुत सारे रिएक्शन पेज देखने के बाद कुछ नहीं करते हैं और थोड़ी देर के बाद> 1GB हो जाते हैं। ब्राउज़र उसके बाद जमा देता है।

एक परमाणु ढांचे के प्रदर्शन के साथ वैश्विक स्तर पर समय के साथ घटकों में सुधार होता है, क्योंकि प्रत्येक परमाणु "वर्ग" को कैश किया जाता है। शायद परीक्षण में भी परिलक्षित नहीं हुआ।

जब तक यह SSR का समर्थन करता है तब तक खुश रहता है

मैंने मूल स्टाइल घटकों के मुद्दे से अपना वोट वापस ले लिया: पसीना_स्मिल: - पहली बार स्टोरीबुक के माध्यम से भावनाओं को जानना सीखा, लेकिन It will mean that all components styles need to be created using the styled API, which means for developers they will always have wrapper components if they need to re-style. मुझे स्विच करने के लिए मिला।

त्वरित प्रतिक्रिया के लिए सभी को धन्यवाद। यहाँ कुछ टिप्पणियों / प्रश्नों के उत्तर दिए गए हैं।

ब्रेकिंग परिवर्तनों के बारे में क्या, कौन सा विकल्प अधिक ब्रेकिंग परिवर्तनों (यदि कोई हो) का परिचय देता है?

@ sag1v styled-components vs emotion का उपयोग करके किसी भी अधिक या कम ब्रेकिंग परिवर्तनों को प्रस्तुत नहीं करता है जिन्हें हमें संभालने की आवश्यकता होगी। समग्र ब्रेकिंग परिवर्तन आसपास होंगे कि थीम के अंदर ओवरराइड कैसे दिखेंगे:

// previosly
root: {
  contained: {
    '&$disabled': { // <-- this part will need to be transformed
      color: 'red',
    },
  },
  containedPrimary: {
    color: 'blue',
  },
}

// after
root: {
  contained: {
     '&.Mui-disabled': {
      color: 'red',
    },
  },
}

हालाँकि, emotion & styled-components बीच की शैली वाक्य रचना समान है, इससे कोई फ़र्क नहीं पड़ेगा।

यकीन नहीं होता अगर इससे कोई फर्क पड़ता है लेकिन क्या बेंचमार्क भावनाओं और / या शैली-घटक के बैबल प्लगइन्स के साथ किया गया था? वे चीजों को और अधिक अनुकूलित करने में मदद करते हैं।

@ hc-codersatlas nope, लेकिन perfs वे हैं जो वैसे भी शीर्ष कुछ के बीच हैं, इसलिए मुझे विश्वास नहीं है कि इससे कोई फर्क पड़ेगा। अच्छी कॉल कठिन!

स्टाइलट्रॉन-रिएक्शन से इंकार क्यों किया गया? यह एक संपूर्ण मीट्रिक छोड़ता है जिसे माना नहीं गया था, जो कि मेमोरी खपत है। डिफ़ॉल्ट स्टाइलट्रॉन इंजन (और फेला) परमाणु है। जबकि थोड़ा धीमा यह बहुत सारी मेमोरी को बचाता है। बहुत सारे रिएक्शन पेज देखने के बाद कुछ नहीं करते हैं और थोड़ी देर के बाद> 1GB हो जाते हैं। ब्राउज़र उसके बाद जमा देता है।

एक परमाणु ढांचे के प्रदर्शन के साथ वैश्विक स्तर पर समय के साथ घटकों में सुधार होता है, क्योंकि प्रत्येक परमाणु "वर्ग" को कैश किया जाता है। शायद परीक्षण में भी परिलक्षित नहीं हुआ।

लगभग styletron-react मेरी टिप्पणी से इंकार किया गया था, उसके बारे में थोड़ा भ्रामक खेद हो सकता है, जो पीआर विवरण को अपडेट करेगा। परफेक्ट अच्छा है, लेकिन स्टाइलटरॉन के साथ मेरी सबसे बड़ी चिंता समुदाय है: https://www.npmtrends.com/styletron-react-vs-@emotion/core-vs- स्टाइल-कंपोनेंट जबकि भावना और स्टाइल-दोनों घटक पिछले 6 महीनों में 2000000 से अधिक डाउनलोड हुए हैं, स्टाइलट्रॉन लगभग 15000 है।

इसके अलावा परमाणु सीएसएस ओवरराइड के साथ समस्या पैदा कर सकता है, क्योंकि प्रत्येक क्लासनाम में केवल एक स्टाइलर नियम होता है।

मुझे एक प्रश्न मिला है कि क्या हम भावनाओं का उपयोग करने का निर्णय लेते हैं जिसे हम सभी फ़ाइलों के शीर्ष पर नीचे कोड जोड़ना चाहते हैं?
/ ** @ jsx jsx * /
यह JSX pragma है, डिफ़ॉल्ट रूप से JSX pragma React.createElement है

यदि आप css संपत्ति का उपयोग कर रहे हैं, तो आपको इसे जोड़ने की आवश्यकता है। styled API के साथ-साथ नियमित रूप से ClassName API के लिए आपको इसकी आवश्यकता नहीं है।

JSX pragma को जोड़ना छोड़ना संभव है, लेकिन इसके लिए अतिरिक्त बैबल सेटअप की आवश्यकता होती है और यह टूलिंग से भी बदतर समर्थन के साथ आता है - उदाहरण के लिए, TS आपके CSS प्रोप को ठीक से जाँचने में सक्षम नहीं है जैसा कि JSX pragma का उपयोग करते समय होता है। अधिक जानकारी यहां से प्राप्त की जा सकती है: https://github.com/emotion-js/emotion/pull/1941/files#diff -9abe25e5d2b00958d4b9849f5f20c139305

@mnajdova धन्यवाद मैं उम्मीद कर रहा था कि मेमोरी का उपयोग विशेष रूप से स्टाइलट्रॉन के लिए वाउचिंग से अधिक कवर किया गया है। डाउनलोड या समुदाय के रूप में - "केवल" Uber स्टाइलट्रॉन का उपयोग करता है :) इसलिए कोई चिंता नहीं है। पहली बार में भावना के लिए वोट दिया।

अगर वहाँ एक कोलाहल प्लगइन या समान है कि स्थिर शैलियों वास्तविक सीएसएस वर्गों में बदल सकता है शांत था। पहले से ही समान लाइब्रेरी compiled । वास्तविक रूप से अधिकांश शैलियाँ स्थिर हैं।

उपयोगी होने के लिए फेला को fela-plugin-rtl , fela-plugin-prefixer जैसे प्लगइन्स की आवश्यकता होगी जो प्रदर्शन को और भी बदतर बना देगा (https://github.com/microsoft/fluentui/pull/12289) will और फिर आप शायद भावनाओं के साथ समाप्त हो जाएंगे (https://github.com/microsoft/fluentui/pull/13547) कभी-कभी यह फेला F की तुलना में दो गुना तेज हो सकता है

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

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

उम्मीद है, उन दो एपीआई के लिए कोई परिवर्तन नहीं हुआ है, और मैं css मैक्रो का उपयोग करने के लिए मजबूर नहीं हूं।

मेरी एकमात्र चिंता भावना से सीएसएस चीज़ का उपयोग करने की है।

@yordis आप निश्चित रूप से css प्रोप का उपयोग करने के लिए मजबूर नहीं होंगे। मुझे संदेह है कि makeStyles और withStyles के usages के लिए कुछ परिवर्तन होगा। उम्मीद है कि आवश्यक परिवर्तन की मात्रा ज्यादातर आयात पर एक कोडमोड तक सीमित हो सकती है। मुझे नहीं लगता कि makeStyles या withStyles में उपयोग किया जाने वाला तरीका भावना का उपयोग करने के लिए समर्थन करने के लिए व्यावहारिक होगा, इसलिए मैं उन एपीआई के किसी भी चल रहे समर्थन को एक अलग पैकेज के माध्यम से होने की उम्मीद करूंगा (ताकि " @ सामग्री-ui / कोर "अब एक जेएसएस निर्भरता) जो शायद केवल न्यूनतम रखरखाव प्राप्त होगा के बाद v5 क्या करने के लिए होता चारों ओर जारी की है (विवरण के makeStyles और withStyles नीचे किसी न किसी नहीं कर रहे हैं अभी तक, इसलिए यह सिर्फ भावना के साथ आगे बढ़ने के निहितार्थ के बारे में मेरी अटकलें हैं)।

। भावना का उपयोग करने का विकल्प। styled API styled-components से बचने का एक कारण मेरी टीम ने इमोशन को चुना है (जो css प्रोप के अलावा समान styled API का समर्थन करता है)। हम वर्तमान में मटेरियल यूआई स्टाइल कस्टमाइजेशन के लिए इमोशन का उपयोग करते हैं और यह बहुत अच्छा काम करता है। समर्थन में निर्मित सिर्फ केक पर टुकड़े करना होगा।

इन तथ्यों के बारे में:

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

समवर्ती मोड का समर्थन करें
स्टाइल-घटक: आंशिक

यदि स्टाइल-घटकों को समवर्ती मोड के लिए पूर्ण समर्थन था, तो क्या यह अधिक समझदार विकल्प होगा, क्योंकि अधिकांश डेवलपर्स स्टाइल-घटकों (JSS को छोड़कर) के साथ MUI को ओवरराइड कर रहे हैं? बंडल साइज में छोटा होने के बारे में बात मूट है अगर 2 सीएसएस-इन-जे एस समाधानों को शामिल करने की आवश्यकता है। और मुझे लगता है कि एमयूआई के अधिकांश व्यावहारिक अनुप्रयोगों में इसकी शैलियों को शामिल किया जाएगा।

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

नीचे भावना स्टाइलल्डकम्पोनेंट पर विचार करें;

const StyledComponent = styled.div`
  ${({color}) => color && `color: ${color}`};
  display: flex;
  justify-content: center;
  align-items: center;
  background: teal;
  font-size: 20px;
  padding-top: 8px;
  padding-bottom: 8px;
  margin-top: 12px;
  margin-bottom: 12px;
  border: 1px solid grey;
`

जब रंग प्रोप बदलता है नया css क्लास सभी css प्रॉप्स ( display: flex, justify-content, ..., border: 1px soild grey ) से कॉपी किया जाता है। जिसके परिणामस्वरूप प्रत्येक कलर प्रोप के लिए ठीक उसी सीएसएस प्रॉप्स के साथ सीएसएस कक्षाएं होंगी, नीचे देखें;

एक और अक्षमता हमें मिली है, जब एक नया घटक StyledComponent से ऊपर से प्राप्त होता है, यह आधार सी StyledComponent से अधिक कॉपी किए गए सभी सीएसएस प्रॉप्स के साथ एक नया वर्ग बनाएगा। नीचे विचार करें;

const DerivedComponent = styled(StyledComponent)`
  font-family: monospace;
`

यह एक और सीएसएस वर्ग है कि केवल कहते हैं बनाता है font-family: monospace से उत्पन्न ऊपर सीएसएस वर्ग के लिए StyledComponent । यही है, यह एक ऐसी सीएसएस बनाता है जिसमें StyledComponent से कॉपी की गई सभी प्रॉप्स हैं जैसा कि नीचे देखा जा सकता है;

अब अगर StyledComponent और DerivedComponent का उपयोग एक साथ किया जाता है तो हमारे पास (शुरू में) दो css कक्षाएं होती हैं जिनमें डुप्लिकेट css प्रॉप्स होते हैं, (केवल फॉन्ट-फैमिली में भिन्न)। जैसा कि नीचे देखा जा सकता है;

जैसा कि आप कई सीएसएस वर्गों की कल्पना कर सकते हैं जिनके पास एक दूसरे के डुप्लिकेट सीएसएस प्रॉप्स हैं जो बहुत तेज़ी से बढ़ सकते हैं।

मैंने पाया कि भावना के साथ, जैसा कि घटक शैलियों को एक साथ बनाया गया है, हम कई डुप्लिकेट सीएसएस प्रॉप्स के साथ सीएसएस कक्षाओं के साथ समाप्त होते हैं।

मुझे यकीन नहीं है कि प्रत्येक सीएसएस वर्ग में सीएसएस प्रॉप्स के इस डुप्लिकेट का ऐप पर कोई ध्यान देने योग्य प्रभाव पड़ता है, लेकिन मुझे आश्चर्य है कि अगर यह भावना का उपयोग करने के लिए चुनने पर ध्यान में रखा जाता है।

मैं रन टाइम में CSSStyle बनाने और लगाने में इमोशन के प्रदर्शन पर सवाल नहीं उठा रहा हूं। इत्र परीक्षण में स्पष्ट रूप में CSSstyles को लागू करने पर सबसे तेज़ में से एक है।
मैं बस चिंतित हूँ जिसके परिणामस्वरूप सीएसएसस्टाइल फूला हुआ है। और जैसा कि इमोशन SSR (एड) हो सकता है, जिसका अर्थ है कि HTML में स्टाइल इनबिल्ट हैं, हम सिर्फ अनावश्यक रूप से फूला हुआ हो सकते हैं (सीएसएस स्टाइल टैग के साथ) HTML फाइल। जिसके परिणामस्वरूप ब्राउज़रों द्वारा अनावश्यक सीएसएस प्रॉप्स के साथ पार्स करने के लिए बहुत अधिक टैग मिलते हैं।

यदि स्टाइल-घटकों को समवर्ती मोड के लिए पूर्ण समर्थन था, तो क्या यह अधिक समझदार विकल्प होगा, क्योंकि अधिकांश डेवलपर्स स्टाइल-घटकों (JSS को छोड़कर) के साथ MUI को ओवरराइड कर रहे हैं? बंडल साइज में छोटा होने के बारे में बात मूट है अगर 2 सीएसएस-इन-जे एस समाधानों को शामिल करने की आवश्यकता है। और मुझे लगता है कि एमयूआई के अधिकांश व्यावहारिक अनुप्रयोगों में इसकी शैलियों को शामिल किया जाएगा।

@petermikitsh ने जिन कारणों से हम भावनाओं पर निष्कर्ष निकाला, वे वास्तव में निष्कर्ष में चार बिंदु हैं

• स्टाइल-घटकों और भावनाओं के बीच एक छोटा प्रवास लागत
  पहले से ही स्टाइल-घटकों का उपयोग करने वाले डेवलपर्स को लगभग किसी भी प्रयास के साथ भावना का उपयोग करने में सक्षम होना चाहिए।
• आवरण घटकों के अलावा ओवरराइड को जोड़ने के लिए अलग-अलग तरीके हैं
  भावना से cx + css का समर्थन डेवलपर्स के लिए फायदेमंद हो सकता है, अगर वे रैपर घटकों को बनाना नहीं चाहते हैं, तो स्टाइल ओवरराइड को जोड़ने के लिए एक विकल्प के रूप में इसका उपयोग करें।
• समवर्ती मोड सुनिश्चित समर्थित sure के लिए है
• कैसे विशिष्टता को संभाला जाता है

पहले बिंदु को ध्यान में रखते हुए, अगर डेवलपर्स वास्तव में बंडल में दो सीएसएस-इन-जेएस समाधान होने से बचना चाहते हैं, तो प्रवास लागत भावना के लिए आगे बढ़ने के लिए बहुत कम है + यह styled अलावा अन्य एपीआई का समर्थन करता है।

@ ko-toss यह लिखने के लिए धन्यवाद ये सभी अच्छे बिंदु हैं। यह तथ्य कि भावना सभी शैलियों के साथ एक वर्ग नाम उत्पन्न करती है, यह ओवरराइड्स को हल करने के लिए बेहतर इंजन बनाती है। कई वर्ग के नाम के कारण हमें जो समस्या हो सकती है, वह यह है कि लिखा गया अंतिम वर्ग जीत जाएगा, जो भविष्य में समस्याग्रस्त हो सकता है।

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

दूसरी ओर, मेरा मानना ​​है कि किसी भी css-in-js समाधान का उपयोग करके, लोग बेतरतीब ढंग से शैलियों के अनंत संयोजन का निर्माण नहीं करेंगे, वे अभी भी प्रॉपर मूल्य के आधार पर बहुत संरचित हैं।

हालांकि, फिर से ये अच्छे बिंदु हैं, कि हमारे मन में होगा, उन्हें साझा करने के लिए बहुत बहुत धन्यवाद these

• अन्य?

[स्टाइललेक्स] विचार संगतता के बारे में क्या है (जैसे [स्टाइल 9])

• अन्य?

स्टाइल 9 या कोई अन्य सीएसएस इंजन जो स्टाइललेक्स विचार के साथ संगत है

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

(यह बल्कि FYI है, भावना एक अच्छा विकल्प है)

https://github.com/cristianbote/goober (1kB, इमोशन से कम बुरा)

मुझे अभी तक इसका कोई अनुभव नहीं है लेकिन मैं एक दिन कोशिश करना चाहता हूं।

@cztomsik https://github.com/kuldeepkeshwar/filbert-js के समान है, लेकिन इसमें कोई जावास्क्रिप्ट सिंटैक्स समर्थन (केवल CSS टेम्पलेट स्ट्रिंग) नहीं है

यहां समय-समय पर बातचीत समय पर Google लाइटहाउस के साथ कुछ परीक्षण किए गए हैं:

https://jantimon.github.io/css-framework-performance/

FYI करें, मैंने स्टाइल-कंपोनेंट्स v5, इमोशन V10, और इमोशन v11 के कुछ विस्तृत बेंचमार्क को, वेनिला एपीआई, सीएसएस प्रॉपर एपीआई और स्टाइल एपीआई के साथ / बिना बबल प्लगइन के साथ किया है। आशा है कि यह चर्चा में मदद करेगा!

https://github.com/simnalamburt/css-in-js-benchmark

क्या आपने सीएसएस-इन-जेएस पुस्तकालयों की नई लहर पर विचार किया है जो परमाणु सीएसएस और टाइपस्क्रिप्ट समर्थन पर बहुत अधिक भरोसा करते हैं?

• https://github.com/modulz/stitches
• https://github.com/kripod/otion

क्या आपने सीएसएस-इन-जेएस पुस्तकालयों की नई लहर पर विचार किया है जो परमाणु सीएसएस और टाइपस्क्रिप्ट समर्थन पर बहुत अधिक भरोसा करते हैं?

• https://github.com/modulz/stitches

• https://github.com/kripod/otion

यह बेंचमार्क पर नहीं है, लेकिन वर्तमान में इमोशन भावना की तुलना में 2 ~ 4 गुना धीमा है। मुझे लगता है कि इमोशन में वास्तव में बहुत बड़ी क्षमता है और विश्वास है कि अनुकूलन के लिए एक जगह है, लेकिन इमोशन अभी तक उत्पादन के लिए तैयार नहीं है।

मैं हालांकि अभी तक टाँके का परीक्षण नहीं किया है। 😃

एक वास्तविक शून्य-रनटाइम लाइब्रेरी के बारे में क्या? मैंने किसी को लिनेरिया का उल्लेख नहीं करते देखा है।

मैं कुछ बिंदु पर लिनारिया में ठोकर खाई और मैं वास्तव में इसे पसंद करता हूं। इसके साथ मेरी एकमात्र चिंता यह है कि गतिकी शैली की शैली पूरी तरह से सीएसएस चर पर निर्भर करती है, और आईजी 11 के लिए कोई समर्थन नहीं है https://github.com/callstack/linaria/issues/445 पर आधारित styled-components की तुलना में emotion समुदाय इस समय बहुत छोटा है।

@TheHolyWaffle
लिनारिया कमाल का है।
Iff आपने इसे ठीक से सेट किया है, मेरा मानना ​​है कि यह css-in-js (देव अनुभव के संदर्भ में) और शुद्ध css (शुद्ध css प्रदर्शन को नहीं हरा सकता) दोनों में से सबसे अच्छा है। यह सीएसएस नियमों का भी अनुकूलन करता है।
लेकिन लिनारिया को बिल्ड और बंडलिंग कदम की आवश्यकता होती है जो शुरुआती लोगों के लिए कठिन होगा।

मैं इसी तरह एपीआई सतह जैसे के साथ अन्य सीएसएस-इन-js पुस्तकालयों के लिए बंदरगाहों को देखने के लिए प्यार होता हेज़लनट-js / goober

@kuldeepkeshwar हम आपको स्टाइल एपीआई के लिए एडेप्टर देखने के बाद आपको बताएंगे :)

Https://compiledcssinjs.com/ इस सब में कैसे फिट बैठता है? यह एक अविश्वसनीय रूप से दिलचस्प दृष्टिकोण प्रतीत होता है; संकलित परियोजना के लिए RFC भी चलाता है, जो खुले स्रोत और सहयोग के लिए महान साबित होता है। _आँख झपकना_

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

संकलित कार्य मुझे

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

_CSS रनटाइम पर उत्पन्न नहीं किया जा सकता है ।_

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

एक अलग पक्ष पर ध्यान दें, मैं यह बताना चाहूंगा कि लोकप्रियता एक अच्छी परियोजना के लिए बहुत मायने नहीं रखती है। मुझे MUI और उस काम से प्यार है जो इस प्रकार अब तक चला आ रहा है; मुझे भी लगता है कि यह शानदार है यह एक प्रीमियम उत्पाद बन गया है।
लेकिन लोकप्रियता के लिए 'लोकप्रिय' _name_ चुनना उचित तर्क नहीं है।
मैंने लोकप्रियता को कई बार संदर्भित किया है, और मुझे यह भी बहुत नापसंद है कि क्या एक्स राशि का उपयोग करने वाले लोग x तकनीक का उपयोग करते हैं - MUI है (मेरी पुस्तकों में) प्रदर्शन, डीएक्स, और अन्य चीजों पर ध्यान केंद्रित किया गया है, केवल लोकप्रियता नहीं।

MUI में हमेशा 60k सितारे नहीं थे, यह उन्हें मिला क्योंकि इसने सबसे अच्छी तकनीक (या करीब) को चुना, इसलिए नहीं कि इसने लोकप्रिय तकनीक को चुना।

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

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

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

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

मैं उत्सुक हूँ अगर संकलित भी एक विकल्प है और यह कैसे एडेप्टर और इस तरह के साथ काम करेगा। मुझे लगता है कि संकलित दृष्टिकोण:

संकलित जेएस में अपने सीएसएस को अपने कोड का सांख्यिकीय रूप से विश्लेषण करके और फिर इसे संकलित घटकों में परिवर्तित करके संकलित करता है। सब कुछ हम घटक का उपयोग करने की जरूरत है यह जावास्क्रिप्ट बंडल में पक्ष के साथ शामिल है।

सोचने का एक रास्ता है, रनिंग की कमी पर पूरे संकलन 'सीएसएस' को देखते हुए।

मैं इसे इमोशन मेंटेनर के रूप में कह रहा हूं - संकलित महान है। या बल्कि - यह भविष्य में हो सकता है, यह बहुत रोमांचक सामान है लेकिन यह अभी भी प्रयोग में काफी जल्दी है। मुझे बहुत संदेह है कि MUI इस समय इस बिंदु पर जा सकता है।

मुझे सही है अगर मैं गलत हूँ, लेकिन संकलित होने का तात्पर्य एक विन्यास से है जिसका अर्थ है कि किसी भी कस्टम शैलियों का उपयोग किए बिना भी MUI के लिए एक विन्यास फाइल रखना अनिवार्य होगा।

मैं सिर्फ MUI का उपयोग करने के लिए एक विन्यास बनाने के लिए मजबूर होने से नफरत करता हूँ। एक साइड नोट पर: क्रिएट रिएक्ट ऐप जैसे रायशुदा बूटस्ट्रैपर्स में उपयोग करना कठिन नहीं होगा?

@ भारतवासी मैं पूरी तरह सहमत हूँ। मैं एक सहयोग शुरू करने या कम से कम पुस्तकालय के विकास में भाग लेने पर विचार करने का सुझाव दूंगा। मैं इस बारे में जिज्ञासु हूँ कि यह भविष्य में कहाँ ले जा सकता है! : आँखें: मुझे लगता है कि कुछ संकलित है - जैसा कि आप कह रहे हैं - भविष्य में महान होने जा रहा है। यह बहुत बढ़िया होगा कि कुछ शानदार बनाने के लिए अधिक महान दिमाग एक साथ मिलें।

@shilangyu मुझे यकीन नहीं है कि आप क्या कर रहे हैं, क्योंकि मुझे कुछ याद आ रहा है। तो मैं बस इतना ही कहूंगा कि संकलित किए गए

शून्य कॉन्फ़िगरेशन वास्तविकता पर माइग्रेट करें

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

बस शुरुवात है

शून्य शून्य आउट-ऑफ-द-बॉक्स के साथ, हम यह नहीं भूल रहे हैं कि कल क्या दिख सकता है। वैकल्पिक सीएसएस निष्कर्षण की संभावना के साथ, सीएसएस को परमाणु रूप में बदलना, और यहां तक ​​कि हमारे कोड आधार पर विश्लेषण के लिए सीएसएस डेटा का उपयोग करने में सक्षम होने के कारण, हम कल एक रोमांचक सोच रहे हैं।

@MathiasKandelborg
मैंने https://compiledcssinjs.com/ के माध्यम से स्किम्ड किया। क्या यह अभी भी रन-टाइम css-in-js नहीं है?
यह बिल्ड समय पर सीएसएस कक्षाएं बनाता है लेकिन यह उस शैली पर लागू होता है (रन टाइम के साथ बिल्ड टाइम उत्पन्न सीएसएस कक्षाओं के साथ स्टाइल टैग बनाता है) रनटाइम पर <CC>...</CC> टैग के साथ।
यदि यह केवल शुद्ध सीएसएस का उपयोग करने के रूप में तेज़ है तो यह वास्तव में भविष्य है (क्योंकि यह सीएसएस चर का उपयोग करता है)। साझा करने के लिए धन्यवाद
मुझे आश्चर्य है कि यह भावना की तुलना में कितना तेज है।

एक वास्तविक शून्य-रनटाइम लाइब्रेरी के बारे में क्या? मैंने किसी को लिनेरिया का उल्लेख नहीं करते देखा है।

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

इसलिए जबकि शून्य-रनटाइम संभवतः सबसे तेज़ समाधान है, इसके लिए अतिरिक्त ध्यान देने की भी आवश्यकता है। एक शून्य-कॉन्फ़िगरेशन समाधान होना जिसे शून्य-रनटाइम के साथ चलाने के लिए कॉन्फ़िगर किया जा सकता है, आदर्श होगा जो मुझे लगता है।

इसलिए जबकि शून्य-रनटाइम संभवतः सबसे तेज़ समाधान है, इसके लिए अतिरिक्त ध्यान देने की भी आवश्यकता है। एक शून्य-कॉन्फ़िगरेशन समाधान होना जिसे शून्य-रनटाइम के साथ चलाने के लिए कॉन्फ़िगर किया जा सकता है, आदर्श होगा जो मुझे लगता है।

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

तो योग करने के लिए - यदि आप 0config इमोशन (या स्टाल्ड कंपोनेंट्स) के साथ जाते हैं तो भविष्य में एक वैकल्पिक ऑप्टिमाइजेशन के रूप में कंपाइल को एडॉप्ट करना संभव हो सकता है (यदि प्रोजेक्ट जो वादा करता है उसे डिलीवर करने के लिए मैनेज करेगा)

@ ko-toss मुझे लगता है कि यह निर्मित समय में स्टाइल घटक में संकलित है। रनटाइम के दौरान, घटक से शैलियों को फिर उनके सही स्थान पर ले जाया जाता है।

जैसा कि वे वेबपेज पर कहते हैं:

सब कुछ हम घटक का उपयोग करने की जरूरत है यह जावास्क्रिप्ट बंडल में पक्ष के साथ शामिल है।

हम आपका प्रारंभिक कोड इसकी महिमा में लेते हैं:

import { styled } from '@compiled/css-in-js';

export const ColoredText = styled.span`
  color: #ff5630;
`;

और फिर इसे एक संकलित घटक में बदल दें:

...
...

जो तब रनटाइम पर डॉक्यूमेंट्स को हेड के पास ले जाएगा।

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

सीएसएस रनटाइम पर उत्पन्न नहीं किया जा सकता है।

एक शून्य-कॉन्फ़िगरेशन समाधान होना जिसे शून्य-रनटाइम के साथ चलाने के लिए कॉन्फ़िगर किया जा सकता है, आदर्श होगा जो मुझे लगता है।

मुझे लगता है कि आपने बिलकुल सटीक जगह वार किया। यह स्वप्न में अचानक सपना देखने के लिए अचानक महसूस होगा।

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

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

IE11 समर्थन के संबंध में, आप आँकड़े कैसे देख रहे हैं? मुझे यकीन है कि यह पूरी तरह से व्यवहार्य बात है। एज अब क्रोमियम पर आधारित है, और अधिकांश व्यवसायों को स्विच बनाना चाहिए जब एमएस अंततः IE के लिए समर्थन बंद कर

यह अच्छा होगा कि IE11 का समर्थन करने का विकल्प न हो। यह अब उद्योग मानक नहीं है, और इसे हटा दिया

यह अच्छा होगा कि IE11 का समर्थन करने का विकल्प न हो।

उसके लिए https://github.com/mui-org/material-ui/issues/14420 देखें।

हम IE के लिए समर्थन को पूरी तरह से छोड़ने की योजना नहीं बनाते हैं। डिफ़ॉल्ट संस्करण की संभावना IE 11 को v5 में लक्षित नहीं करेगी, लेकिन हम एक ऐसा समाधान नहीं चुन सकते जो IE 11 में बिल्कुल काम नहीं करेगा। या यह एक समाधान होना चाहिए कि हम बिल्ड समय पर स्वैप कर सकें और उसी का उत्पादन करें उत्पादन।

यह मझे खुश करता है।

क्या मुझे आश्चर्य है कि मौजूदा jss को स्टाइल / इमोशन में बदलने के लिए एक कोड मॉड है?

सभी को नमस्कार। मैं इस चर्चा में आने का अवसर ले रहा हूं।

वर्तमान संस्करण में, मटेरियल यूआई बिना किसी डायनेमिक स्टाइल (स्टाइल जो कि फंक्शन पर निर्भर करता है) के बिना withStyles HOC का भारी उपयोग करता है, जो आंतरिक रूप से makeStyles का उपयोग करता है। makeStyles (डायनेमिक प्रॉप्स के बिना) का प्रदर्शन काफी उल्लेखनीय है और भौतिक यूआई और भी तेज हो सकता है अगर यह सीधे withStyles बजाय इसका उपयोग कर रहा था, जो एक अनावश्यक आवरण बनाता है।

मैंने इस बेंचमार्क का एक बेंचमार्क बनाया है , और मैंने इसे वर्सेल में तैनात किया है, ताकि सभी कोड उत्पादन झंडे के साथ संकलित हो। बेंचमार्क JSS पुस्तकालयों में विभिन्न CSS का उपयोग करके कार्ड प्रदान करता है। यहाँ लिंक हैं:

100 कार्ड के लिए :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=100
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=100
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-compenders&cards=100

500 कार्ड के लिए :

• makeStyles : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=mui-make-styles&cards=500
• emotion : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=emotion-styled&cards=500
• styled-components : https://csb-5z6e2-lh4u8acll.vercel.app/?cases=styled-compenders&cards=500

2500 कार्ड के लिए :

• makeStyles : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=mui-make-styles&cards=2500
• emotion : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=emotion-styled&cards=2500
• styled-components : https://csb-5z6e2-fqtfkzcrk.vercel.app/?cases=styled-compenders&cards=2500

कुल मिलाकर, emotion और styled-components प्रदर्शन में बहुत समान हैं। हालांकि, makeStyles माउंट पर 2-4x तेजी से लगता है और अद्यतनों के लिए 6-8x तेज होता है।

अंतर काफी महत्वपूर्ण है, खासकर जब हम कम-शक्ति वाले उपकरणों, जैसे हमारे फोन पर प्रदान कर रहे हैं .. और वहां बहुत सारे भद्दे फोन हैं।

यह सब कहने के लिए कि मैं सामग्री प्रवासन के बारे में emotion का उपयोग कर रहा हूं , जो 3-5x कारक द्वारा उपयोग करने वाले सामग्री UI और साइटों के प्रतिपादन के प्रदर्शन को (यह वास्तव में सच नहीं है, यह घटक पर निर्भर करता है; जितना अधिक जटिल होगा, उतना कम अंतर होगा)।

कुछ प्रश्न और विचार के लिए भोजन:

• क्या DX वास्तव में UX ट्रेडऑफ़ के लायक है? यहां तक ​​कि DX डिबेटेबल है क्योंकि कई लोग makeStyles पसंद करते हैं
• makeStyles की समस्या गतिशील शैलियों के साथ है, जो नियतात्मक कैश आईडी को लागू करने से ठीक होने लगती है। वर्तमान में, हर घटक उदाहरण को गतिशील प्रॉप्स के लिए अपनी स्वयं की आईडी मिलती है, भले ही प्रॉप्स और आउटपुट स्टाइल समान हों, जिससे रनटाइम ओवरहेड, सिर में कई स्टाइल टैग और एसएसआर प्रदर्शन में कमी आए। गतिशील शैलियों के लिए हैशिंग रणनीति का उपयोग करके तय किए गए लगता है, जैसे जेएस के कई अन्य सीएसएस लिबास में कर रहे हैं। संबंधित: https://github.com/mui-org/material-ui/pull/16858
• क्या emotion और styled-components पास में सुधार के लिए कोई स्थान है, या makeStyles से बेहतर भी हो सकता है?
• क्या सामग्री UI एक आधिकारिक जेएसएस इंजन एडॉप्टर का समर्थन करेगा ताकि डेवलपर्स इसे अधिक प्रदर्शन के लिए चुन सकें?

मैं एक छोटे से प्रदर्शन के नुकसान के साथ रह सकता हूं।

300% प्रदर्शन हानि नहीं, किसी भी कीमत पर नहीं। 😅

@satazor इस खोज के लिए धन्यवाद। हमने इस प्रयास को शुरू करने से पहले एक भारी परिक्षण किया था, अधिक विवरण के लिए PR https://github.com/mui-org/material-ui/pull/22173 देखें (हमने इसे ListItem घटक पर किया था) और पूर्ण अंतर था उत्पादन मोड में x1000 उदाहरण प्रस्तुत करने के लिए सबसे अधिक

https://deploy-preview-22173--material-ui.netlify.app/performance/list-raw/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-mui/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled/

https://deploy-preview-22173--material-ui.netlify.app/performance/list-styled-wrapper/

• Https://github.com/mui-org/material-ui/pull/22173#issuecomment -673486269 से कॉपी किया गया

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

निश्चित नहीं है कि आपके बेंचमार्क पर क्या हो रहा है, लेकिन 3-5x मुझे बहुत अधिक लगता है, यह मुझे आश्चर्यचकित करता है कि कोई भी emotion / styled-compoenents यदि यह मामला था .. हम कोशिश कर सकते हैं यह देखने के लिए कि दो बेंचमार्क के बीच अंतर कहां है, मामले में हम कुछ याद कर रहे हैं। इसके अलावा, वास्तविक एमयूआई घटक पर बेंचमार्क करना मेरे विचार में बहुत बेहतर होगा, इसलिए हमें अधिक यथार्थवादी संख्याएं मिलेंगी, इसलिए मुझे बताएं कि क्या आप इस तरफ अधिक अन्वेषण करना चाहते हैं। मेरे द्वारा जोड़ा गया PR एक अच्छा प्रारंभिक बिंदु है।

उत्तर @mnajdova के लिए धन्यवाद। आप सही हैं कि मुई घटक पर परीक्षण अधिक यथार्थवादी होगा। शायद यह हो रहा है कि सूची घटकों के लिए मुई कोड प्रमुख धीमापन कारक है, और उनके बीच अंतर (~ 30ms) शैलियों के साथ जुड़े वास्तविक प्रतिपादन समय अंतर है। मैं उस पीआर का कोड ले लूंगा और बेंचमार्क में जोड़ दूंगा, परिणाम देखने के लिए।

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

जो सामग्री UI और साइटों का प्रतिपादन प्रदर्शन घटाकर 3-5x कारक का उपयोग करेगा।

आपने एक ऐसा मानदंड बनाया है जिसमें यह कारक है। यह पालन नहीं करता है कि हर एक घटक इस कमी को दिखाएगा। कृपया इस भ्रामक जानकारी से बहुत आसानी से फैलने वाली भ्रामक जानकारी फैलने के बाद से निष्कर्ष पर जाने से बचने की कोशिश करें।

Devtools एक्सटेंशन का उपयोग करके मैंने मेक सिटल्स के साथ माउंट के लिए भावना बनाम 120ms के साथ माउंट के लिए 140ms देखा।

आपने एक ऐसा मानदंड बनाया है जिसमें यह कारक है। यह पालन नहीं करता है कि हर एक घटक इस कमी को दिखाएगा। कृपया इस भ्रामक जानकारी से बहुत आसानी से फैलने वाली भ्रामक जानकारी फैलने के बाद से निष्कर्ष पर जाने से बचने की कोशिश करें।

आप सही हैं, मेरी पिछली टिप्पणी देखें।

आपने एक ऐसा मानदंड बनाया है जिसमें यह कारक है। यह पालन नहीं करता है कि हर एक घटक इस कमी को दिखाएगा। कृपया इस भ्रामक जानकारी से बहुत आसानी से फैलने वाली भ्रामक जानकारी फैलने के बाद से निष्कर्ष पर जाने से बचने की कोशिश करें।

Devtools एक्सटेंशन का उपयोग करके मैंने मेक सिटल्स के साथ माउंट के लिए भावना बनाम 120ms के साथ माउंट के लिए 140ms देखा।

मैं उपयोग करने के लिए बेंचमार्क को नवीनीकृत किया है actualDuration के बजाय baseDuration , इसलिए हम अब क्या DevTools प्रोफाइलर में दिखाया गया है के साथ और अधिक इनलाइन मूल्यों को देखना चाहिए। baseDuration संस्मरण के बिना समय को मापता है, जबकि actualDuration विपरीत है। कृपया ध्यान दें कि यह परिवर्तन केवल रेंडरर प्रदर्शन को प्रभावित करता है, और अब मैं रेंडर्स के लिए makeStyles 6-8x तेज़ी से देख रहा हूं, जिसका अर्थ है कि यह कैशिंग / मेमोइज़ेशन बेहतर है? हालाँकि, मुझे आपके द्वारा देखे जा रहे मान नहीं मिल रहे हैं। क्या आप अद्यतन लिंक के साथ कोशिश कर सकते हैं?

@satazor मुझे नहीं लगता कि आपके परीक्षण के मामले समकक्ष हैं। हमें अच्छा होना चाहिए।

परिवर्तनों के एक जोड़े को आप यह समझने की कोशिश कर सकते हैं कि और प्रदर्शन के अंतर को कम करेगा:

• बढ़ते प्रतिक्रिया घटकों में एक लागत होती है, खासकर जब उनमें से बहुत से प्रतिपादन करते हैं। makeStyles सीधे div का उपयोग करता है जबकि भावना / sc नए घटक बनाते हैं। हमारे टेबल बेंचमार्क में, मैंने अनुभव किया है कि प्रत्येक जोड़ घटक बेसलाइन रेंडरिंग टाइम को जोड़ता है, इसलिए यदि घटकों के 3 स्तर => x3 (या <MenuItem> <li> की तुलना में लगभग x10 धीमा क्यों है)।
• MakeStyles के साथ आपका डेमो एक एकल स्टाइलशीट बनाता है, भावना / sc नहीं। प्रत्येक कार्ड कंटेनर में आइटम को लक्षित करने के लिए सीएसएस चयनकर्ताओं के साथ एकल स्टाइलशीट का उपयोग करने का प्रयास करें। या इसके विपरीत, मुख्य मेक स्टाइल स्टाइलशीट को एक से अधिक, एक आइटम में तोड़ना।

दरअसल, @oliviertassinari ऐसा लगता है कि भावनाएं / स्टाइल-घटकों के साथ आगे बढ़ने वाला प्रदर्शन 1.5x-2x कारक अधिकतम में सरल घटकों के लिए भी अधिक है, जैसे Typography , जो मैंने यहां लागू किया है: https://codesandbox.io/ एस / सीएसएस-इन-js-तुलना-कांटेदार-lr3sr? फ़ाइल = / src / घटकों / EmotionTypography.js।

प्रोडक्शन बिल्ड और बेंचमार्क की जाँच करें: https :

makeStyles 1.5-2x माउंट पर तेज़ और 3-4x तेज़ी से रेंडरेंडर्स पर है। यह संभावित रूप से कुछ पर नज़र रखने के लिए है, लेकिन मुझे लगता है कि विचलन अधिक जटिल घटकों के लिए बहुत छोटा होगा।

इसलिए, निष्कर्ष में, मैं अब प्रदर्शन के बारे में

@mnajdova यहां लिस्ट टेस्ट के लिए प्रोडक्शन बिल्ड: https://csb-lr3sr-3zi42510w.vercel.app/?compords=1000 , आपके द्वारा उल्लिखित पीआर की कॉपी दी गई है। कोडैंडबॉक्स लिंक: https://codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStyles माउंट पर 1.7x तेज़ी से लगता है, और रेंडरर पर 2.2x तेज़। मुझे आपके द्वारा देखे जा रहे 10% अंतर नहीं मिल रहा है। क्या मुझसे कुछ गलत हो रही है?

@satazor दिलचस्प है, इसे एक साथ रखने के लिए धन्यवाद। मैंने इस बेंचमार्क का उपयोग # 22435 के प्रदर्शन की तुलना करने के लिए किया है

import Slider from '@material-ui/core/Slider';

बनाम (भावना)।

import SliderStyled from '@material-ui/lab/SliderStyled';

बनाम (स्टाइल-घटकों)।

import SliderStyled from '@material-ui/lab/SliderStyled';

इस बिंदु पर, यह बताना मुश्किल है कि यह धीमा क्यों है। शैलियों पर अड़चन नहीं हो सकती है। और मन है कि मैंने इसे देव विधा में चलाया है run!

मैंने स्लाइडर के WIP भावना संस्करण के प्रदर्शन पर एक नज़र डालने के लिए दो नए पृष्ठ जोड़े हैं:

• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-emotion/
• https://deploy-preview-22435--material-ui.netlify.app/performance/slider-jss/

एक बार उत्पादन के लिए बनाए जाने के बाद, आंकड़े https://github.com/mui-org/material-ui/issues/22342#issuecomment -697540546 के समान प्रतीत होते हैं, यह X1.6 धीमी (लेकिन CSS पूरी तरह गतिशील है) के बारे में है। ध्यान दें कि आप इसके साथ WIP भावना संस्करण खेल सकते हैं:

• भावना : https://codesandbox.io/s/headless-shadow-fn41t?file=/package.json

• स्टाइल-घटक : https://codesandbox.io/s/preact-material-ui-test-forked-lum1y?file=/src/index.tsx @mnajdova sc के लिए, मुझे पार्सल का उपयोग करना था, मैं उपयोग नहीं कर सका। CRA का खाका।

इसके अलावा, ध्यान दें कि हम जानते हैं कि हम वर्तमान JSS संस्करण X1.1 को तेजी से बनाने के बजाय withStyles का उपयोग करके कर सकते हैं: # 15023।

ठग मोड में

यह देखते हुए कि कैसे makeStyles लागू किया जाता है, मैं देखता हूं कि जब आप सिर्फ स्थैतिक शैलियों का उपयोग करते हैं तो यह कितना तेज होता है:

1. प्रत्येक माउंट पर, attach को बुलाया जाता है।
2. यदि यह उस घटक प्रकार का पहला उदाहरण है, तो stylesCreator.create कहा जाता है, जो बदले में fn को makeStyles(fn) में निर्दिष्ट करता है।
3. हर दूसरे उदाहरण पर, stylesCreator.create छोड़ दिया जाता है क्योंकि रेफरी संख्या 0 है।

रेंडरर्स के लिए:

1. प्रत्येक रेंडरर पर, attach कॉल किया जाता है।
2. बाद में, stylesCreator.create छोड़ दिया जाता है क्योंकि ref count> 0 है, इसलिए कोई भी काम बिल्कुल नहीं किया जाता है।

कृपया ध्यान दें कि यदि गतिशील शैलियों को खेलने में है, तो शीट को हर माउंट और रेंडर पर यहां अपडेट किया गया होगा।

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

     const someContext = useContext(FooContext);

    return <div css={ { paddingTop: someContext.padding(1) } }>;

यदि मेरी धारणाएं सही हैं, तो स्थैतिक शैलियों के लिए makeStyles का प्रदर्शन स्तर तक पहुंचना बहुत कठिन होगा, जिस तरह से यह काम करता है और एपीआई को कैसे डिज़ाइन किया जाता है, अनुकूलन के लिए अनुमति देता है कि styled या css API नहीं कर सकते।

मुझे कुछ संभावित दिशाएँ दिखाई देती हैं जिनका हम पता लगा सकते हैं:

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

अगर किसी तरह emotion useCss हुक जैसा कि यह https://github.com/emotion-js/emotion/issues/1321 और https://github.com/emotion- में अनुरोध किया गया था makeStyles API और इसके परिणामस्वरूप, "सीएसएस सीएसएस" के लाभ को बनाए रख सकते हैं। हालांकि, हम प्रदर्शन को बढ़ावा देने के लिए हर जगह स्टेटिक सीएसएस का उपयोग करते रहेंगे, जो इतना "साफ" नहीं है, लेकिन यही हम पहले से ही v4 में कर रहे हैं।

दरअसल, ClassNames API के साथ, मुझे लगता है कि हम अभी withStyles का एक पोर्ट कर सकते हैं, जो स्टैटिक CSS perf के लाभों और भावनाएं वाले गतिशील CSS के अच्छे प्रदर्शन को बनाए रखेगा। यदि const css = useCss() अस्तित्व में है, तो यह useStyles API पोर्ट बनाने के लिए भी सरल होगा।

withStyles + makeStyles API रखने के मुख्य लाभ जो हुड के नीचे भावना का उपयोग करते हैं:

• प्रवासन जो सामग्री को करना है वह व्यावहारिक रूप से कोई भी नहीं है, हमें केवल उन 2 कार्यों का पोर्ट बनाने की आवश्यकता होगी।
• पहले से ही सामग्री UI के बाहर withStyles और makeStyles का उपयोग करने वाले उपयोगकर्ताओं को बिल्कुल भी माइग्रेट करने की आवश्यकता नहीं होगी। उन्हें गतिशील सीएसएस के लिए बेहतर प्रदर्शन का लाभ मुफ्त में मिलेगा।
• classes + CSS API रखने के लिए किसी अतिरिक्त तर्क की आवश्यकता नहीं है। styled हमें हाथ से या उपयोग के साथ वैश्विक className s बनाने की आवश्यकता होगी।
• इस रणनीति में, useCss के बजाय, जे एस समाधान में सीएसएस के लिए हमारे एडाप्टर समारोह है styled ।
• जेएस समाधानों में अन्य सीएसएस का समर्थन करने के लिए, उन्हें एक यूसेजसी हुक या समान प्रदान करने की आवश्यकता होगी। आदर्श रूप से, हम styled तरह उन्हें बदलने के लिए webpack / babel aliasing करने में सक्षम होंगे।

हमने https://twitter.com/olivtassinari/status/1309247827839680512 पर आगे प्रदर्शन के मुद्दे की खोज की है

• देशी: 7.71ms
• v5 अस्थिर: 20.89ms
• v4: 29.93ms
• v5: 37.37ms
• atd: 53.48ms
• चक्र: ६४.६ms मी

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

खेद है कि मैं आपको चर्चा में इतनी देर से परेशान करता हूं, लेकिन मैं थोड़ा आश्चर्यचकित हूं कि आप स्टाइल-जेएक्स पर बारीकी से नहीं देख रहे हैं

उनकी सूची आपकी आवश्यकताओं को पूरा करती है:

• सर्वर और क्लाइंट काम करता है
• पूर्ण सीएसएस समर्थन, सत्ता में कोई ट्रेडऑफ़ नहीं
• सिर्फ 3kb का रनटाइम आकार (gzipped, 12kb से)
• पूर्ण अलगाव: चयनकर्ता, एनिमेशन, कीफ्रेम
• अंतर्निहित सीएसएस विक्रेता उपसर्ग
• बहुत तेज, न्यूनतम और कुशल वाष्पीकरण (नीचे देखें)
• सर्वर-रेंडरिंग न करने पर उच्च-प्रदर्शन रनटाइम-सीएसएस-इंजेक्शन
• भविष्य-प्रूफ: सर्वर-रेंडर करने योग्य "शैडो सीएसएस" के बराबर
• स्रोत मानचित्र समर्थन करते हैं
• गतिशील शैलियों और विषयों का समर्थन करते हैं
• सीएसएस Preprocessing प्लगइन्स के माध्यम से

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

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

@mifrej मैं व्यक्तिगत रूप से इसके साथ एक बुरा अनुभव था: https://github.com/vercel/styled-jsx/issues/142।

हमने https://twitter.com/olivtassinari/status/1309247827839680512 पर आगे प्रदर्शन के मुद्दे की खोज की है

• देशी: 7.71ms
• v5 अस्थिर: 20.89ms
• v4: 29.93ms
• v5: 37.37ms
• atd: 53.48ms
• चक्र: ६४.६ms मी

https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/src/App.js…

क्या आपने भावना / स्टाइल-घटकों के लिए बैबल प्लग इन की कोशिश की? क्या इससे टाइमिंग पर फर्क पड़ा?

JSS से क्या परिवर्तन मौजूदा MUI घटकों पर उपलब्ध classes प्रोप के लिए होगा? V5 माइग्रेशन उन मौजूदा उपयोगकर्ताओं के लिए कैसा लगेगा जो इस प्रोप का बड़े पैमाने पर लाभ उठाते हैं?

हम इसके बजाय निम्नलिखित सिंटैक्स का उपयोग करने के लिए लोगों को कल्पना करते हैं: https://next.material-ui.com/compenders/slider-styled/#unstyled -slider कक्षाएं मूल रूप से घटक में प्रत्येक स्लॉट के लिए उपलब्ध वर्ग चयनकर्ताओं द्वारा प्रतिस्थापित की जाती हैं। आप अनुकूलन उदाहरण पर भी एक नज़र डाल सकते हैं: https://next.material-ui.com/compenders/slider-styled/#customized -sliders

एक फ़ायदे के तौर पर आप बस प्रॉपर का इस्तेमाल कर सकते हैं और उनके आधार पर डायनेमिक स्टाइल लागू कर सकते हैं।

हम इसके बजाय निम्नलिखित सिंटैक्स का उपयोग करने के लिए लोगों को कल्पना करते हैं: https://next.material-ui.com/compenders/slider-styled/#unstyled -slider कक्षाएं मूल रूप से घटक में प्रत्येक स्लॉट के लिए उपलब्ध वर्ग चयनकर्ताओं द्वारा प्रतिस्थापित की जाती हैं। आप अनुकूलन उदाहरण पर भी एक नज़र डाल सकते हैं: https://next.material-ui.com/compenders/slider-styled/#customized -sliders

एक फ़ायदे के तौर पर आप बस प्रॉपर का इस्तेमाल कर सकते हैं और उनके आधार पर डायनेमिक स्टाइल लागू कर सकते हैं।

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

v5 , अगर मुझे सही तरीके से याद है, तो JSS संकलक उन वर्ग नामों को संरेखित करेगा और आप उन्हें लक्षित नहीं कर सकते? लेकिन अब ऐसा लगता है कि वे लक्षित उद्देश्यों के लिए सामने आएंगे? 🙌 इसके अलावा, सीएसएस पूर्वता के साथ समस्या थी। और उन चिंताओं को इस नए दृष्टिकोण के साथ हल किया जाता है? इस रिफ्लेक्टर पर काम करने के लिए धन्यवाद!

@ConAntonakos वास्तव में इन वर्गों को घटकों के अस्थिर और स्टाइल वाले दोनों संस्करणों के लिए लक्षित किया जा सकता है। जिस क्रम में स्टाइल किया जाता है, यह सुनिश्चित करता है कि नई शैली जीत जाएगी, निश्चित रूप से अगर विशिष्टता समान है :)

V5 से पहले, अगर मुझे सही ढंग से याद है, तो JSS कंपाइलर उन क्लास नामों को मसल देगा और आप मज़बूती से उन्हें निशाना नहीं बना सकते हैं?

आप पहले से ही उन्हें v4 में लक्षित कर सकते हैं।

कक्षाएं मूल रूप से घटक में प्रत्येक स्लॉट के लिए उपलब्ध वर्ग चयनकर्ताओं द्वारा प्रतिस्थापित की जाती हैं।

क्या वे "मूल रूप से" प्रतिस्थापित या वास्तव में प्रतिस्थापित हैं? मुझे लगा कि हमने ब्रेकिंग परिवर्तनों की संख्या को कम करने के लिए कुछ पुराने एपीआई रखने का फैसला किया है।

मुझे लगा कि हमने ब्रेकिंग परिवर्तनों की संख्या को कम करने के लिए कुछ पुराने एपीआई रखने का फैसला किया है।

हमने उसी API को theme.components.overrides लिए रखने का निर्णय लिया - उसी तरीके से थीम कार्य में परिभाषित ओवरराइड्स।

उदाहरण के लिए ओवरराइड करने के लिए, हमारे पास styled वर्ग के चयनकर्ताओं के साथ अब दृष्टिकोण है, यही कारण है कि classes प्रोप अब समर्थित नहीं है। डेवलपर्स अब और अधिक लचीले ढंग से ऐसा कर सकते हैं।

डेवलपर्स अब और अधिक लचीले ढंग से ऐसा कर सकते हैं।

ऐसा लगता है कि यह एक ऐसा मामूली मुद्दा है क्योंकि इसके लिए एक विकल्प है लेकिन इसके लिए माइग्रेशन लागत बहुत बड़ी है। माइग्रेशन प्लान कैसा दिखता है?

डेवलपर्स अभी भी थीम ओवरराइड्स का उपयोग कर सकते हैं, अगर वे उदाहरण को केवल एक नेस्टेड ThemeProvider पर ले जाते हैं, तो उन्हें उन सभी शैलियों को बदलने की आवश्यकता नहीं होगी, क्योंकि उन दोनों के बीच की संरचना समान है (यह सही नहीं है , लेकिन अगर वे वृद्धिशील उन्नयन चाहते हैं तो यह एक रास्ता है)

दूसरी ओर, हम अभी भी आसानी से कक्षाएं प्रोप का समर्थन कर सकते हैं, लेकिन उस मामले में हम गारंटी नहीं दे सकते हैं कि कक्षाओं + स्टाइल का संयोजन उसी घटक पर उपयोग किया जाता है जिसे किसी को जीतना चाहिए। क्या हमें कम से कम घटकों के स्टाइल संस्करण पर कक्षाओं के समर्थन का समर्थन करना चाहिए?

मैं इस धागे के माध्यम से इस तरह से याद कर सकता हूं - मेरे classes प्रश्न से संबंधित एक और प्रश्न। "शुद्धता" की किस तरह की गारंटी हो सकती है?

उदाहरण के लिए मैंने स्लाइडर का उदाहरण संपादित किया है:

const StyledSlider = styled(SliderUnstyled)`
  & .MuiSlider-raill {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

आप देखेंगे कि मैंने गलती से MuiSlider-rail गलत वर्तनी की है। साथ पहले classes वहाँ की तरह कुछ होगा classes.rail , और अगर मैं संपत्ति गलत वर्तनी, मैं एक क्रम चेतावनी है कि मिलेगा classes.raill स्टाइलशीट में मौजूद नहीं है। मेरा मानना ​​है कि थीम का व्यवहार समान था?

classes API के फायदे जिनके बारे में मैं सोच सकता हूं:

1. वैश्विक सीएसएस चयनकर्ताओं के खिलाफ बढ़त जो बच्चों के बीच लीक होती है: जैसे .css-e7ylz8 .MuiTreeItem-group । आपके पास कोई गारंटी नहीं है कि घटक बाल घटक पर शैली को लागू नहीं करता है (न कि वह प्रभाव जिसकी आप उम्मीद कर रहे थे, आश्चर्यचकित हो सकता है!)। शायद हमारे घटकों के लिए ठीक है, क्योंकि हम सावधान रहेंगे।
2. पोर्टल्स को नो ब्रेनर बनाए: https://material-ui.com/guides/interoperability/#portals। टूलटिप स्टाइल करने के लिए, हमें पॉपर घटक को स्टाइल करने की आवश्यकता होगी, न कि रूट जैसा कि हमने स्लाइडर के साथ किया था।
3. $styleRule सिंटैक्स चेतावनी देता है कि क्या शैली नियम अपरिभाषित है।
4. उपयोग किए गए वर्ग नामों को अनुकूलित करने की अनुमति दें। वर्तमान समाधान componentsProps प्रोप का उपयोग करना है। हम वर्ग नामों को मर्ज करते हैं।

एक वैकल्पिक दुनिया है जहाँ हम करेंगे:

ए। स्टाइल घटक के चयनकर्ताओं के साथ 1. और 3. को हल करने की अनुमति दें।
बी पिछड़े अनुकूलता के लिए classes API का खुलासा करें।
सी। आदेश में एक पाने के लिए। और बी। काम करते हुए, हमें समतल करने की आवश्यकता होगी कि घटक की शैलियों को आंतरिक रूप से कैसे लिखा जाता है। 1 स्टाइल रूट के बजाय x स्टाइल घटक। लेकिन पूर्ण निहितार्थ के साथ perf।

क्या हमें वास्तव में ऐसा करने की आवश्यकता है?

मैंने jQuery के UI के classes प्रोप के इतिहास को देखा है। मुझे दो मुद्दे मिल सकते हैं: https://bugs.jqueryui.com/ticket/7053 , https://bugs.jqueryui.com/ticket/8928 और प्रारंभिक प्रतिबद्ध: https://github.com/jquery/jquery- ui / / c192d4086d9bbaf09d5f870857af30c60a427e22 प्रतिबद्ध।

हम इसके बजाय निम्नलिखित सिंटैक्स का उपयोग करने के लिए लोगों को कल्पना करते हैं: https://next.material-ui.com/compenders/slider-styled/#unstyled -slider कक्षाएं मूल रूप से घटक में प्रत्येक स्लॉट के लिए उपलब्ध वर्ग चयनकर्ताओं द्वारा प्रतिस्थापित की जाती हैं। आप अनुकूलन उदाहरण पर भी एक नज़र डाल सकते हैं: https://next.material-ui.com/compenders/slider-styled/#customized -sliders

एक फ़ायदे के तौर पर आप बस प्रॉपर का इस्तेमाल कर सकते हैं और उनके आधार पर डायनेमिक स्टाइल लागू कर सकते हैं।

वाह, यह अब तक की सबसे अच्छी बात है।
कस्टमाइज्ड या हेडलेस घटकों को कस्टमाइज़ेशन के लिए सबसे अच्छा होने वाला है (मुई के बारे में आलोचकों में से एक, मुझे लगता है)।
यह इमो को ठीक करने के लिए एक छोटी सी बात नहीं है, लेकिन मीयूआई के लिए एक अशिष्ट प्लस है।

पुनश्च: मुझे याद है कि अतीत में कुछ घटकों को अनुकूलित करते हुए कुछ कठिन समय
PS2: आपने https://github.com/modulz/stitches पर एक नज़र

तुम नोटिस करेंगे मैं गलती से MuiSlider-Rail को छोड़ दिया। पहले की कक्षाओं के साथ कुछ होते थे जैसे कि classes.rail, और अगर मैंने प्रॉपर्टी को मिस किया, तो मुझे रनटाइम चेतावनी मिलेगी कि स्टाइलशीट में classes.raill मौजूद नहीं है। मेरा मानना ​​है कि थीम का व्यवहार समान था?

@ianschmitz विकल्प के अलावा @oliviertassinari ने स्टाइल वाले घटक चयनकर्ताओं का उपयोग करने के लिए सुझाव दिया, हमारे पास एक और विकल्प है, जो उन वर्गों के लिए स्थिरांक को उजागर करने के लिए है जिन्हें हम उजागर करते हैं। शायद कुछ इस तरह:

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

const StyledSlider = styled(SliderUnstyled)`
  & .${sliderClasses.rail} {
    display: block;
    position: absolute;
    width: 100%;
    height: 2px;
    border-radius: 1px;
    background-color: currentColor;
    opacity: 0.38;
  }
)

यह classes.rail रनटाइम चेतावनी के समान नहीं है, लेकिन वर्गों को गलत वर्तनी के खिलाफ मदद करनी चाहिए।

@mnajdova हम एक अनुरक्षक प्लगइन पर भी विचार कर सकते हैं।

classes प्रोप पर समर्थन के बारे में - हमारे लिए मज़बूती से ऐसा करने में सक्षम होने के लिए, हमें कोर घटक के प्रत्येक भाग (स्लॉट) के लिए घटक बनाने होंगे। उदाहरण के लिए, Slider , हमें रेल, ट्रैक, मार्क, मार्क लेबल, अंगूठे और मूल्य लेबल के लिए घटकों को बनाने की आवश्यकता होगी। यह हमें उन घटकों पर सीधे शैलियों को निर्दिष्ट करने की अनुमति देगा, बजाय विशिष्टता बढ़ाने के लिए कक्षाओं का उपयोग करने के लिए। ये परिवर्तन इस पीआर पर देखे जा सकते हैं - https://github.com/mui-org/material-ui/pull/22893

इन परिवर्तनों के साथ, हमने एक कोडैंडबॉक्स बनाया है, जो v4, देशी स्टाइल, अस्थिर, साथ ही दो अन्य प्रतिस्पर्धी पुस्तकालयों - https://codesandbox.io/s/ की तुलना में इस नए अपडेट किए गए स्लाइडर घटक की पूर्णता की तुलना कर सकता है।

अगर हम इन पूर्णताओं की तुलना केवल एक घटक होने और इसके भागों के लिए वर्गों के चयनकर्ताओं के उपयोग से करते हैं - https://codesandbox.io/s/slider-comparison-forked-jziv6?file=/rcrc/App.js हम देखेंगे कि प्रति स्लॉट में घटकों को जोड़ने पर 20% पूर्ण गिरावट होती है components

उत्पादन संस्करण:

• एक घटक - https://csb-jziv6-99lfgp8e6.vercel.app/
• प्रति स्लॉट घटक - https://csb-2tytc-pz2xlac86.vercel.app/

सच कहूं तो मैं इस बिंदु पर नहीं जानता कि इस पिछड़ेपन को जोड़ना बेहतर है या नहीं।

क्या classes के समर्थन के लिए ये कोई वास्तविक उपयोग के मामले हैं या क्या यह अपग्रेड को आसान बनाने के लिए है?
क्या हम माइग्रेशन पथ को आसान बनाने के लिए 20% परफेक्ट गिरावट के साथ ठीक हैं?
क्या कोई ऐसा विकल्प है जिसे हम नहीं देख सकते हैं, जो हमें इन दोनों को पूर्ण लागत का भुगतान किए बिना करने में मदद करेगा?

@ianschmitz @ eps1lon @oliviertassinari और अन्य :) क्या इस पर कोई विचार हैं?

जब तक हम टाइपस्क्रिप्ट के साथ विषयों और शैलियों को परिभाषित और उपयोग कर सकते हैं, तब तक मुझे 20% तक छूट की तुलना में माइग्रेट करने में समय व्यतीत करने में कोई दिक्कत नहीं होगी

मैं आमतौर पर उत्सुक हूं, और मुझे माफ कर दो अगर मुझे अंतर्निहित डिज़ाइन समझ में नहीं आता है, लेकिन classes JSS के लिए एक एपीआई था? अगर एपीआई डिजाइन JSS से स्टाइल घटकों में बदल रहा है, तो क्या यह classes समर्थन करने के लिए समझ में आता है?

क्या ये classes के समर्थन के लिए कोई वास्तविक उपयोग-मामले हैं या क्या यह अपग्रेड को आसान बनाने के लिए है?
क्या हम माइग्रेशन पथ को आसान बनाने के लिए 20% परफेक्ट गिरावट के साथ ठीक हैं?
क्या कोई ऐसा विकल्प है जिसे हम नहीं देख सकते हैं, जो हमें इन दोनों को पूर्ण लागत का भुगतान किए बिना करने में मदद करेगा?

माफी अगर मैं प्रस्तावित एपीआई के साथ कुछ भी याद किया है, लेकिन IMO का उपयोग मामला जो मैं सबसे अधिक बार हमारे ऑर्ग के भीतर देखता हूं वह है MUI द्वारा उपयोग किए जाने वाले अंतर्निहित स्टाइलिंग सिस्टम का अमूर्त। हाँ, मुझे लगता है कि classes "JSS के लिए API" की तरह @ConAntonakos के रूप में उल्लिखित है, लेकिन उपभोक्ता के लिए यह कोई मायने नहीं रखता था। एक उपभोक्ता के रूप में मैं वरीयता की सीएसएस तकनीक का उपयोग कर सकता हूं (क्या आज classes साथ कोई सीमाएं हैं?)। हमारे पास कई प्रकार के उत्पाद हैं:

• वेनिला सीएसएस फ़ाइलें
• एससीएसएस
• जेएसएस

उन टीमों की जरूरतों और वरीयताओं के आधार पर।

यदि आप CSS-in-JS के कुछ स्वाद का उपयोग कर रहे हैं, तो वर्ग नामों का निर्यात करने में मदद करता है, लेकिन उन लोगों के लिए क्या विचार हैं?

आरई। 20% परिपूर्ण, मैं मानता हूँ कि संभवतः एक स्वीकार्य व्यापार बंद नहीं है। दिन के अंत में आप लोगों को वह करना चाहिए जो समुदाय के अधिकांश लोगों के लिए सबसे अच्छा हो। बस अपने विचार प्रस्तुत कर रहा हूं 😄

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

@mschipperheyn प्रतिक्रिया-मूल अभी तक एक लक्ष्य नहीं है। यह उपयोग क्षमता का 5% (विकास का 1 महीना) और + 50% अधिक प्रयास (एक अनुमान) है। अवसर लागत वास्तव में उच्च है इसे (ईओण के मॉडल के बाहर) विमुद्रीकरण करने पर कोई स्पष्ट दिशा नहीं। इसके अलावा, ऐसा लगता है कि मनमुटाव दर्शकों के एक बड़े हिस्से पर कब्जा कर लिया है, जो कि देशी-प्रतिक्रिया को लक्षित करता है।

अब जब v5 अल्फा रिलीज में है, तो क्या इस मुद्दे का कोई समाधान है? विशेष रूप से, स्टाइलिंग समाधान अभी भी जेएसएस पर आधारित है? हमने JSS से संबंधित पर्याप्त प्रदर्शन मुद्दों को देखा है, इसलिए एक नए समाधान की उत्सुकता से प्रतीक्षा कर रहे हैं।

@zzzev यह एक मुद्दा नहीं है। यह एक आरएफसी (टिप्पणियों के लिए अनुरोध) धागा है।

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

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

मेरी समझ यह है कि भावना स्थैतिक शैलियों के प्रदर्शन के लिए एक मामूली हिट का कारण बनेगी, और बहुत बेहतर गतिशील शैलियों परिपूर्ण - लेकिन शायद यह बिल्कुल सही नहीं है? इस धागे में बहुत सारी अलग-अलग संख्याएँ हैं और प्रदर्शन की एक तस्वीर में समेटना कठिन है (और जाहिर है कि यह किसी व्यक्ति की स्थिति पर बहुत कुछ निर्भर करता है)।

जब आप कहते हैं कि हमें शैलियों को एक अलग तरीके से लिखना चाहिए, तो क्या आपका मतलब गतिशील शैलियों से बचना है? या क्या अन्य सर्वोत्तम प्रथाएं हैं जिन पर हमें विचार करना चाहिए?

पहले भाग पर @zzzev सही, दूसरे पर काफी नहीं है (जब तक कि आप एक अनंत प्रदर्शन लाभ के रूप में समर्थित असमर्थित से नहीं जा रहे हैं)।

भावनाओं को गतिशील शैलियों के लिए समर्थन मिलता है, स्थैतिक के लिए मामूली धीमे प्रदर्शन की कीमत पर।

मैं उलझन में हूं; वर्तमान / v4 मेक स्टाइल में गतिशील शैलियाँ नहीं हैं? जैसे यह पैटर्न

मैं उलझन में हूं; वर्तमान / v4 मेक स्टाइल में गतिशील शैलियाँ नहीं हैं? जैसे यह पैटर्न

वहाँ हैं, लेकिन एक बड़ा ज्ञात पूर्ण मुद्दा है। मेरी टीम एटीएम से बहुत दूर रहती है

मुझे बस घटक-शैली से नफरत है
jss अच्छा है, लेकिन डिबगिंग, प्रदर्शन में कुछ समस्याएं हैं और फिर भी कुछ बग अभी भी हल नहीं हुए हैं जैसे &:after नेस्टेड

यह प्रतिक्रिया-मूल और प्रतिक्रिया-मूल-वेब के लिए मेरा पैकेज बिल्ड-अप है
https://www.npmjs.com/package/@material-native-ui/theme -provider

मैं `कुछ इस तरह से (यह आरएन और आरएनडब्ल्यू के शीर्ष पर बिल्ड-अप है)

तो क्या सामग्री UI v5 के साथ उपयोग करने के लिए अनुशंसित शैली समाधान पर कोई निष्कर्ष है? ऐसा लगता है कि JSS से दूर जाने का एक इरादा है जो @material-ui/styles वर्तमान में बनाया गया है। या @material-ui/styles styled-components बजाय

तो क्या सामग्री UI v5 के साथ उपयोग करने के लिए अनुशंसित शैली समाधान पर कोई निष्कर्ष है? ऐसा लगता है कि JSS से दूर जाने का एक इरादा है जो @ सामग्री-उई / शैलियों वर्तमान में बनाया गया है। या @ सामग्री-उई / शैलियों को स्टाइल-घटकों जैसे अन्य स्टाइलिंग समाधानों के निर्माण के लिए फिर से बनाया जाएगा?

@ Matthewkwong2 हम नए स्टाइल इंजन के लिए @material-ui/styles पैकेज को नहीं अपनाएंगे, यह jss का समर्थन करता रहेगा। V5 में इसे बाकी कोडबेस से अलग किया जाएगा और हम इसे नए स्टाइल इंजन में बदलने में मदद करने के लिए इसे v6 में हटाने की योजना बनाते हैं।

V5 के लिए, हमारे पास स्टाइलिंग समाधान के बारे में नई बीट प्रथाएं होंगी, जैसे sx प्रोप और styled उपयोगिता, हम अभी भी इस पर प्रलेखन पर काम करते हैं।

इसके अलावा विषय ओवरराइड और वेरिएंट अभी भी v5 में समर्थित होने जा रहे हैं।

V5 के लिए, हमारे पास स्टाइल सॉल्यूशन के बारे में नई बीट प्रैक्टिस होंगी, जैसे sx प्रोप और स्टाइल यूटिलिटी, हम अभी भी इसके आस-पास के डॉक्यूमेंटेशन पर काम करते हैं।
इसके अलावा विषय ओवरराइड और वेरिएंट अभी भी v5 में समर्थित होने जा रहे हैं।

इसलिए यदि मैं सही ढंग से समझता हूं, तो व्यक्तिगत घटकों की स्टाइलिंग के लिए, sx या styled बजाय makeStyles का उपयोग करने के लिए प्रोत्साहित किया जाता है।

लेकिन विषय के बारे में क्या (यानी createMuiTheme )? मेरा मानना ​​है कि यह हिस्सा JSS पर भी बनाया गया है? अब विषय बनाने का अनुशंसित तरीका क्या होगा (यानी वैश्विक शैलियों को परिभाषित करने के मुख्य उद्देश्य के साथ)?

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

@mschipperheyn प्रतिक्रिया-मूल अभी तक एक लक्ष्य नहीं है। यह उपयोग क्षमता का 5% (विकास का 1 महीना) और + 50% अधिक प्रयास (एक अनुमान) है। अवसर लागत वास्तव में अधिक है। इसके अलावा, ऐसा लगता है कि मनमुटाव दर्शकों के एक बड़े हिस्से पर कब्जा कर लिया है, जो कि देशी-प्रतिक्रिया को लक्षित करता है।

मैं हमें स्पर्शरेखा के बहुत बड़े हिस्से पर नहीं ले जाना चाहता, लेकिन मैं इनमें से कुछ युक्तियों पर जोर देना चाहता हूं।

• अतीत में जब आरएन का निर्माण किया गया था, तो इससे निपटने के लिए सबसे कठिन चीजों में से एक था मटेरियल डिज़ाइन। वास्तव में यह एक बड़ा पर्याप्त मुद्दा था, यह संभावित रूप से यह तय कर सकता था कि मोबाइल ऐप बनाने में परेशान करना है या नहीं। मैंने सुना है कि यह एक आशाजनक नई लाइब्रेरी के साथ थोड़ा बेहतर है। लेकिन मुझे संदेह है कि यह उतना ही आशाजनक है जितना कि मिउ मिक्स में था। शायद यह सिर्फ मेरे लिए है, लेकिन मैं एक क्रॉस-प्लेटफॉर्म एमयूआई देख सकता हूं जो वास्तव में आरएन का उपयोग बढ़ा रहा है। मुझे पता है कि यह प्रतिक्रिया-डोम के उपयोग का केवल एक छोटा सा अंश है, लेकिन वेब बहुत बड़ा है और प्रतिक्रिया-डोम आधुनिक वेब रूपरेखाओं पर हावी है । भले ही प्रतिक्रिया-मूलक उपयोग अपेक्षाकृत कम हो, फिर भी एक निरपेक्ष के रूप में लोगों की एक उचित संख्या हो सकती है जो इसका उपयोग करेंगे। वर्तमान MUI उपयोगकर्ताओं का एक पोल शायद npm आँकड़ों से बेहतर मीट्रिक होगा।
• मुझे पता है कि मैं लूप से बाहर हूं, लेकिन मैं फ्लटर को रिएक्ट नेटिव से अधिक नहीं खरीदता हूं। यह यातायात तुलना वास्तव में तुलना करने का एक शानदार तरीका नहीं है। यह इतने सारे भ्रमित कारकों से प्रभावित है (स्पंदन नया है इसलिए बहुत से लोग पहले से ही आरएन को जानते हैं और दस्तावेज़ीकरण को संदर्भित करने की आवश्यकता नहीं है; फ़्लटर का प्रलेखन अधिक उपयोगी हो सकता है यह ट्रैफ़िक को फिर से संदर्भित कर रहा है; आरएन के कुछ डॉक रीडिंग ट्रैफ़िक भी हो सकते हैं; एक्सपो के बजाय)। यह कुछ हद तक त्रुटिपूर्ण Google रुझान तुलना एक बेहतर उपाय है, और यह काफी हद तक सही भी है। मुझे पता है कि फ़्लटर के पास कुछ कठिन डील ब्रेकर थे और आरएन अभी भी अगली बार के लिए बहुत अधिक आशाजनक है, एक ग्राहक कहता है कि उन्हें एक मोबाइल ऐप चाहिए।
• JSS रिएक्ट नेटिव के साथ MUI को बनाने के साथ सबसे बड़ा मुद्दा (वास्तव में संभवतः सबसे बड़ा) था। मुझे पता है कि अभी भी कुछ जटिल कारक होंगे, लेकिन IMHO इमोशन पर स्विच ने संभवतः MN को RN में कम से कम प्रयोगात्मक रूप से काम करने में कठिनाई के 2/3 को खत्म कर दिया है।

RN में MUI कार्य करने में कठिनाई के 2/3 स्विच ऑफ इमोशन की संभावना समाप्त हो गई है

हम आपका POC to देखने के लिए उत्सुक हैं

हम आपका POC to देखने के लिए उत्सुक हैं

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

दो सवाल:

1. क्या आप HOC के बिना नए स्टाइलिंग समाधान का उपयोग कर सकते हैं? मैं एक के लिए रिएक्ट हुक एपीआई से प्यार करता हूं, जो कि मीयूआई के पास वर्तमान में है ... निश्चित नहीं कि अगर स्टाइल सिंटैक्स भी हुड के नीचे एक एचओसी है लेकिन यह एचओसी से दूर जाने में प्रयासों (रिएक्ट पुस्तकालयों में हर जगह बहुत ज्यादा) को हरा देगा।
2. क्या classes प्रोप अधिकांश घटकों का अभी भी समर्थन किया गया है (यह उपयोगकर्ताओं को किस स्टाइल समाधान में पूर्ण लचीलापन दे सकता है)?

fast-refresh डिफ़ॉल्ट रूप से क्रिएट-रिएक्शन-ऐप v4 में सक्षम है। क्या हमें एक नई आवश्यकता के रूप में तेज़-ताज़ा समर्थन जोड़ना चाहिए?

यह gatsby के साथ बाहर की कोशिश कर रहा है। जब मैं import { Link } from '@material-ui/core' करूं तो मुझे मिला:

Can't resolve '@emotion/core' in 'node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

Can't resolve '@emotion/styled' in '/node_modules/@material-ui/styled-engine'
File: node_modules/@material-ui/styled-engine/index.js

जब import Link from '@material-ui/core/Link' समस्या में बदल गया।

अगर मैं @emotion/styled @emotion/core हूं:

'' @ भावनाओं / प्रतिक्रिया 'को' / \ __odules / @ भावना / स्टाइल / डिस्ट 'में हल नहीं कर सकते

तब मैं @emotion/react स्थापित करता हूं।

एक रनटाइम त्रुटि आती है।

Error: The `@emotion/core` package has been renamed to `@emotion/react`. Please import it like this `import { jsx } from '@emotion/react'`.
./node_modules/@emotion/core/dist/emotion-core.cjs.dev.js
node_modules/@emotion/core/dist/emotion-core.cjs.dev.js:3

शामिल पैकेज संस्करण:

    "@emotion/core": "^11.0.0",
    "@emotion/react": "^11.0.0",
    "@emotion/styled": "^11.0.0",
    "@material-ui/core": "^5.0.0-alpha.15",
    "@material-ui/lab": "^5.0.0-alpha.15",

भावना संकुल के v10 संस्करण स्थापित करें

ओह 11 अब "नवीनतम" संस्करण है, इसलिए मुझे लगता है कि मुई को अपग्रेड या दस्तावेज बनाने की आवश्यकता है

ओह 11 अब "नवीनतम" संस्करण है, इसलिए मुझे लगता है कि मुई को अपग्रेड या दस्तावेज बनाने की आवश्यकता है

हमने इसे peerDependencies में संस्करण श्रेणियों के माध्यम से प्रलेखित किया है। हमने इसे इंस्टाल निर्देशों में स्पष्ट रूप से उल्लेख नहीं किया है क्योंकि हम इसे जल्द ही v11 में अपडेट करने की योजना बना रहे हैं।

दोस्ताना याद दिलाता है कि यह एक अल्फा और इमोशन 11 है जो कुछ दिन पुराना है। शुरुआती दत्तक के रूप में आपको कुछ खुरदुरे किनारों की उम्मीद करनी चाहिए।

सभी को नमस्कार, मैं यहां नया हूं, और मैं सामग्री-यूई सीएसएस समाधानों को देख रहा था और इस मुद्दे पर आया था।
बस इस पर अपने 2 सेंट देते हुए, मैं Linaria https://github.com/callstack/linaria सुझाव देना चाहूंगा
यह एक शून्य रनटाइम लाइब्रेरी है, जिसमें रिएक्शन प्रॉपर के रूप में सीएसएस निष्कर्षण और सीएसएस चर होते हैं।

आशा है कि यह इस RFC पर मदद करता है R