Material-ui: क्या प्रदर्शन में सुधार के लिए टाइपिंग को सरल बनाया जा सकता है?

मैं सामग्री-यूआई प्रकारों से परिचित नहीं हूं लेकिन इन सवालों के जवाब देने का प्रयास करता हूं।

1. हां, वास्तविक वेब मानकों में घोषित सभी सीएसएस संपत्तियों के लिए पूर्ण समर्थन उपयोगी है।
2. ए) हमारे मामले में हम कभी भी 2 से अधिक गहराई का उपयोग नहीं करते हैं, लेकिन इस तरह के मामले काफी संभव हैं
   `` `टाइपस्क्रिप्ट
   कास्ट स्टाइल = (थीम: थीम) =>
   क्रिएट स्टाइल्स({
   कुछदिव: {
   'और: होवर बटन': {
   दृश्यता: 'दृश्यमान',
   अस्पष्टता: 1,

                ':after': {
                    content: 'x',

                    [theme.breakpoints.up('lg')]: {
                        content: 'close',
                    },
                }
            },
        }
    });
```
b) I do not understand why `BaseCSSProperties[keyof BaseCSSProperties]` is needed there

1. मुझे लगता है कि (props: Props) => CreateCSSProperties<Props> की आवश्यकता नहीं है, हमने इस प्रकार को सामग्री-यूआई प्रकारों के अपने संस्करण में शामिल नहीं किया है, और कुछ भी बुरा नहीं हुआ है।

यह संस्करण 3.9.3 में प्रकारों के कार्यान्वयन को देखने लायक हो सकता है, क्योंकि इस संस्करण में, टाइप चेकिंग काफी तेज थी और टाइपिंग अच्छी थी।

सबसे पहले मैं आपको इस पर पहुंचने और इस पर गौर करने के लिए धन्यवाद देना चाहता हूं। किसी के लिए बेंचमार्क होना अविश्वसनीय रूप से मददगार है कि किस प्रकार के हिस्से धीमे हैं या नहीं।

1. क्या मैं यह मानने में सही हूं कि प्रत्येक प्रसिद्ध सीएसएस संपत्ति के लिए नाम और प्रकार होना अविश्वसनीय रूप से मूल्यवान है और ऐसा कुछ नहीं है जिसे हम छोड़ सकते हैं?

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

1. [...]
   क्या ये बैग स्वयं पुनरावर्ती हैं या केवल एक अतिरिक्त परत है?

मुझे उस सीएसएस-इन-जेएस समाधान की जांच करनी होगी जिसका हम उपयोग कर रहे हैं। CSS में तकनीकी रूप से मीडिया के प्रश्न पुनरावर्ती हो सकते हैं। मैं इस पुनरावर्तीता में कटौती करने और यह देखने के लिए तैयार हूं कि हमें रिपोर्ट मिलती है या नहीं। तकनीकी रूप से नेस्टेड मीडिया प्रश्नों को and ऑपरेटर के साथ समतल किया जा सकता है। हालांकि हमें इसे दो स्तरों तक सीमित रखना चाहिए: एक मीडिया के प्रश्नों के लिए और दूसरा छद्म चयनकर्ताओं के लिए। यह अभी भी आईएमओ टाइप किया जाना चाहिए:

const styles = {
  root: {
    '<strong i="18">@media</strong> (max-width: 12cm)': {
      ':hover': {}
    }    
  }
}

क्या यह कुछ ऐसा है जिसे आप स्वयं @oliviertassinari लिखते हुए देखते हैं?

1. [...]
   CSSProperties - या (props: Props) => CreateCSSProperties, जो मुझे समझ में नहीं आया क्योंकि यह प्रभावी रूप से डबल-आलसी है - आपने एक बार CreateCSSProperties प्राप्त करने के लिए और फिर व्यक्तिगत गुण प्राप्त करने के लिए प्रॉप्स में पास किया है। यह "डबल थंकेड" क्यों है?

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

makeStyles({ root: { color: 'blue' }}); // A
makeStyles(theme => ({ root: { color: theme.color } })); // B
makeStyles({ root: props => ({ color: props.color})}); // C
makeStyles({ root: { color: props => props.color } }); // D: same as C, only exists for dev ergonomics
makeStyles(theme => ({ root: props => ({ color: props.color || theme.color }) })); // E: what you called "double-lazy"

यह पूर्ण में सुधार करने के लिए आलसी मूल्यांकन के बारे में कम है लेकिन संदर्भ और प्रोप उपलब्ध होने की प्रतीक्षा करने के बारे में अधिक है।

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

एक मामला है जहां इसका उपयोग किया जाता है:

विचार करना

const useStaticStyles = makeStyles({ root: { color: 'blue' } });
const useDynamicStyles= makeStyles({ root: { color: props =>  props.color } })
function Component() {
  const staticClasses = useStaticStyles(); // No error
  const throwingClasses = useDynamicStyles(); // $ExpectError
  const dynamicClasses = useDynamicStyles({ color: 'blue' });
}

makeStyles से लौटाए गए फ़ंक्शन के कॉल हस्ताक्षर का अनुमान लगाने के लिए (यानी हुक का नाम कुछ इस तरह है useSomeStyles )। हमें यह जांचना होगा कि किस प्रकार का स्टाइल बैग makeStyles । स्टाइल बैग में उपयोग किए जाने वाले प्रोप के प्रकारों का अनुमान लगाने के लिए हमारे पास पहले से ही एक {} प्रकार का अनुमान लगाता है। फिर हम IsEmptyInterface साथ प्रोप के अनुमानित प्रकार की जांच करते हैं और एक शाखा के लिए हम 0 पैरामीटर के साथ कॉल हस्ताक्षर का उपयोग करते हैं और दूसरी शाखा के लिए हम 1 पैरामीटर के साथ कॉल हस्ताक्षर का उपयोग करते हैं जो अनुमानित प्रोप प्रकार के बराबर होता है ( StylesRequireProps और StylesHook ।

संक्षेप में: हम useStaticStyles({}) या useStaticStyles(null as any) लिखने से बचते हैं। इसे https://github.com/mui-org/material-ui/pull/14019 में । मुझे लगता है कि हम कॉल सिग्नेचर का निर्धारण शॉर्ट सर्किट कर सकते हैं। शायद सशर्त प्रकारों का उपयोग करने के बजाय कॉल हस्ताक्षर को अधिभारित करें?

इस "सुविधा" के साथ समस्या यह है कि उन्नत उपयोगकर्ताओं को null as any का उपयोग करने में कोई समस्या नहीं है यदि वे समझते हैं कि क्यों। हो सकता है कि जरूरत न होने पर भी किसी खाली वस्तु को पास करना ठीक हो। हालांकि, जब सामग्री-यूआई या टाइपस्क्रिप्ट का उपयोग नहीं किया जाता है तो यह बहुत भ्रमित/निराशाजनक होता है। खासकर जब से अधिकांश स्टाइल वैसे भी प्रॉप्स पर आधारित नहीं है।

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

मैं विशेष रूप से withStyles या makeStyles उपयोग को देखने के लिए और अधिक रिपॉजिटरी क्रॉल कर सकता हूं। अब तक मैंने केवल प्रॉप्स के उपयोग को देखा है।

क्या यह कुछ ऐसा है जिसे आप स्वयं @oliviertassinari लिखते हुए देखते हैं?

@ eps1lon हमारे पास कोडबेस में इस नेस्टिंग की कुछ घटनाएं हैं (उदाहरण के लिए <strong i="8">@media</strong> (hover: none) )। लेकिन यह मुख्य घटकों के लिए बहुत बार नहीं होता है। मुझे लगता है कि यह वही उपयोगकर्ता भूमि है। यह निश्चित रूप से ट्रेडऑफ का हिस्सा हो सकता है।

@beholderrk

1. मैंने उतना ही सोचा, लेकिन सोचा कि मैं भी पूछ सकता हूं।
2. ए) गहराई दो को व्यक्त किया जाना चाहिए - गहराई की तुलना में बस थोड़ा अधिक दोहराव होगा।
   बी) मुझे इसके बारे में अपना सिर पाने में काफी समय लगा और काश मैं इसे पाठ के बजाय व्यक्तिगत रूप से समझा पाता। मूल रूप से, सूचकांक हस्ताक्षर कह रहा है कि सभी गुणों का एक ही प्रकार है। यह केवल तभी काम कर सकता है जब यह उन सभी के लिए काम करने वाले प्रकार को निर्दिष्ट करता है। ऐसा करने का एक तरीका सभी प्रकार की संपत्ति के संघ का निर्माण करना है, BaseCSSProperties[keyof BaseCSSProperties] - तो यह सच होगा कि प्रत्येक संपत्ति का एक संगत प्रकार होता है। उदाहरण के लिए, मान लें कि आपके पास CSS में केवल name: string और width: number ही गुण हो सकते हैं। दोनों गुणों के साथ काम करने वाले इंडेक्स हस्ताक्षर को निर्दिष्ट करने का एक तरीका यह कहना होगा कि प्रत्येक संपत्ति string | number । यह बहुत अच्छा नहीं है - name कभी भी number और width कभी भी string - लेकिन यह काम करता है। वास्तविक समस्या यह है कि आप जो चाहते हैं वह वास्तव में व्यक्त नहीं किया जा सकता है (कम से कम, जहां तक ​​​​हम निर्धारित करने में सक्षम हैं - एक "चतुर" हैक हो सकता है जो इसे करता है)। आप वास्तव में यह कहना चाहते हैं कि आपके प्रकार में name: string , width: number या x: CSSProperties , जहां x कुछ भी है लेकिन name या width - यह "कुछ भी लेकिन" गायब है। मुझे आशा है कि यह थोड़ा स्पष्ट है।
3. ऐसा लग रहा था कि @ eps1lon को इस बारे में कुछ कहना है, लेकिन मैं अभी भी उनकी प्रतिक्रिया को पार्स कर रहा हूं।

एक ज्ञात-अच्छी आधार रेखा बहुत मददगार होगी। क्या आपके पास एक लिंक होता है?
संपादित करें: इसे मिला।

@eps1lon बातचीत का हिस्सा हूं । तेज़, सही प्रकार सभी के लिए अच्छे होते हैं। मैं

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

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

2(बी) पर आपके क्या विचार हैं? ऐसा लगता है कि वह प्रकार अधिक मूल्य प्रदान नहीं कर रहा है क्योंकि यह मूल रूप से कहता है कि किसी भी संपत्ति का नाम स्वीकार किया जाएगा और वापसी प्रकार बड़ी संख्या में चीजों में से एक हो सकता है।

isEmptyInterface के संबंध में, क्या आप केवल गुण पैरामीटर को (उदाहरण के लिए) useStaticStyles वैकल्पिक बना सकते हैं?

मैं पहले कॉल हस्ताक्षर को ओवरलोड करने के साथ प्रयोग करना चाहता हूं और देखता हूं कि इसका कोई प्रभाव पड़ता है या नहीं। फिर हम इसे हमेशा वैकल्पिक बनाकर इसे कम ध्वनि बनाने का प्रयास करेंगे। इसे कम ध्वनि बनाना सामान्य से अधिक सुरक्षित लगता है क्योंकि लगभग सभी उपयोग के मामलों में इसे केवल एक बार कॉल किया जाता है, इसलिए आप केवल एक बार गलती करने की संभावना रखते हैं और यह बहुत जल्दी सामने आता है। इसे बेचना मुश्किल होगा, हालांकि अगर इससे हमें ज्यादा प्रदर्शन नहीं मिलता है। मैं मूल मुद्दे (https://github.com/microsoft/TypeScript/issues/34801#issue-514055289) के लिए बनाए गए रिपॉजिटरी का उपयोग करूंगा।

2(बी) पर आपके क्या विचार हैं? ऐसा लगता है कि वह प्रकार अधिक मूल्य प्रदान नहीं कर रहा है क्योंकि यह मूल रूप से कहता है कि किसी भी संपत्ति का नाम स्वीकार किया जाएगा और वापसी प्रकार बड़ी संख्या में चीजों में से एक हो सकता है।

इसे गलती से छोड़ दिया। मैं इसे IsEmptyInterface प्रयोग के बाद देखूंगा।

@ eps1lon पूरी तरह से सहमत हैं - isEmptyInterface यदि इसे समाप्त करना पर्याप्त पूर्ण जीत नहीं है।

#19320 के साथ हमने कुछ जटिल सशर्त प्रकारों से छुटकारा पाया जहां फ़ंक्शन अधिभार ने एक ही चीज़ प्राप्त की ( IsEmptyInterface और किसी भी बूलियन तर्क प्रकार को हटाकर)। हालांकि ऐसा लगता है कि कम कोड होने के अलावा हमें ज्यादा फायदा नहीं हुआ।

मैं यह जोड़ना चाहता हूं कि मैं वर्तमान में TS 3.2.4 और 3.7.4 के बीच आगे और पीछे स्विच कर रहा हूं। हमारा टाइप टेस्ट सूट 3.2.4 (~ 90s बनाम 50s) की तुलना में 3.7.4 में 50% धीमी गति से चलता है।

मैं जांच करना जारी रखूंगा कि क्या हम CSSProperties की गहराई को सीमित कर सकते हैं और मीडिया प्रश्नों और छद्म चयनकर्ताओं के लिए पूरी तरह से समर्थन हटा सकते हैं। हालांकि टाइप न करना वास्तव में एक विकल्प नहीं है। टाइप चेकर उचित समय में उनको जांचने में सक्षम होना चाहिए।

यह हो सकता है कि टाइप चेकर वास्तविक अड़चन हो। हो सकता है कि हम जांच कर सकें कि किस संस्करण में पर्फ़ हिट हुआ।

यदि आप 3.2.4 और 3.7.4 में चल रहे कमांड मुझे भेजते हैं, तो मैं स्थानीय रूप से प्रोफाइल कर सकता हूं। हालाँकि, अनुभव बताता है कि इसका कारण संभवतः 3.2.4 के बाद से अतिरिक्त, वांछनीय जाँच को जोड़ा जाएगा। (और मुझे लगता है कि "0s" एक टाइपो है - शायद "40s" या "50s"?)

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

हमारे पास कंपाइलर के कई संस्करणों की तुलना करने के लिए स्क्रिप्ट हैं, इसलिए, यदि आप एक काफी स्थिर परीक्षण की पहचान कर सकते हैं, जिसे आप हमें चलाना चाहते हैं, तो हम समय के साथ मंदी का पता लगा सकते हैं।

(और मुझे लगता है कि "0s" एक टाइपो है - शायद "40s" या "50s"?)

क्षमा करें, यह 50 का दशक है।

यदि आप 3.2.4 और 3.7.4 में चल रहे कमांड मुझे भेजते हैं, तो मैं स्थानीय रूप से प्रोफाइल कर सकता हूं।

यह रूट में सिर्फ yarn typescript है जो इसे लागू करने वाले प्रत्येक कार्यक्षेत्र में समान कमांड चलाता है। उदाहरण के लिए yarn workspace @material-ui/styles run typescript tslint और dtslint के $ExpectError साथ हमारे प्रकारों का परीक्षण करता है। 3.7.4 में हमें कुछ विफलताओं का सामना करना पड़ा और हमें अपने परीक्षणों को समायोजित करना पड़ा (देखें #19242)

पहली समस्या यह है कि टाइप सिस्टम वास्तव में आपके इच्छित आकार को व्यक्त नहीं कर सकता है।

मुझे उतना ही शक था। ऐसा लगता है कि जिस तरह से हम इंडेक्स सिग्नेचर वाली किसी ऑब्जेक्ट के साथ "कंक्रीट" शेप को मिलाते हैं, वह केवल एक वर्कअराउंड है।

क्या मैं मान सकता हूँ कि आप उस चर्चा में भाग लेने के इच्छुक होंगे?

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

मैं कल उन आदेशों को आज़माउंगा (मुझे लगता है कि मुझे उल्लेख करना चाहिए कि मैं प्रशांत समय पर हूं और अमेरिकी छुट्टियों का पालन करता हूं)।

ऐसा लगता है कि जिस तरह से हम इंडेक्स सिग्नेचर वाली किसी ऑब्जेक्ट के साथ "कंक्रीट" शेप को मिलाते हैं, वह केवल एक वर्कअराउंड है।

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

मुझे संदेह होगा कि अन्य सीएसएस-इन-जेएस स्टाइलिंग समाधान समान प्रदर्शन बाधाओं को प्रभावित करते हैं।

बहुत ज़्यादा। हम उम्मीद कर रहे हैं कि हम आपके लिए जो कुछ भी करते हैं उसे पूरे पारिस्थितिकी तंत्र को बेहतर बनाने के लिए सामान्यीकृत किया जा सकता है।

मुझे लगता है कि मुझे कुछ स्पष्ट याद आ रहा है, लेकिन मैं वर्तमान में फंस गया हूँ। सबसे पहले, मैंने विंडोज़ को छोड़ दिया - चीजें लिनक्स पर बेहतर काम करने लगती हैं। मुझे बताएं कि क्या आप उसमें खुदाई करना चाहते हैं। दूसरा, मुझे चलाने के लिए yarn typescript मिल सकता है - सफाई से, जहां तक ​​​​मैं कह सकता हूं - लेकिन ऐसा लगता है कि यह शुद्ध tsc के बजाय tslint चल रहा है। जब मैं उसी tsconfig.json (मैं विशेष रूप से शैलियों के साथ परीक्षण कर रहा हूं) पर tsc चलाता हूं, तो मुझे ~ 40 त्रुटियां मिलती हैं। मैं क्या गलत कर रहा हूं? प्रोफाइलिंग उद्देश्यों के लिए, एक एकल टीएससी आमंत्रण के लिए रेप्रो को नीचे लाना बहुत मददगार होगा।

@amcasey yarn typescript संकलन के बारे में नहीं है बल्कि हमारे प्रकारों का परीक्षण कर रहा है। हम निश्चित रूप से टाइप किए गए रेपो में उपयोग किए गए समान सेटअप का उपयोग कर रहे हैं। packages/* में टाइपस्क्रिप्ट फ़ाइलें लगभग हमेशा बयानों का एक समूह होती हैं जो या तो पास हो जाती हैं या विफल हो जाती हैं जिसे हम $ExpectError साथ पकड़ लेते हैं।

मुझे लगता है कि सबसे अच्छा "वास्तविक दुनिया" परीक्षण का मामला उपयोग कर रहा है tsc के माध्यम से हमारे डॉक्स पर yarn workspace docs run tsc -p tsconfig.json के बाद आपके द्वारा जोड़े गए skipLibCheck: true और noEmit: true करने के लिए ./docs/tsconfig.json :

--- a/docs/tsconfig.json
+++ b/docs/tsconfig.json
@@ -3,6 +3,8 @@
   "include": ["types", "src/pages/**/*"],
   "compilerOptions": {
     "allowJs": false,
-    "noUnusedLocals": true
+    "noUnusedLocals": true,
+    "noEmit": true,
+    "skipLibCheck": true
   }
 }

@ eps1lon स्पष्ट करने के लिए धन्यवाद। मैं रोमांचित नहीं हूं कि tslint धीमा हो गया, लेकिन मैं एक समय में एक चर पर ध्यान केंद्रित करना चाहता हूं। मैं टाइपस्क्रिप्ट के विभिन्न संस्करणों के साथ आपके द्वारा सुझाए गए डॉक्स बिल्ड को चलाऊंगा और देखूंगा कि क्या कुछ बाहर निकलता है। धन्यवाद!

यह सेटअप एकदम सही है। मुझे 3.3 और 3.4 के बीच चेक का समय दोगुना दिखाई दे रहा है।

| संस्करण | चेक टाइम |
|-|-|
| 3.2 | 16.71s |
| 3.3 | 16.79s |
| 3.4 | 35.25s |
| 3.5 | 21.40s |
| 3.6 | 23.10s |
| 3.7 | 27.39 एस |

मैं थोड़ा और खोदूंगा, लेकिन मुझे बताया गया है कि सशर्त प्रकारों का 3.3 कार्यान्वयन अधूरा था, 3.4 कार्यान्वयन धीमा था, और 3.5 कार्यान्वयन अच्छा है। तो, दुर्भाग्य से, यह शायद अपेक्षित है।

विशेष रूप से, मुझे संदेह है कि इस परिवर्तन ने इस बग में वर्णित मंदी की शुरुआत की।

मुझे लगता है कि 3.5 और 3.7 के बीच चेक चलाने में लगने वाले समय में 6-सेकंड की वृद्धि हुई थी। यह काफी सारगर्भित लगता है।

@embeddedt वे संख्याएँ प्रत्येक संस्करण के साथ एकल रन से हैं, इसलिए संभवतः काफी शोर है। हालांकि, मैं खुदाई करूंगा और देख सकता हूं कि मुझे कुछ मिल सकता है या नहीं।

मैंने इसे लिनक्स वीएम पर रिडीड किया और 3.7 लगातार 20-25% 3.5 से धीमा था।

यह द्विभाजित करना काफी कठिन साबित हुआ है क्योंकि एक ही बिल्ड के लगातार रन ~ 5% से भिन्न होते हैं और 3.5 और 3.6 के बीच या 3.6 और 3.7 के बीच का अंतर केवल ~ 10% है।

एक संदेहास्पद बात मैंने देखी है कि styled-components TS >= 3.7 के लिए अलग .d.ts फ़ाइलें प्रदान करता है, इसलिए तुलना सेब से सेब नहीं हो सकती है।

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

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

@amcasey इसे देखने में आपके प्रयासों के लिए धन्यवाद! TS टीम और सामग्री UI के सदस्यों को एक साथ काम करते हुए देखना वास्तव में अच्छा है। मैं इस Github मुद्दे पर ठोकर खाई यह पता लगाने की कोशिश कर रहा हूं कि सामग्री UI के साथ हमारा संपादक अनुभव इतना धीमा क्यों है (हम इसे काम पर दो परियोजनाओं में उपयोग कर रहे हैं)। निश्चित रूप से पुष्टि कर सकते हैं कि हम VsCode के अंदर इंटेलिजेंस और उपयोगिता में काफी महत्वपूर्ण प्रभाव देख रहे हैं।

इस बिंदु पर हमें अपने जेएसएस में शेष पुस्तकालय के लिए तेज़ प्रतिक्रिया के लिए थोड़ी सी प्रकार की सुरक्षा का व्यापार करने में खुशी होगी। कभी-कभी टाइपस्क्रिप्ट सर्वर को कोड परिवर्तन के लिए पकड़ने से पहले प्रतीक्षा करने में 8-10 सेकंड का समय लगता है

तीन-रन औसत के साथ भी, डेटा बहुत शोर है। हालांकि, वहाँ पर क्रम में उल्लेखनीय ड्रॉप हो गया लगता है https://github.com/microsoft/TypeScript/commit/ad322a561a301ae357da051b9221b2222c13be36 पर एक ध्यान देने योग्य वृद्धि (मोटे तौर पर पिछले स्तर को वापस) https://github.com/microsoft/TypeScript /commit/480b73915fdd805952fd355e4cf3e1bc803e0878 और उसके बाद एक सामान्य ऊपर की ओर रुझान (हालांकि यह मेरे लिए बहुत समान दिखता है और मुझे पर्यावरणीय कारकों पर संदेह है) जिसमें https://github.com/microsoft/TypeScript/commit/c5e6d95e930048a033868d72440a9296904a33ec पर एक विशेष स्पाइक शामिल है

ऊपर की ओर रुझान जांच के लिए खड़ा है और मुझे नहीं पता कि इसका क्या कारण हो सकता है। हो सकता है कि असतत मंदी एक साथ इतने करीब हो कि शोर उन्हें एक ही वक्र जैसा दिखता है।

मैं प्रति प्रतिबद्धता 10 रन तक उछला और अब ढलान वाले क्षेत्र में चार अलग-अलग प्रतिगमन हैं। :मुस्कुराओ:

https://github.com/microsoft/TypeScript/commit/26caa3793e310e271dee8adc1804486e5b0749f (~700ms)
https://github.com/microsoft/TypeScript/commit/250d5a8229e17342f36fe52545bb68140db96a2e (~500ms)
https://github.com/microsoft/TypeScript/commit/7ce793c5b8c621af5ce50af0ca3958c7bd6541bf (~1300ms)
https://github.com/microsoft/TypeScript/commit/28050d5c47c6cd7627555f12cf13b1062f80322a (~400ms)

(प्रतिगमन शुरू होने से पहले कुल समय ~33s था।)

उम्मीदों को थोड़ा कम करने के लिए: यह काफी संभावना है कि इनमें से कई रिग्रेशन मूल्यवान अतिरिक्त चेक साबित होंगे और, भले ही हम उन सभी चेकों को मुफ्त में प्राप्त करने में कामयाब रहे, फिर भी हम केवल 20% की छूट लेंगे "बहुत लंबा" ".

संपादित करें: मैंने लिंक अपडेट कर दिए हैं। क्योंकि मैं समय के साथ पीछे की ओर जा रहा था, मैं भ्रमित हो गया और प्रत्येक प्रतिगमन _before_ मर्ज को ध्वजांकित किया।

@ eps1lon इस ओर से किसी ने सुझाव दिया कि @ts-ignore को हटाने से मदद मिल सकती है। मूल रूप से, जब किसी त्रुटि का पता चलता है, तो यह माना जाता है कि उपयोगकर्ता की सर्वोच्च प्राथमिकता त्रुटि के बारे में अच्छी जानकारी प्राप्त करना है, इसलिए यह संभव है कि अतिरिक्त कार्य किया जाएगा। यदि वह जानकारी बाद में छोड़ दी जाती है ( @ts-ignore ), तो वह समय बर्बाद हो जाता है। (दुर्भाग्य से, यह पता लगाना आसान नहीं है कि किसी त्रुटि का पता लगाने की आवश्यकता नहीं है।) एक वैकल्पिक रणनीति स्पष्ट प्रकार के अभिकथन ( any ) को तब तक जोड़ना है जब तक कि संकलक शिकायत करना बंद न कर दे।

@ eps1lon इस ओर से किसी ने सुझाव दिया कि @ts-ignore को हटाने से मदद मिल सकती है।

docs/ में हमारा केवल एक ही उपयोग था। मैंने इसे वैसे भी हटा दिया है: #19504

ईमानदार होने के लिए ऐसा लगता है कि @ts-ignore उस मामले में एक विरोधी पैटर्न है। यह न केवल आपको उपयोगी जानकारी प्रदान करता है अर्थात हमें किस प्रकार की त्रुटि है बल्कि यह एक पूर्ण बाधा भी है।

जहां तक ​​मैं बता सकता हूं @ts-ignore केवल .js फाइलों में उपयोगी है जिन्हें टाइप-चेक किया जा रहा है।

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

प्रदर्शन को वापस लेने वाले परिवर्तनों के लिए बग:
https://github.com/microsoft/TypeScript/issues/36562
https://github.com/microsoft/TypeScript/issues/36564
https://github.com/microsoft/TypeScript/issues/36565
https://github.com/microsoft/TypeScript/issues/36566
https://github.com/microsoft/TypeScript/issues/36567

निष्पक्ष चेतावनी: इनमें से कुछ के सार्थक होने की संभावना है।

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

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

ऐसा कहा जा रहा है, क्या ऐसा ध्वज जोड़ना संभव/व्यावहारिक है जो स्टाइलिंग सिस्टम के महंगे हिस्सों के लिए टाइप चेकिंग को बंद कर देता है (संभवतः सशर्त रूप से type CSSProperties = any जैसी चीजें करके)? मैं स्टाइल सिस्टम का उपयोग करने वाले लोगों की संख्या के लिए आंकड़े नहीं जानता, इसका उपयोग नहीं कर रहा हूं, लेकिन मुझे लगता है कि यह वास्तव में बहुत नुकसान नहीं कर सकता है (बशर्ते कि उस ध्वज सेट के साथ टाइपिंग का परीक्षण करने के लिए एक चेक जोड़ा गया हो) , और यह उपयोगकर्ताओं के कम से कम एक वर्ग के प्रदर्शन को बेहतर बनाने का एक त्वरित तरीका होगा।

बस सामान्य विचार का उल्लेख करना चाहता था; इसे नीचे शूट करने के लिए स्वतंत्र महसूस करें। :थोड़ा_मुस्कुराता_चेहरा:

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

नए नंबर (अलग मशीन, अलग समय मीट्रिक):

| संस्करण | कुल समय |
|-|-|
| 3.5.3 | 32.5s |
| 3.7.5 | 35.9s |
| मास्टर | 29.9s |

मेरे द्वारा ऊपर पोस्ट की गई कुछ समस्याएं अभी भी खुली हैं, लेकिन हम मूल रूप से 3.5 perf (इस बेंचमार्क के लिए) पर वापस आ गए हैं। जाहिर है, यह अभी भी हमारी अपेक्षा से बहुत धीमा है, लेकिन परिवर्तनों का अगला बैच सामग्री-यूआई पक्ष पर होने की संभावना है।

हमारे परीक्षण सूट पर 3.8.1 का परीक्षण किया गया और ऐसा लगता है कि वे पिछले वाले के रूप में 3.2.4 (3.7 काफी धीमी गति से) का उपयोग कर रहे हैं।

सच कहूँ तो, मुझे विश्वास नहीं हो रहा है कि हम नई कार्यक्षमता को छोड़े बिना कितना अच्छा कर पाए। : मुस्कान: मुझे लगता है कि थोड़ा और सुस्त हो सकता है (उदाहरण के लिए https://github.com/microsoft/TypeScript/pull/36754), लेकिन मुझे अभी भी संदेह है कि सबसे प्रभावशाली परिवर्तन CSSProperties प्रकारों का सरलीकरण होगा। क्या आपको उन लोगों के साथ खेलने का मौका मिला है? ऐसा लगता है कि कम से कम उपयोगकर्ताओं का एक सबसेट (जैसे @embeddedt) एक पूर्ण जीत के बदले में कुछ प्रकार की जाँच को छोड़ कर खुश होगा।

ऐसा लगता है कि कम से कम उपयोगकर्ताओं का एक सबसेट (जैसे @embeddedt) एक पूर्ण जीत के बदले में कुछ प्रकार की जाँच को छोड़ कर खुश होगा

क्या TS टीम के किसी व्यक्ति ने हाल ही में ट्वीट नहीं किया था कि प्रत्येक उपयोगकर्ता जो सख्त प्रकार चाहता है, उसके लिए एक है जो शिथिल होना चाहता है? :मुस्कुराओ:

मेरे लिए यह वास्तव में टाइप चेकिंग के बारे में नहीं है (ब्राउज़र devtools में आपके सीएसएस की जांच करने की बेहतर क्षमताएं हैं)। यह स्वतः पूर्ण उपलब्ध होने के बारे में अधिक है।

मैं विभिन्न "संस्करणों" के साथ खेलूंगा और देखूंगा कि वे कैसे करते हैं।

@amcasey मुझे नहीं लगता कि https://github.com/eps1lon/mui-types-perf/pull/6 और बेंचमार्क लॉग देखें।

यह हमारे द्वारा किए जाने वाले "ओवरलोडिंग" की मात्रा के साथ एक समस्या का अधिक हो सकता है। styled-components केवल एक स्थिर वस्तु की अनुमति देता है जबकि हम एक थंकेड संस्करण के साथ-साथ प्रत्येक संपत्ति को एक थंक होने की अनुमति देते हैं। हालांकि मुझे यकीन नहीं है।

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

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

मेरे जैसे उपयोगकर्ताओं को सक्षम करेगा जिन्हें जटिल प्रकारों की आवश्यकता नहीं है ताकि वे प्रदर्शन में तेजी से वृद्धि देख सकें।

यह भी निश्चित नहीं है कि आपको ध्यान देने योग्य अंतर मिलेगा। मैंने 15% पूर्ण जीत देखी है लेकिन यह संदिग्ध है अगर यह पहचानने योग्य है।

मैं देख सकता था कि "उपयोगकर्ता सेटिंग" इंस्टॉल पर पैकेज को पैच कर रहा है। टाइपिंग के कई संस्करणों को बनाए रखने के लिए हमारे पास बैंडविड्थ नहीं है।

@ eps1lon क्षमा करें, मुझे लगता है कि मेरा प्रश्न अस्पष्ट हो सकता है। मुझे लगता है कि CSSProperties ठीक है (हालांकि, जाहिर है, अगर यह छोटा होता तो यह तेज़ होता) - मैं वास्तव में उम्मीद कर रहा था कि https://github.com/mui-org में उपप्रकारों को सरल बनाने के लिए जगह हो सकती है इस प्रकार को any बदलते हैं तो क्या आपको कम पूर्णताएँ प्राप्त होंगी?

संपादित करें: मेरे बॉक्स पर, यह docs प्रोजेक्ट को 15% तेज (29.7s से 25.5s तक) संकलित करता है, लेकिन मुझे संपादन अनुभव पर प्रभाव का पता नहीं है।
2 संपादित करें: वास्तव में, एक बार जब आप प्रकार के पुनरावर्ती भाग में तह करना छोड़ देते हैं, तो आप केवल BaseCreateCSSProperties उपयोग कर सकते हैं और किसी भी अन्य संपत्ति में any टाइप होगा (यानी आपको रखना होगा CSS गुणों के वास्तविक प्रकार)।
संपादित करें 3: संपादित करें 2 अतिरिक्त संपत्ति की जाँच के कारण काम नहीं करता है (अर्थात वस्तु शाब्दिक में मनमानी संपत्ति के नामों की अनुमति नहीं है)।

पूर्णता बनाम प्रकार की जाँच के बारे में आपकी बात बहुत दिलचस्प थी क्योंकि मेरी एक परिकल्पना थी कि कुछ प्रकार के लेखक ऐसा महसूस कर सकते हैं। @DanielRosenwasser मुझे लगता है कि हमने "a" | "b" | string पैटर्न को समायोजित करने के लिए ऐसा कुछ करने पर ध्यान दिया - क्या वह कहीं भी गया?

यह भी ध्यान दें कि styled-components में (हमारा मानना ​​है) बारीकी से संबंधित चेकर प्रदर्शन समस्याएं हैं।

प्रकार को अधिक सटीक रूप से निर्दिष्ट करने में सक्षम होने के संबंध में, मैंने https://github.com/microsoft/TypeScript/issues/36782 दायर किया है

ऐसा लगता है कि emotion एक ही नाव में हो सकता है।

मैंने आज अपने प्रोजेक्ट में मटेरियल UI ( 4.9.4 ) जोड़ना शुरू कर दिया है, और मंदी वास्तव में इतनी महत्वपूर्ण है कि मुझे नहीं लगता कि मैं इसे अपने प्रोजेक्ट में भी उपयोग कर सकता हूं। बस एक साधारण जोड़ा <Slider/> , घटक का उपयोग अनुकूलित withStyles() ।

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

एक तरीका खोजने की कोशिश कर रहा हूं कि मैं कम से कम सभी टाइपस्क्रिप्ट सामग्री को @material-ui लिए अभी के लिए बाहर कर सकता हूं (मूल रूप से संपूर्ण मॉड्यूल any ) - लेकिन टाइपस्क्रिप्ट इतना आसान नहीं लगता है।

@lostpebble क्या स्लाइडर को अनुकूलित करने के लिए withStyles अलावा कुछ और उपयोग करने से ऐसा ही होता है, CSS मॉड्यूल कहें?

@lostpebble वर्तमान में हमारे पास किसी विशेष प्रकार के सेट को बाहर करने का समर्थित तरीका नहीं है। यदि आप वास्तव में, वास्तव में चाहते हैं, तो प्रयोग करने की बात पथ मैपिंग होगी। आप "@material-ui/*": ["simplemui"] जैसे पथ मैपिंग का प्रयास कर सकते हैं और फिर simplemui.d.ts युक्त बना सकते हैं

declare const x: any;
export = x;

यह प्रभावी रूप से सभी सामग्री-यूआई प्रकार any । यह निश्चित रूप से एक हैक है और ऐसा कुछ नहीं है जिसकी मैं सिफारिश कर सकता हूं, लेकिन यह आपके संपादन अनुभव को अनब्लॉक कर सकता है।

मुझे लगता है कि हमने कुछ अच्छे सुधार किए हैं (कहीं-कहीं 30% क्षेत्र में) लेकिन ऐसा लगता है कि अभी हम टाइपिंग को कम कर सकते हैं।

इसके लिए पूरी तरह से ठोस प्रस्तावों की आवश्यकता है जैसे कि टाइप चेकर द्वारा स्वीकार किए जाने के लिए आप किस गलत कोड के साथ ठीक होंगे। फिर हमें बेंचमार्क करना होगा और देखना होगा कि क्या यह सार्थक सेंध लगाता है।

आपको यह समझना होगा कि जानबूझकर शुरू किए गए प्रतिगमन अनुरक्षकों के लिए बहुत काम जोड़ते हैं क्योंकि हमें पुस्तकालय उपभोक्ताओं को यह समझाना पड़ता है और कुल मिलाकर यह काफी तनावपूर्ण है।

तो इस समय मेरे लिए यह प्राथमिकता नहीं है जब तक कि किसी के पास कार्रवाई योग्य बुद्धि न हो। नहीं तो मुझे बहुत कम समय में बहुत अधिक समय देना होगा।

मेरे मामले में makeStyles(theme => createStyles(...)) , Record<ClassKey, any> से createStyles(...) लगभग ~ आधा ~ (मेरे कोड और कंप्यूटर में, लगभग ~ 1200ms -> 750ms ~ 1400ms → 1100ms) encodedSemanticClassifications-full: elapsed time tsserver लॉग में दिखाया गया है (यह एक महंगा काम नहीं दिखता है, लेकिन शायद टाइप चेक पूरा होने की प्रतीक्षा कर रहा है)।

export default function createStyles<ClassKey extends string, Props extends {}>(
  styles: StyleRules<Props, ClassKey>,
): Record<ClassKey, any>;

createStyles(...) शैली संरचना की जांच करता है ताकि हम createStyles बनाम रिटर्न-टाइप-ऑफ-मैसिव-यूनियन के तर्क-प्रकार-के-बड़े पैमाने पर संघ के लिए टाइप चेक को छोड़ सकें।

~(और संपूर्ण मेक स्टाइल कोड पर टिप्पणी करते हुए: 650ms)~

@ypresto createStyles केवल const अभिकथन के बिना टाइपप्रति संस्करणों के लिए आवश्यक है। यदि आप अपने कोडबेस (ts >= 3.4) में { display: 'block' as const } का उपयोग कर सकते हैं तो उस createStyles से अधिक का उपयोग करें।

@ eps1lon हमने उस पर ध्यान दिया और docs में स्विच करने का प्रयास किया लेकिन परिणाम अप्रभावी थे।

@ eps1lon const और createStyles बिना, IntelliSense अब संदर्भ-जागरूक उम्मीदवारों को नहीं दिखाता है: रो:

@ypresto इसे चाहिए। क्या आपके पास एक उदाहरण कोड स्निपेट है?

@amcasey

बाहरी वस्तु या संपत्ति में as const जोड़ना प्रभावी रूप से इसे मारता है। मैं इसे हर संपत्ति पर नहीं रखना चाहता।

const useStyles = makeStyles(theme => ({
  root: {
    // no IntelliSense
  }
} as const))

इसके अलावा createStyles के बिना स्ट्रिंग पूर्णता के लिए इसकी छोटी सीमा है।

const useStyles = makeStyles(theme => ({
  root: {
    direction: '|', // no IntelliSense at | (works with createStyles)
    direction: | // IntelliSense works at |
  }
}))

@ypresto "इसे मारता है" से, क्या आपका मतलब है "यह उसी तरह काम करता है जैसे createStyles किया"?

इसे हर जगह रखना एक खिंचाव है, लेकिन हर जगह createStyles डालने से ज्यादा कोई खींच नहीं है।

@amacleay मेरा मतलब था kills IntelliSense : प्रार्थना:।

क्षमा करें, मैं आपकी टिप्पणियों से चूक गया। मैं इसे एक शॉट दूंगा।

मुझे पता नहीं क्यों, लेकिन यह 1100ms → 750ms दिलचस्प है:

 export const DropArea: React.FC<CardProps & {
   active?: boolean
   description: string
   icon?: React.ReactNode
-}> = ({ active, description, icon, children, ...props }) => {
+}> = ({ children, ...props }) => {
   const classes = useStyles()
+  const active = false
+  const icon: React.ReactNode = null
+  const description = ''
   return (
     <Card {...props} className={clsx(classes.root)} variant="outlined">

FC से CardProps & को हटाना लगभग समान परिणाम है। शायद ऐसा इसलिए है क्योंकि कार्डप्रॉप्स पेपरप्रॉप्स का विस्तार करता है, जो बड़े HTMLAttributes का विस्तार करता है।

अद्यतन और महत्वपूर्ण: यह पता चला है कि कार्डप्रॉप्स को HTMLAttributes<HTMLDivElement> बदलने से समय भी कम हो जाता है (मापा नहीं जाता)।

अंत में, मुझे सबसे बड़ा मिला, 750ms → 130ms:

दो टाइपोग्राफी से style={...} निकाला जा रहा है।

-<Typography variant="subtitle2" component="div" noWrap style={{ width: '26ch' }}>...</Typography>
+<Typography variant="subtitle2" component="div" noWrap>...</Typography>
-<Typography variant="caption" component="div" noWrap style={{ width: '20ch' }}>...</Typography>
+<Typography variant="caption" component="div" noWrap>...</Typography>

लेकिन क्यों? <div> में समान शैली जोड़ने से प्रदर्शन प्रभावित नहीं होता है। शायद OverridableComponent बहुत जटिल है..?

(मैं टाइपस्क्रिप्ट 3.8.3, @material-ui/core 4.9.1 का उपयोग कर रहा हूं)

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

@embeddedt प्रकार के स्तर में, यह React.CSSProperties समाधान करता है जो कि div के स्टाइल प्रोप के समान है।

@ypresto मैं सही खड़ा हूं। माफ़ करना।

हाय दोस्तों, सुनिश्चित नहीं है कि इसके लिए एक नया मुद्दा खोलना उचित है, इसलिए मैं इसे यहां पोस्ट करूंगा क्योंकि यह प्रकार शुद्धता/प्रदर्शन से संबंधित है। मुझे बताएं कि क्या मुझे इसके बजाय कोई मुद्दा खोलना चाहिए।
कस्टम फ़ॉन्ट जोड़ने के लिए
Type 'string' is not assignable to type 'FontFaceFontDisplayProperty'

यह अजीब है, क्योंकि csstype 2.6.9 टाइपिंग मान्य लगती है और अन्य विशेषताएँ ठीक हैं (MUI 4.9.5 का उपयोग करके)।

const sourceSansPro = {
  fontFamily: "'Source Sans Pro'",
  fontStyle: "normal",
  fontDisplay: "swap", // won't work
  fontWeight: 400,
  src: `
    url('/static/fonts/Source_Sans_Pro/SourceSansPro-Regular.ttf') format("truetype")
  `
};

थीम संपत्ति:

  overrides: {
    MuiCssBaseline: {
      "@global": {
        "@font-face": [sourceSansPro]
      }
    }

प्रकार है type FontFaceFontDisplayProperty = "auto" | "block" | "fallback" | "optional" | "swap";

@ एरिक-ब्यूरल यह टाइपस्क्रिप्ट के स्वचालित प्रकार को चौड़ा करने वाला एक मुद्दा है। कोशिश

- fontDisplay: "swap", // won't work
+ fontDisplay: "swap" as "swap",

धन्यवाद यह काम करता है, और मैंने एक नई अवधारणा "टाइप चौड़ा" सीखा है :) यह अजीब है कि fontStyle उदाहरण के लिए प्रभावित नहीं है, यह एकमात्र सीएसएस संपत्ति नहीं है जिसे एनम के रूप में परिभाषित किया गया है लेकिन पहली बार मैंने इसे मारा .

संपादित करें: ठीक है मेरा बुरा यह अच्छी तरह से प्रलेखित है: https://material-ui.com/guides/typescript/#using -createstyles-to-defeat-type-widening

अंत में, मुझे सबसे बड़ा मिला, 750ms → 130ms:

दो टाइपोग्राफी से style={...} निकाला जा रहा है।

-<Typography variant="subtitle2" component="div" noWrap style={{ width: '26ch' }}>...</Typography>
+<Typography variant="subtitle2" component="div" noWrap>...</Typography>
-<Typography variant="caption" component="div" noWrap style={{ width: '20ch' }}>...</Typography>
+<Typography variant="caption" component="div" noWrap>...</Typography>

लेकिन क्यों? <div> में समान शैली जोड़ने से प्रदर्शन प्रभावित नहीं होता है। शायद OverridableComponent बहुत जटिल है..?

(मैं टाइपस्क्रिप्ट 3.8.3, @material-ui/core 4.9.1 का उपयोग कर रहा हूं)

क्या आपने इसे बिल्ड समय को प्रभावित करने के लिए पाया है, या इंटेलिजेंस के उपयोगी होने में लगने वाले समय को प्रभावित किया है? मुझे बिल्ड इश्यू (स्मृति से बाहर) मिल रहा है और हमारे कुछ टीएस कोड में घटकों पर style={someStyle} का एक टन सेट है। आश्चर्य है कि क्या यह हमारे मुद्दे का हिस्सा है।

@ yatrix7 , आम तौर पर बोलते हुए, मैं उम्मीद करता हूं कि ये लंबे चेक समय बिल्ड और संपादक प्रतिक्रिया समय दोनों को प्रभावित करेंगे।

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

खुद इस पर गौर करने का मन नहीं करेगा।

यह कमाल होगा। वर्तमान में हमारे पास काम करने के लिए कार्रवाई योग्य वस्तुओं के बारे में जानकारी नहीं है। तो बाधाओं के लिए किसी भी संकेतक की सराहना की जाएगी।

जांच में मदद के लिए अभी के लिए कुछ बेंचमार्किंग जोड़े गए हैं: https://github.com/mui-org/material-ui/pull/22110

@FabianKielmann टीएस के अंत में, मैं पूर्ण जांच उपकरण पर काम कर रहा हूं, जो मुझे आशा है कि जल्द ही परिपक्व हो जाएगा, सामग्री-यूआई पर लागू होगा।

यदि आपके पास इस पर खर्च करने के लिए कुछ समय है, तो आप https://github.com/microsoft/TypeScript/issues/38583 जैसे कुछ भी आज़मा सकते हैं