Material-ui: هل يمكن تبسيط الكتابة لتحسين الأداء؟

لست على دراية بأنواع واجهة المستخدم المادية ولكن حاول الإجابة على هذه الأسئلة.

1. نعم ، يعد الدعم الكامل لجميع خصائص css المعلنة في معايير الويب الفعلية مفيدًا.
2. أ) في حالتنا ، لا نستخدم أبدًا عمق أكثر من 2 ، لكن حالات مثل هذه ممكنة تمامًا
   `` مطبوعه
   أنماط const = (السمة: السمة) =>
   createStyles ({
   Somediv: {
   "&: زر التمرير": {
   الرؤية: "مرئية" ،
   العتامة: 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. هل أنا محق في افتراض أن وجود اسم ونوع لكل خاصية CSS معروفة هو أمر ذو قيمة لا تصدق وليس شيئًا يمكن أن نتخلى عنه؟

من المستحيل أن تكون غير متحيز هنا. لا أعتقد أنه يمكننا التخلي عنها رغم النظر إلى النظام البيئي الأوسع. تحتوي أدوات Chrome devtools على هذه الميزة ، وتتفاعل بنفسها أنواع الخاصية style مع CSSProperties إلخ. لا أستطيع أن أرى نفسي أتحول من IDE إلى المتصفح وأتحقق مما إذا كانت زخرفة نصية أو زخرفة خط أم تحويل النص.

1. [...]
   هل هذه الأكياس نفسها متكررة أم أن هناك طبقة إضافية واحدة فقط؟

سأحتاج إلى التحقق من حل CSS-in-JS الذي نستخدمه. من الناحية الفنية ، يمكن أن تكون استعلامات الوسائط في CSS متكررة. سأكون على استعداد لقطع هذا التكرار ومعرفة ما إذا كنا نحصل على تقارير. يمكن تسوية استعلامات الوسائط المتداخلة تقنيًا باستخدام عامل التشغيل and . يجب أن نحصره في مستويين: أحدهما للاستعلامات عن الوسائط والآخر للمحددات الزائفة. يجب أن يتم التحقق من نوع IMO:

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

هل هذا شيء ترى نفسك تكتبهoliviertassinari؟

1. [...]
   CSSProperties - أو (props: Props) => CreateCSSProperties، وهو ما لم أفهمه لأنه فعال كسول مزدوج - لقد مررت في Props مرة واحدة للحصول على CreateCSSProperties ثم مرة أخرى للحصول على خصائص فردية. لماذا هو "خشن مزدوج"؟

إذا لم تكن الحجة نفسها عبارة عن حقيبة ملكية ولكنها وظيفة ، فإنها تتطلب سمة. يمكن أن تعتمد الأنماط على نوعين مختلفين من أكياس الخاصية: السمة (المتاحة عبر واجهة برمجة تطبيقات سياق React) أو الدعائم (التي يتم تمريرها مباشرةً إلى المكون):

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 . لدينا بالفعل مساعد لاستنتاج أنواع الدعائم المستخدمة في حقيبة الأناقة . إذا كانت حقيبة النمط ثابتة ، فإن TS يشير إلى النوع {} . ثم نتحقق من النوع المستنتج من Props بـ IsEmptyInterface ولفرع واحد نستخدم توقيع استدعاء مع معلمات 0 وبالنسبة للفرع الآخر نستخدم توقيع استدعاء مع معلمة واحدة تساوي نوع الدعائم المستنتجة ( انظر StylesRequireProps و StylesHook .

باختصار: نتجنب الاضطرار إلى كتابة useStaticStyles({}) أو useStaticStyles(null as any) . تم تقديمه في https://github.com/mui-org/material-ui/pull/14019 لإغلاق https://github.com/mui-org/material-ui/issues/14018. أعتقد أنه يمكننا ماس كهربائى لتحديد توقيع المكالمة. ربما يفرط في تحميل توقيع المكالمة بدلاً من استخدام الأنواع الشرطية؟

تكمن مشكلة هذه "الميزة" في أن المستخدمين المتقدمين ليس لديهم مشكلة في استخدام null as any إذا فهموا السبب. ربما حتى تمرير جسم فارغ أمر جيد على الرغم من عدم الحاجة إليه. ومع ذلك ، فإنه أمر محير / محبط للغاية عند عدم استخدامه لـ Material-UI أو TypeScript. خاصة وأن معظم التصميم لا يعتمد على الدعائم على أي حال.

يبدو أن مدقق النوع مشغول في معظم الأوقات بحل التصميم؟ كنت أتوقع توقيع المكالمة لمكوناتنا ، أي ما هي الدعائم التي يمكن أن تستغرق معظم الوقت.

يمكنني الزحف إلى المزيد من المستودعات للنظر تحديدًا في استخدام withStyles أو makeStyles . حتى الآن نظرت فقط في استخدام الدعائم.

هل هذا شيء ترى نفسك تكتبهoliviertassinari؟

@ eps1lon لدينا تكرارات لهذا التداخل في قاعدة الشفرة (على سبيل المثال مع <strong i="8">@media</strong> (hover: none) ). لكنها ليست متكررة جدًا بالنسبة للمكونات الأساسية. أتخيل أنها نفس أرض المستخدم. يمكن أن يكون بالتأكيد جزءًا من المقايضة.

تضمين التغريدة

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. تعمل مجموعة الاختبار الخاصة بنا بشكل أبطأ بنسبة 50٪ في 3.7.4 مقارنة بـ 3.2.4 (~ 90 ثانية مقابل 50 ثانية).

سأستمر في التحقيق فيما إذا كان بإمكاننا الحد من عمق CSSProperties وإزالة دعم استعلامات الوسائط والمحددات الزائفة تمامًا. ومع ذلك ، فإن وجود أولئك الذين لم تتم كتابتهم ليس خيارًا حقًا. يجب أن يكون مدقق النوع قادرًا على التحقق من ذلك في وقت معقول.

قد يكون مدقق النوع هو عنق الزجاجة الفعلي. ربما يمكننا التحقيق في الإصدار الذي تم ضرب perf فيه.

إذا أرسلت لي الأوامر التي تقوم بتشغيلها في 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 's $ExpectError . في 3.7.4 واجهنا بعض الإخفاقات واضطررنا إلى تعديل اختباراتنا (انظر # 19242)

المشكلة الأولى هي أن نظام الكتابة لا يمكنه بالفعل التعبير عن الشكل الذي تريده.

كنت أظن كثيرا. يبدو أن الطريقة التي نمزج بها الشكل "الملموس" مع كائن بتوقيع الفهرس هي مجرد حل بديل.

هل يمكنني أن أفترض أنك مهتم بالمشاركة في هذا النقاش؟

قطعا. سأقضي وقتًا أطول قليلاً مع CSSProperties غير العودية ثم أكتب المزيد من الاختبارات لتوضيح ما نبحث عنه في هذه الأنواع. أظن أن حلول تصميم css-in-js الأخرى قد أصابت اختناقات أداء مماثلة.

سأحاول تنفيذ هذه الأوامر غدًا (أفترض أنني يجب أن أذكر أنني في وقت المحيط الهادئ وأحتفل بالعطلات الأمريكية).

يبدو أن الطريقة التي نمزج بها الشكل "الملموس" مع كائن بتوقيع الفهرس هي مجرد حل بديل.

شكرًا ، لقد كنت أعاني من أفضل السبل للتعبير عن ذلك. نعم ، أنت محق في أن توقيع الفهرس لا يفعل ما تريد. لدينا بعض الأفكار حول البديل الذي قد يكون ، لكننا بحاجة إلى استكشاف الآثار المترتبة على الأداء.

أظن أن حلول تصميم css-in-js الأخرى قد أصابت اختناقات أداء مماثلة.

كثير جدا هكذا. نأمل أن يتم تعميم أي شيء نقوم به من أجلك لتحسين النظام البيئي بأكمله.

أشعر وكأنني أفتقد شيئًا واضحًا ، لكنني عالق حاليًا. أولاً ، تخليت عن نظام Windows - يبدو أن الأمور تعمل بشكل أفضل على Linux. اسمحوا لي أن أعرف إذا كنت ترغب في البحث في ذلك. ثانيًا ، يمكنني الحصول على yarn typescript للتشغيل - بشكل نظيف ، بقدر ما أستطيع - ولكن يبدو أنه يعمل tslint ، بدلاً من tsc الخالص. عندما أقوم بتشغيل tsc على نفس tsconfig.json (أنا أختبر على وجه التحديد باستخدام الأنماط) ، أحصل على 40 خطأ. ما الخطأ الذي افعله؟ لأغراض التنميط ، سيكون الحصول على repro إلى استدعاء tsc واحد مفيدًا جدًا.

لا يتعلقamcasey yarn typescript بالتجميع ولكن باختبار الأنواع الخاصة بنا. نحن نستخدم إعدادًا مشابهًا للإعداد المستخدم في DefinitelyTyped repo. غالبًا ما تكون ملفات 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 شكرا

هذا الإعداد مثالي. أرى أن وقت الفحص يتضاعف بين 3.3 و 3.4.

| الإصدار | تحقق من الوقت |
| - | - |
| 3.2 | 16.71 ثانية |
| 3.3 | 16.79 ثانية |
| 3.4 | 35.25 ثانية |
| 3.5 | 21.40 ثانية |
| 3.6 | 23.10 ثانية |
| 3.7 | 27.39 ثانية |

سأحفر أكثر قليلاً ، لكن قيل لي أن تنفيذ 3.3 للأنواع الشرطية كان غير مكتمل ، وكان تنفيذ 3.4 بطيئًا ، والتنفيذ 3.5 جيد. لذا ، لسوء الحظ ، هذا متوقع على الأرجح.

على وجه التحديد ، أظن أن هذا التغيير أدى إلى التباطؤ كما هو موضح في هذا الخطأ .

أجد أنه فيما بين 3.5 و 3.7 كانت هناك زيادة قدرها 6 ثوانٍ في الوقت المستغرق لتشغيل الشيك. هذا يبدو جوهريًا جدًا.

embeddedt هذه الأرقام مأخوذة من عمليات تشغيل فردية مع كل إصدار ، لذلك من المحتمل أن يكون هناك قدر كبير من الضوضاء. ومع ذلك ، سأحفر وأرى ما إذا كان بإمكاني العثور على أي شيء.

لقد أعدت ذلك على Linux VM و 3.7 كان باستمرار 20-25 ٪ أبطأ من 3.5.

لقد ثبت أن هذا صعب للغاية لأن عمليات التشغيل المتتالية لنفس البنية تختلف بنسبة ~ 5٪ والفرق بين 3.5 و 3.6 أو بين 3.6 و 3.7 هو 10٪ فقط.

أحد الأشياء المشبوهة التي لاحظتها هو أن styled-components يوفر ملفات .d.ts منفصلة لـ TS> = 3.7 ، لذلك قد لا تكون المقارنة تفاحًا بالتفاح.

لدهشتي كثيرًا ، يبدو أن الأنواع الجديدة styled-components أسرع. ومع ذلك ، فإن مقارنة التفاح بالتفاح ستجعل التحقيق أسهل.

لم أستطع التفكير في حل ذكي ، لذلك سأخطط لدمج وقت التجميع عن طريق الدمج والبحث عن الارتفاعات. أتمنى الحصول على أرقام غدا.

@ amcasey نشكرك على جهودك في النظر في هذا الأمر! أنيق حقًا لرؤية أعضاء فريق TS و Material UI يعملون معًا. لقد عثرت على مشكلة Github هذه في محاولة لمعرفة سبب بطء تجربة المحرر مع Material UI (نحن نستخدمها في مشروعين في العمل). يمكن أن نؤكد بالتأكيد أننا نشهد تأثيرًا كبيرًا جدًا في التحسس وسهولة الاستخدام داخل VsCode.

في هذه المرحلة ، يسعدنا تداول القليل من أمان الكتابة في JSS لدينا للحصول على تعليقات سريعة لبقية المكتبة. في بعض الأحيان ، يستغرق الأمر من 8 إلى 10 ثوانٍ من الانتظار قبل أن يكتشف خادم Typescript تغييرات التعليمات البرمجية

حتى مع وجود متوسطات ثلاث مرات ، فإن البيانات صاخبة للغاية. ومع ذلك ، يبدو أن هناك انخفاضًا ملحوظًا في وقت التشغيل على https://github.com/microsoft/TypeScript/commit/ad322a561a301ae357da051b9221b2222c13be36 زيادة ملحوظة (تعود إلى المستوى السابق تقريبًا) على https://github.com/microsoft/TypeScript / الالتزام / 480b73915fdd805952fd355e4cf3e1bc803e0878 واتجاه تصاعدي عام بعد ذلك (على الرغم من أنه يبدو موحدًا جدًا بالنسبة لي وأظن أن العوامل البيئية) بما في ذلك ارتفاع معين على https://github.com/microsoft/TypeScript/commit/c5e6d95e930048a0338336297. سأركز على أول اثنين حتى أجري المزيد من الاختبارات لتأكيد الاتجاه الصعودي العام (كيف يمكن أن يصبح أسوأ بشكل موحد مع كل التزام؟).

الاتجاه التصاعدي يقف في وجه التدقيق وليس لدي أي فكرة عما يمكن أن يسبب ذلك. ربما تكون حالات التباطؤ المنفصلة قريبة جدًا من بعضها البعض لدرجة أن الضوضاء تجعلها تبدو وكأنها منحنى واحد.

لقد صدمت ما يصل إلى 10 أشواط لكل التزام والآن هناك أربعة انحدارات متميزة في المنطقة المنحدرة. :ابتسامة:

https://github.com/microsoft/TypeScript/commit/26caa3793e310e271ddee8adc1804486e5b0749f (700 مللي ثانية تقريبًا)
https://github.com/microsoft/TypeScript/commit/250d5a8229e17342f36fe52545bb68140db96a2e (500 مللي ثانية تقريبًا)
https://github.com/microsoft/TypeScript/commit/7ce793c5b8c621af5ce50af0ca3958c7bd6541bf (1300 مللي ثانية تقريبًا)
https://github.com/microsoft/TypeScript/commit/28050d5c47c6cd7627555f12cf13b1062f80322a (400 مللي ثانية تقريبًا)

(إجمالي الوقت قبل بدء الانحدار كان حوالي 33 ثانية.)

فقط لتهدئة التوقعات قليلاً: من المحتمل جدًا أن تتحول العديد من حالات الانحدار هذه إلى عمليات تحقق إضافية قيّمة ، وحتى إذا تمكنا من الحصول على كل هذه الشيكات مجانًا ، فإننا لا نزال نأخذ خصمًا بنسبة 20٪ فقط "لفترة طويلة جدًا ".

تحرير: لقد قمت بتحديث الروابط. نظرًا لأنني كنت أعود إلى الوراء عبر الزمن ، فقد شعرت بالارتباك وقمت بوضع علامة على الدمج قبل كل تراجع.

@ 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

تحذير منصف: من المحتمل أن يتم تحديد بعض هذه الأمور على أنها جديرة بالاهتمام.

أنا جديد تمامًا على عالم TypeScript ، لا سيما عندما يتعلق الأمر بحلول التصميم في JS ، لكنني كنت أتابع هذا الموضوع بهدوء خلال الشهر الماضي وكنت مهتمًا بسماع أفكار الناس حول حل بديل محتمل ، في الأقل في المدى القصير.

أفترض أن بعض المستخدمين (أنا نفسي) لا يستفيدون كثيرًا من نظام التصميم المدمج ، أو يتجنبونه تمامًا. أفعل ذلك بشكل أساسي لأنني أكثر دراية بـ CSS أو Sass العادي ولم أحصل على الوقت الكافي للبحث في كيفية استخدام نظام تصميم JS بشكل فعال. أفضل فقط تكوين أسماء الفصول الخاصة بي ، وكتابة ملف ورقة أنماط منفصل ، واستخدام أسماء الفئات داخل مكونات React الخاصة بي والاستمرار. في الأساس ، أنا أرتقي كما لو كنت أكتب HTML عادي.

ومع ذلك ، هل من الممكن / العملي إضافة علامة تقوم بإيقاف تشغيل فحص النوع للأجزاء باهظة الثمن من نظام التصميم (ربما عن طريق القيام بأشياء مشروط مثل type CSSProperties = any )؟ لا أعرف الإحصائيات الخاصة بأعداد الأشخاص الذين يستخدمون نظام النمط مقابل عدم استخدامه ، لكنني أعتقد أنه لا يمكن أن يسبب الكثير من الضرر (بشرط أن تتم إضافة فحص لاختبار الكتابة باستخدام مجموعة العلامات هذه) ، وستكون طريقة سريعة لتحسين الأداء لشريحة واحدة على الأقل من المستخدمين.

أردت فقط أن أذكر الفكرة العامة ؛ لا تتردد في إسقاطها. : قليلا_ابتسامة_الوجه:

embeddedt بشكل عام ، وضع علامة صراحة على شيء ما كـ any طريقة جيدة لتعطيل فحص النوع لهذا الرمز. بعد قولي هذا ، لا أستطيع أن أتذكر ما إذا كان يمكنك فقط ضرب إعلان سابق أو بالأحرى ، كما تقترح ، ستحتاج إلى دعم مترجم لتجنب مشكلات الإعلان المكررة.

أرقام جديدة (آلة مختلفة ، مقياس زمني مختلف):

| الإصدار | الوقت الإجمالي |
| - | - |
| 3.5.3 | 32.5 ثانية |
| 3.7.5 | 35.9 ثانية |
| سيد | 29.9 ثانية |

لا تزال بعض المشكلات التي نشرتها أعلاه مفتوحة ، لكننا نعود بشكل أساسي إلى 3.5 perf (بالنسبة لهذا المعيار). من الواضح أنه لا يزال أبطأ بكثير مما نود ، ولكن من المحتمل أن تكون الدفعة التالية من التغييرات على جانب واجهة المستخدم المادية.

تم اختبار 3.8.1 في مجموعة الاختبار الخاصة بنا ويبدو أنها بنفس سرعة الإصدارات السابقة باستخدام 3.2.4 (كان 3.7 كان أبطأ بشكل ملحوظ).

بصراحة ، لا أستطيع أن أصدق مقدار الأداء الذي تمكنا من استعادته دون التخلي عن الوظيفة الجديدة. : ابتسامة: أعتقد أنه قد يكون هناك مزيد من الركود (على سبيل المثال https://github.com/microsoft/TypeScript/pull/36754) ، لكنني ما زلت أشك في أن التغيير الأكثر تأثيرًا سيكون تبسيطًا لأنواع خصائص CSSProperties. هل سنحت لك الفرصة للعب مع هؤلاء على الإطلاق؟ يبدو أن مجموعة فرعية على الأقل من المستخدمين (على سبيل المثالembeddedt) سيكونون سعداء للتخلي عن نوع معين من التحقق في مقابل الفوز بالأداء.

يبدو أن مجموعة فرعية على الأقل من المستخدمين (على سبيل المثالembeddedt) سيكونون سعداء بالتخلي عن نوع من التحقق في مقابل الفوز بالأداء

ألم يقم أحد من فريق TS بالتغريد مؤخرًا أنه مقابل كل مستخدم يريد أنواعًا أكثر صرامة ، هناك شخص يريد أنواعًا أكثر صرامة؟ :ابتسامة:

بالنسبة لي ، لا يتعلق الأمر بالتحقق من النوع (تتمتع أدوات تطوير المتصفح بقدرات أفضل بكثير في فحص CSS). يتعلق الأمر أكثر بتوفير الإكمال التلقائي.

سألعب مع "إصدارات" مختلفة وأرى كيف تعمل.

amcasey لا أعتقد أن الطبيعة التكرارية لـ CSSProperties (تسمى CSSObject في المكونات المصممة) هي المشكلة الرئيسية. وإلا فإن أدائهم سيكون سيئًا مثلنا. راجع https://github.com/eps1lon/mui-types-perf/pull/6 وسجلات الاختبار .

قد يكون الأمر يتعلق بقدر أكبر من "التحميل الزائد" الذي نقوم به. يسمح styled-components فقط بكائن ثابت بينما نسمح بنسخة خادعة بالإضافة إلى كون كل خاصية خداعًا. لست متأكدا بالرغم من ذلك.

أرغب في تبسيط توقيع النوع (نظرًا لأنه من السهل أيضًا على المطورين فهم IMO) ولكن طُلب مني صراحة مطابقة تنفيذ JSS. الآن بعد أن دعمناها ، لا يمكننا التراجع بسهولة. خاصة إذا كان المكسب في منطقة الـ 20٪. لا أعتقد أن هذا يبرر الكسر.

هل يمكن جعل الأنواع أقل دقة بشكل مشروط (بناءً على إعداد المستخدم)؟ لا ينبغي أن يؤدي ذلك إلى كسر أي رمز موجود (لأنه يمكن إيقاف الإعداد افتراضيًا) ، وسيمكن المستخدمين مثلي الذين لا يحتاجون إلى الأنواع المعقدة من رؤية زيادة سريعة في الأداء.

ستمكّن المستخدمين مثلي الذين لا يحتاجون إلى الأنواع المعقدة من رؤية زيادة سريعة في الأداء.

لم يتم التأكد من أنك ستكسب فرقًا ملحوظًا. لقد رأيت 15٪ فوزًا في الأداء ، لكن من المشكوك فيه ما إذا كان هذا ممكنًا.

"إعداد المستخدم" الذي يمكنني رؤيته هو تصحيح الحزمة عند التثبيت. ليس لدينا عرض النطاق الترددي للحفاظ على إصدارات متعددة من الأنواع.

@ eps1lon معذرة ، أعتقد أن سؤالي ربما كان غير واضح. أعتقد أن CSSProperties جيد (على الرغم من أنه من الواضح أنه سيكون أسرع إذا كان أصغر) - كنت آمل في الواقع أن يكون هناك مجال لتبسيط الأنواع الفرعية في https://github.com/mui-org /material-ui/blob/master/packages/material-ui-styles/src/withStyles/withStyles.d.ts. على سبيل المثال ، هل ستحصل على عدد أقل من الإكمالات إذا غيرت هذا النوع إلى any ؟

تحرير: في الصندوق الخاص بي ، هذا يجعل تجميع المشروع docs 15٪ أسرع (29.7 ثانية وصولاً إلى 25.5 ثانية) ، لكني لا أعرف التأثير على تجربة التحرير.
تحرير 2: في الواقع ، بمجرد أن تتخلى عن الطي في الجزء العودي من النوع ، يمكنك فقط استخدام BaseCreateCSSProperties وستكون لأي خاصية أخرى النوع any (أي يمكنك الاحتفاظ بها الأنواع الحقيقية لخصائص CSS).
تحرير 3: لا يعمل التحرير 2 بسبب التحقق الزائد للخاصية (على سبيل المثال ، لا يُسمح بأسماء الخصائص التعسفية في الكائنات الحرفية).

كانت وجهة نظرك حول التحقق من الإكمالات والنوع مثيرة للغاية لأن لدي فرضية مفادها أن بعض مؤلفي النوع قد يشعرون بهذه الطريقة. DanielRosenwasser أعتقد أننا بحثنا في القيام بشيء مثل هذا لاستيعاب النمط "a" | "b" | string - هل ذهب ذلك إلى أي مكان؟

لاحظ أيضًا أن styled-components يواجه (نعتقد) مشكلات متعلقة بأداء المدقق.

فيما يتعلق بالقدرة على تحديد النوع بشكل أكثر دقة ، قمت بتقديم https://github.com/microsoft/TypeScript/issues/36782.

يبدو أن emotion قد يكون في نفس المركب.

لقد بدأت في إضافة واجهة المستخدم المادية ( 4.9.4 ) إلى مشروعي اليوم ، والتباطؤ مهم جدًا لدرجة أنني لا أعتقد أنه يمكنني حتى استخدامه في مشروعي. أضفت للتو مكوِّنًا بسيطًا <Slider/> ، تم تخصيصه باستخدام withStyles() .

نحن نتحدث عن الانتقال من ملاحظات TypeScript الفورية في IDE الخاص بي إلى ما يشبه 5-10 ثوانٍ في بعض الأحيان (لأجزاء من الكود الخاص بي التي لا تتفاعل حتى مع Material UI الآن - إنها مجرد تباطؤ كامل في TypeScript في الملف الذي يستخدم المكون). يجب أن يكون هناك شيء خاطئ بشكل كبير مع هذه الأنواع (أو نعم ، شديد التعقيد) ، يبدو أن

محاولة إيجاد طريقة يمكنني من خلالها على الأقل استبعاد جميع عناصر TypeScript مقابل @material-ui في الوقت الحالي (اجعل الوحدة بأكملها any ) - ولكن لا يبدو أن TypeScript تجعل ذلك سهلاً بدرجة كافية.

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(...) تقريبًا نصفين ~ (في الكود والكمبيوتر ، حوالي 1200 مللي ثانية -> 750 مللي ثانية ~ 1400 مللي ثانية ← 1100 مللي ثانية) encodedSemanticClassifications-full: elapsed time يظهر

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

يتحقق createStyles(...) بنية النمط حتى نتمكن من تخطي التحقق من نوع الوسيطة من نوع الاتحاد الضخم لـ makeStyles مقابل نوع الإرجاع من اتحاد ضخم لـ createStyles.

~ (والتعليق على كود makeStyles بالكامل: 650 مللي ثانية) ~

ypresto createStyles مطلوب فقط للإصدارات المطبوعة بدون تأكيدات const . إذا كان بإمكانك استخدام { display: 'block' as const } في قاعدة التعليمات البرمجية الخاصة بك (ts> = 3.4) ، فاستخدم ذلك أكثر من createStyles .

@ eps1lon لاحظنا ذلك وحاولنا إجراء التبديل في docs لكن النتائج كانت متواضعة.

@ eps1lon باستخدام const وبدون createStyles ، لم يعد IntelliSense يُظهر المرشحين المدركين للسياق بعد الآن: صرخة:

ypresto يجب. هل لديك مثال مقتطف رمز؟

تضمين التغريدة

تؤدي إضافة 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 بواسطة "kills it" ، هل تقصد "يتسبب في أن يعمل بنفس طريقة عمل 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">

إزالة CardProps & من FC هي نفس النتيجة تقريبًا. ربما يكون ذلك بسبب قيام CardProps بتوسيع PaperProps ، مما يؤدي إلى توسيع سمات HTMLA الكبيرة.

تحديث هام: اتضح أن استبدال CardProps بـ HTMLAttributes<HTMLDivElement> يقلل أيضًا من الوقت (لم يتم قياسه).

أخيرًا ، وجدت أكبرها ، 750 مللي ثانية → 130 مللي ثانية:

إزالة style={...} من اثنين من Typographys.

-<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 معقد جدا ..؟

(أنا أستخدم TypeScript 3.8.3، @material-ui/core 4.9.1)

تختلف طريقة AFAIK التي تتعامل بها Material-UI مع الأنماط المحلية على المكونات عن الطريقة التي يتعامل بها React مع عناصر 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";

@ eric-burel هذا إصدار به توسيع تلقائي لنوع النصوص المطبوعة. يحاول

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

شكرًا ، لقد تعلمت مفهومًا جديدًا "توسيع النوع" :) من الغريب أن fontStyle لم يتأثر على سبيل المثال ، إنها ليست خاصية CSS الوحيدة التي تم تعريفها على أنها تعداد ولكن في المرة الأولى التي قمت فيها بالضغط على هذا .

تحرير: طيب سيئة بلدي تم توثيقه جيدا: https://material-ui.com/guides/typescript/#using -createstyles إلى هزيمة من نوع توسيع

أخيرًا ، وجدت أكبرها ، 750 مللي ثانية → 130 مللي ثانية:

إزالة style={...} من اثنين من Typographys.

-<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 معقد جدا ..؟

(أنا أستخدم TypeScript 3.8.3، @material-ui/core 4.9.1)

هل وجدت أن هذا يؤثر على وقت البناء ، أو فقط الوقت الذي يستغرقه التحسس ليكون مفيدًا؟ أتلقى مشكلة الإنشاء (نفاد الذاكرة) وبعض كود TS الخاص بنا يحتوي على طن من style={someStyle} تعيينه على المكونات. أتساءل عما إذا كان هذا جزءًا من مشكلتنا.

@ yatrix7 ، بشكل عام ، أتوقع أن تؤثر أوقات الفحص الطويلة هذه على أوقات استجابة

أنا أي شخص يبحث في هذا حاليا؟ أعلم أنه كانت هناك بعض التحسينات فيما يتعلق بوقت التحقق من نوع الكتابة المطبوعة في ترقيات الإصدار السابق. ومع ذلك ، فهي لا تزال بطيئة.
لا مانع من النظر في هذا بنفسي.

لا مانع من النظر في هذا بنفسي.

سيكون ذلك رائعًا. لسنا على علم حاليًا بالعناصر القابلة للتنفيذ التي يتعين علينا العمل عليها. لذلك سيكون موضع تقدير أي مؤشرات للاختناقات.

تمت إضافة بعض المعايير في الوقت الحالي للمساعدة في التحقيق: https://github.com/mui-org/material-ui/pull/22110

FabianKielmann في نهاية TS ، كنت أعمل على أدوات التحقيق في الأداء التي آمل أن تصبح قريبًا ناضجة بما يكفي لتطبيقها على واجهة المستخدم المادية.

إذا كان لديك بعض الوقت لإنفاقه على ذلك ، فيمكنك أيضًا تجربة شيء مثل https://github.com/microsoft/TypeScript/issues/38583.