Material-ui: [RFC] حل تصفيف v5 💅

فقط لبعض التصحيحات:

صوّت مجتمع React بشكل عام ضد استخدام JSS على نطاق واسع.

أود أن أقترح بدلاً من ذلك أن مجتمع React لم يصوت لـ _ for_ JSS. ربما لم يتم "تسويقها" مثل الحلول الأخرى؟

لم نراهن على الحصان الصحيح.

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

العاطفة تبدو رائعة! أحب الحصول على دعم TS ، على سبيل المثال ، الإكمال التلقائي وجميع مزايا الكتابة - باستخدام CSS-in-JS - عند إنشاء واجهة المستخدم أو مكونات التصميم ، فهل سيظل ذلك ممكنًا؟

آخر قطعة حصلت علي! أرغب في المساعدة من خلال القيام بذلك خلف علامة تجريبية أو تطوير بعض الميزات:

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

لقد أشرت أيضًا إلى أن كائن الموضوع سيبقى كما هو ، وهو - في رأيي - أفضل طريقة على الإطلاق لتصميم تطبيق! ليس لدي ما أقوله: مندهش:

شكرًا على العمل الرائع على M-UI. أحب الاتجاه الذي يسير فيه المشروع.

الانتقال إلى طريقة تصفيف أكثر توحيدًا هو السبيل للذهاب. أعلم أن الفريق والمجتمع سيعملون على حل مكامن الخلل ، و v5 - من خلال أصواته - سيكون أكثر روعة! :صاروخ:

بصفتي شخصًا استخدم المكونات المصممة والعاطفة ، يمكنني أن أؤكد أن الانتقال بينهما سهل وغير مؤلم.

+ العاطفة هي أكثر ملاءمة للطباعة

التحدث كمشرف على Emotion - هذا يبدو رائعًا 🚀

يجب أن نكون قادرين أيضًا على إصدار برنامج رئيسي جديد قريبًا والذي لن يكون أي ثورة ، فقط بعض عمليات التنظيف والتحسينات الشاملة والخطافات أسفل الغطاء وتحسينات أنواع TS (استدلال وأداء أفضل)

أوه ، والمحلل اللغوي المعاد كتابته! يقضي على بعض أخطاء الحافة في Emotion و Styled-Components (كما هو الحال حاليًا ، كلاهما يستخدم نفس المحلل اللغوي). إنها أصغر وأسرع.

ماذا عن كسر التغييرات ، ما هو الخيار الذي يقدم المزيد من التغييرات العاجلة (إن وجدت)؟

لست متأكدًا مما إذا كان يحدث فرقًا ولكن هل تم إجراء المعايير باستخدام مكونات بابل الخاصة بالعواطف و / أو مكونات النمط؟ إنها تساعد على تحسين الأمور بشكل أكبر.

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

@ ee0pdt العاطفة تشبه إلى حد كبير

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

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

مع الإطار الذري يتحسن الأداء بمرور الوقت عالميًا ، عبر المكونات حيث يتم تخزين كل "فئة" ذرية مؤقتًا. من المحتمل ألا ينعكس في الاختبار أيضًا.

سعيد مع أي منهما طالما أنه يدعم SSR

لقد سحبت للتو تصويتي من مشكلة المكونات المصممة الأصلية: sweat_smile: - تعلمت أولاً معرفة المشاعر من خلال القصص المصورة ، لكن 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 مقابل 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 كلا ، لكن الأفضل هي تلك على أي حال من بين أفضل القلائل ، لذلك لا أعتقد أنه سيحدث أي فرق. دعوة جيدة صعبة!

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

مع الإطار الذري يتحسن الأداء بمرور الوقت عالميًا ، عبر المكونات حيث يتم تخزين كل "فئة" ذرية مؤقتًا. من المحتمل ألا ينعكس في الاختبار أيضًا.

تعليقاتي حول سبب استبعاد styletron-react قد تكون مضللة بعض الشيء آسف لذلك ، سوف يتم تحديث وصف العلاقات العامة على الفور. الأداء جيد ، لكن أكبر ما يقلقني مع Styletron هو المجتمع: https://www.npmtrends.com/styletron-react-vs-@emotion/core -vs-style-element بينما كل من العاطفة والمكونات المصممة أكثر من 2000000 تنزيل في الأشهر الستة الماضية ، بلغ عدد عمليات التنزيل حوالي 15000.

قد تتسبب أيضًا atomic css في حدوث مشكلات في التجاوزات ، حيث يحتوي كل اسم فئة على قاعدة واحدة فقط لأسلوب المصمم.

لدي سؤال إذا قررنا استخدام العاطفة نريد إضافة الكود أدناه فوق جميع الملفات؟
/ ** @ jsx jsx * /
هذا هو JSX pragma ، افتراضيًا JSX pragma هو React.createElement

تحتاج إلى إضافته إذا كنت تستخدم خاصية css في العاطفة. بالنسبة إلى واجهة برمجة تطبيقات styled بالإضافة إلى واجهة برمجة تطبيقات className العادية ، فلن تحتاج إليها.

من الممكن تخطي إضافة JSX pragma ، لكنه يتطلب إعداد Babel إضافيًا ويأتي بدعم أسوأ من الأدوات - على سبيل المثال ، TS غير قادر على التحقق من نوع CSS الخاص بك بدقة كما يفعل عند استخدام JSX pragma. يمكن العثور على مزيد من المعلومات هنا: https://github.com/emotion-js/emotion/pull/1941/files#diff -9abe25e5d2b00958d4b9849f5f20c139R5

mnajdova شكرا. كنت آمل فقط أن يتم تغطية استخدام الذاكرة أكثر من مجرد ضمان لـ Styletron على وجه الخصوص. بالنسبة للتنزيلات أو المجتمع - يستخدم Uber "فقط" Styletron :) لذلك لا تقلق. صوتت للعاطفة في المقام الأول.

سيكون رائعًا إذا كان هناك ملحق babel أو ما شابه ذلك يمكنه تحويل الأنماط الثابتة إلى فئات css حقيقية. توجد بالفعل مكتبة مشابهة تسمى compiled . معظم الأنماط واقعيًا ثابتة.

لكي تكون Fela مفيدة ، ستحتاج إلى مجموعة من المكونات الإضافية مثل fela-plugin-rtl ، fela-plugin-prefixer مما سيجعل الأداء أسوأ (https://github.com/microsoft/fluentui/pull/12289) 🐢 وبعد ذلك من المحتمل أن ينتهي بك الأمر بـ Emotion (https://github.com/microsoft/fluentui/pull/13547) لأنه في بعض الأحيان يمكن أن يكون أسرع مرتين من Fela 📦

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

في معظم الأوقات ، نحاول استخدام الدالة styled ، لكننا سعداء تمامًا بوظيفة makeStyles لإنشاء بعض الفئات في بعض الحالات.

نأمل ألا يكون هناك تغيير مفاجئ لهاتين APIs ، ولست مجبرًا على استخدام الماكرو css .

قلقي الوحيد هو الاضطرار إلى استخدام css thingy من Emotion.

yordis لن تضطر بالتأكيد إلى استخدام css . أظن أنه سيكون هناك درجة معينة من التغيير لاستخدامات makeStyles و withStyles . نأمل أن يقتصر مقدار التغيير الضروري في الغالب على codemod على الواردات. لا أعتقد أن الأسلوب المستخدم في makeStyles أو withStyles سيكون عمليًا لدعم استخدام المشاعر ، لذلك أتوقع أن يكون أي دعم مستمر لواجهات برمجة التطبيقات هذه من خلال حزمة منفصلة (بحيث " @ material-ui / core "لم يعد له تبعية JSS) والتي من المحتمل أن تتلقى الحد الأدنى من الصيانة فقط بعد إصدار v5 (التفاصيل حول ما يحدث لـ makeStyles و withStyles لم يتم تسميتها ومع ذلك ، فهذه مجرد تخميني حول الآثار المترتبة على المضي قدمًا في العاطفة).

👍 اختيار استخدام العاطفة. إن تجنب واجهة برمجة تطبيقات styled styled-components هو أحد الأسباب التي دفعت فريقي إلى اختيار Emotion (الذي يدعم أيضًا واجهة برمجة تطبيقات مماثلة styled بالإضافة إلى css ). نستخدم حاليًا Emotion لتخصيص نمط واجهة المستخدم المادية وهو يعمل بشكل جيد. دعم مدمج سيكون مجرد تثليج على الكعكة.

فيما يتعلق بهذه الحقائق:

يستخدم العديد من المطورين المكونات المصممة لتجاوز أنماط Material-UI. يجد المستخدمون النهائيون أنفسهم مع مكتبتي CSS-in-JS في حزمتهم

دعم الوضع المتزامن
المكونات المصممة: جزئية

إذا كانت المكونات المصممة تتمتع بدعم كامل للوضع المتزامن ، فهل سيكون خيارًا أكثر منطقية ، نظرًا لأن معظم المطورين يتخطون MUI مع المكونات المصممة (باستثناء JSS)؟ النقطة المتعلقة بكون العاطفة أصغر في حجم الحزمة موضع نقاش إذا كان من الضروري تضمين حلين css-in-js. وأفترض أن معظم التطبيقات العملية لـ MUI تتضمن تجاوز أنماطها.

عندما استخدم أنا وفريقي Emotion كطريقة رئيسية لمكونات التصميم ، صادفت بعض أوجه القصور الموجودة في مكتبة المشاعر. وأتساءل ما رأيكم يا رفاق في أوجه القصور هذه الموضحة أدناه.

النظر أدناه Emotion StyledComponent ؛

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 ) فوقها. مما سينتج عنه فئات css مع نفس دعائم css بالضبط لكل عنصر لوني ، انظر أدناه ؛

عدم كفاءة آخر وجدنا أنه عندما يتم اشتقاق مكون جديد من أعلى من StyledComponent فإنه سينشئ فئة جديدة مع نسخ جميع عناصر css من StyledComponent . النظر أدناه ؛

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

يقوم بإنشاء فئة css أخرى تضيف فقط font-family: monospace إلى فئة css أعلاه التي تم إنشاؤها من StyledComponent . أي أنه ينشئ ملف css يحتوي على جميع العناصر التي تم نسخها من StyledComponent كما هو موضح أدناه ؛

الآن إذا تم استخدام أكثر من StyledComponent و DerivedComponent معًا ، فلدينا (في البداية) فئتان من فئات css تحتويان على دعائم css مكررة (تختلف فقط في عائلة الخطوط). كما يتضح أدناه ؛

كما يمكنك أن تتخيل عددًا من فئات css التي تحتوي على دعائم css مكررة لبعضها البعض ، يمكن أن تنمو بسرعة كبيرة.

لقد وجدت أنه مع Emotion ، حيث يتم تكوين أنماط المكونات معًا ، ينتهي بنا الأمر مع فئات css مع العديد من دعائم css المكررة.

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

أنا لا أشكك في أداء Emotion في إنشاء وتطبيق CSSStyle في وقت التشغيل. العاطفة هي واحدة من أسرع الطرق في تطبيق أنماط CSS كما يتضح في اختبارات الأداء.
أنا فقط قلق من أن نمط CSS الناتج منتفخ. ونظرًا لأن Emotion يمكن أن تكون SSR (محرر) مما يعني أن الأنماط مضمنة في HTML ، فقد نتضخم بشكل غير ضروري (باستخدام علامات نمط css) في ملف HTML. وهذا بدوره ينتج عنه المزيد من العلامات لتحليلها باستخدام دعامات css غير الضرورية بواسطة المتصفحات.

إذا كانت المكونات المصممة تتمتع بدعم كامل للوضع المتزامن ، فهل سيكون خيارًا أكثر منطقية ، نظرًا لأن معظم المطورين يتخطون MUI مع المكونات المصممة (باستثناء JSS)؟ النقطة المتعلقة بكون العاطفة أصغر في حجم الحزمة موضع نقاش إذا كان من الضروري تضمين حلين css-in-js. وأفترض أن معظم التطبيقات العملية لـ MUI تتضمن تجاوز أنماطها.

petermikitsh الأسباب التي

• تكلفة انتقال صغيرة بين المكونات المصممة والعاطفة
  يجب أن يتمكن المطورون الذين يستخدمون بالفعل المكونات المصممة من استخدام المشاعر دون أي جهد تقريبًا.
• توجد طرق مختلفة لإضافة التجاوزات بخلاف مكونات الغلاف
  يمكن أن يكون دعم cx + css من العاطفة مفيدًا للمطورين لاستخدامه كبديل لإضافة تجاوزات النمط إذا كانوا لا يريدون إنشاء مكونات مجمعة.
• الوضع المتزامن مدعوم بالتأكيد 👍
• كيف يتم التعامل مع الخصوصية

مع أخذ النقطة الأولى في الاعتبار ، إذا أراد المطورون حقًا تجنب وجود حلين من حلول css-in-js في الحزمة ، فإن تكلفة الترحيل صغيرة جدًا للانتقال إلى العاطفة + فهي تدعم واجهة برمجة تطبيقات مختلفة بخلاف styled .

@ ko-toss شكرًا لك على كتابة هذا ، فهذه كلها نقاط جيدة. حقيقة أن العاطفة تولد اسم فئة واحد مع جميع الأنماط ، يجعلها المحرك الأفضل لحل التجاوزات. قد تكون المشكلة التي قد نواجهها مع إنشاء عدة classNames هي أن الفصل الأخير المكتوب سيفوز ، الأمر الذي قد يصبح مشكلة في المستقبل.

في مشروع آخر ، كنت أستخدم css الذرية ، حيث يكون استهلاك الذاكرة أفضل كثيرًا لأن جميع قواعد css مكتوبة مرة واحدة فقط ، ولكن إجراء تجاوزات يمكن التنبؤ بها هناك صعب جدًا ، حيث أن كل className هي قاعدة ذرية واحدة ، ومرة ​​أخرى أي واحد يفوز ، يعتمد على ترتيب كتابتها ، إذا لم تقرر مسبقًا معالجة جميع الأنماط ودمجها بشكل صحيح ، مما قد يؤثر على الأداء في النهاية.

من ناحية أخرى ، أعتقد أنه باستخدام أي حل css-in-js ، لن يقوم الأشخاص فقط بشكل عشوائي بإنشاء مجموعة لا حصر لها من الأنماط ، بل لا يزالون منظمين إلى حد كبير بناءً على قيمة الدعائم.

ومع ذلك ، مرة أخرى ، هذه نقاط جيدة ، سنضعها في الاعتبار ، شكرًا جزيلاً لمشاركتها 👍

• آخر؟

ماذا عن توافق فكرة [Stylex] (مثل [style9])

• آخر؟

style9 أو أي محرك CSS آخر متوافق مع فكرة التصميم

يبدو أن هذا يتطلب إعدادًا لوقت البناء والذي من شأنه أن يثني الكثير من الناس عن استخدامه ، وخاصة المبتدئين.

(هذا لمعلوماتك بالأحرى ، العاطفة اختيار جيد)

https://github.com/cristianbote/goober (1 كيلوبايت ، أداء أسوأ قليلاً من العاطفة)

ليس لدي خبرة في ذلك حتى الآن ولكني أريد تجربته يومًا ما.

cztomsik مشابه لـ https://github.com/kuldeepkeshwar/filbert-js ولكنه لا يدعم بناء جملة JavaScript (سلسلة قالب CSS فقط)

فيما يلي بعض الاختبارات التي تم إجراؤها باستخدام منارة Google في وقت التفاعل:

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

لمعلوماتك ، لقد قمت ببعض المعايير التفصيلية للمكونات المصممة v5 و emotion v10 و emotion v11 ، مع / بدون المكون الإضافي babel ، مع واجهة برمجة تطبيقات vanilla و css props API و API المصمم. أتمنى أن يساعد هذا في المناقشة!

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

هل فكرت في الموجة الجديدة من مكتبات css-in-js التي تعتمد بشكل كبير على css الذري ودعم الكتابة المطبوعة؟

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

هل فكرت في الموجة الجديدة من مكتبات css-in-js التي تعتمد بشكل كبير على css الذري ودعم الكتابة المطبوعة؟

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

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

إنه ليس على المعيار ، ولكن الدواء حاليًا أبطأ بمقدار 2 ~ 4 مرات من العاطفة. أعتقد أن otion لديها بالفعل إمكانات كبيرة جدًا وأعتقد أن هناك مجالًا للتحسين ، لكن otion ليس جاهزًا حقًا للإنتاج بعد.

لم أختبر الغرز بعد ، رغم ذلك. 😃

ماذا عن مكتبة فعلية لوقت التشغيل الصفري؟ لم أر أحداً يذكر ليناريا .

لقد تعثرت عبر ليناريا في مرحلة ما وأحبها حقًا. قلقي الوحيد هو أن أنماط الدعائم الديناميكية تعتمد فقط على متغيرات css ، ولا يوجد أي دعم لـ IE 11 استنادًا إلى https://github.com/callstack/linaria/issues/445 أيضًا مقارنة بـ styled-components و emotion المجتمع أصغر بكثير في هذه اللحظة.

تضمين التغريدة
ليناريا رائع.
إذا قمت بإعداده بشكل صحيح ، أعتقد أنه الأفضل من كل من css-in-js (من حيث خبرة التطوير) ، و css الخالص (لا يمكنه التغلب على أداء css الخالص). حتى أنه يحسن (يحذف) ويعيد استخدام قواعد المغلق.
لكن ليناريا يتطلب خطوة بناء وتجميع والتي ستكون صعبة للمبتدئين.

أود أن أرى منافذ لمكتبات css-in-js الأخرى ذات السطح المشابه لواجهة برمجة التطبيقات مثل filbert-js / goober

kuldeepkeshwar سنخبرك بمجرد النظر في محولات API المصممة :)

كيف يتناسب https://compiledcssinjs.com/ مع كل هذا؟ يبدو أنه نهج مثير للاهتمام بشكل لا يصدق ؛ تدير Compiled أيضًا RFCs للمشروع ، مما يثبت أنه رائع للمصدر المفتوح والتعاون. _غمزة غمزة_

أعتقد أن المستقبل مشرق للغاية لتصميم الويب ، وآمل أن تكون Material-UI جزءًا لا يتجزأ من حل go-to لتصميم أي تطبيق.

شرح كيف وصلت

يسمح لنا هذا النوع من التحول بتسليم المكون الخاص بك إلى أي مستهلك دون الحاجة إلى تكوين / إعداد أدواتهم. فقط استورد وانطلق. هذا أمر قوي ، والأهم من ذلك ، هو نفس عمل CSS الحالي في مكتبات JS - مع صيد واحد.

_CSS لا يمكن إنشاؤه في وقت التشغيل.

هذا القيد الوحيد يفتح لنا الكثير من الأبواب. بناء تحسينات الوقت. ضمانات وقت التشغيل. اختفت اختناقات الأداء.

في ملاحظة جانبية مختلفة ، أود أن أشير إلى أن الشعبية لا تعني الكثير لمشروع جيد. أنا أحب MUI والعمل الذي تم فيه حتى الآن ؛ أعتقد أيضًا أنه من الرائع أنه أصبح منتجًا متميزًا.
لكن اختيار _name_ "شائع" من أجل الشهرة ليس حجة معقولة.
لقد رأيت الإشارة إلى الشعبية عدة مرات ، وأنا لا أحب كثيرًا حتى التفكير فيما إذا كان عدد الأشخاص يستخدمون تقنية x - MUI (في كتبي) تركز على الأداء و DX وأشياء أخرى ، وليس مجرد الشعبية.

لم يكن لدى MUI دائمًا 60 ألفًا من النجوم ، بل حصلت عليها لأنها اختارت أفضل التقنيات (أو قريبة منها) ، وليس لأنها اختارت التكنولوجيا الشهيرة.

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

يستخدم الناس المنتج المناسب لأنه جيد ، وليس لأنه يستخدم تقنية شائعة ؛ كان MUI مكانًا مناسبًا مرة واحدة ولكنه أصبح مشهورًا على الرغم من احتوائه على CSS-in-JS ، والذي لم يفز بالتصويت الشعبي بالمناسبة. لديها فقط بعض الخصائص المدهشة واتخذت الخيارات الصحيحة التي لم تكن قائمة في المجتمع الحالي ولكن DX الفعلي والأداء.

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

للإنهاء فعليًا ، أنا ممتن لكل فكرة وأي قدر من الوقت للذهاب إلى MUI. لقد قدمت بعض الحلول المدهشة (الخاصة للأسف) وفقًا لجميع المعايير وما إلى ذلك في السنوات القليلة الماضية ، والتي كان من الممكن أن تستغرق شهورًا أو سنوات حتى يتم تنفيذها بمفردها! لا يمكنني وصف تقديري بما يكفي تقريبًا حتى يتألق على الورق 🙇‍♂️ 🙏 🙇‍♂️

أشعر بالفضول إذا كان المترجم حتى خيارًا وكيف سيعمل مع المحولات وما إلى ذلك. أعتقد أن النهج المترجم:

يجمع المترجم CSS الخاص بك في JS في وقت الإنشاء عن طريق التحليل الثابت للكود الخاص بك ثم تحويله إلى مكونات مجمعة. يتم تضمين كل ما نحتاجه لاستخدام المكون بجانبه في حزمة JavaScript.

هو طريق للتفكير فيه ، بالنظر إلى قيود "css في وقت التشغيل" المجمعة.

أنا أقول هذا بصفتي مشرفًا على العاطفة - المترجم رائع. أو بالأحرى - قد يكون في المستقبل ، هذه أشياء مثيرة للغاية ولكن لا يزال الوقت مبكرًا جدًا في التجريب. أشك بشدة في أن MUI يمكن أن تتماشى معها في هذا الوقت من الزمن.

صححني إذا كنت مخطئًا ولكن المترجم يعني وجود تكوين مما يعني أنه سيكون من الضروري وجود ملف تكوين لـ MUI حتى بدون استخدام أي أنماط مخصصة.

أنا أكره أن أجبر على إنشاء تكوين فقط لاستخدام MUI. في ملاحظة جانبية: ألن يكون من الصعب استخدام ذلك في برامج التمهيد ذات الرأي مثل Create React App؟

Andarist أتفق تماما. أود أن أقترح بدء تعاون أو على الأقل التفكير في المشاركة في تطوير المكتبة. أنا فضولي حول إلى أين يمكن أن يؤدي في المستقبل! : العيون: أعتقد أن شيئًا مثل مجمّع - كما تقول - سيكون رائعًا في المستقبل. سيكون من الرائع أن تجتمع المزيد من العقول العظيمة معًا لصنع شيء رائع.

shilangyu لست متأكدًا مما تعنيه ، لأنني قد الصفحة الأولى من المترجم يجب أن تقول عنها:

الهجرة إلى واقع التكوين الصفري

واجهات برمجة التطبيقات التي نحبها موجودة هنا من أجل الركوب - عنصر CSS وأسماء الفئات أيضًا! لا يحتاج عملاؤنا حتى إلى تغيير كيفية استهلاكهم لمكوناتنا ، ومواصلة قصة التهيئة الصفرية التي لا يحتاجون إليها لتكوين حزمة التجميع الخاصة بهم ، ولا يحتاجون إلى إعداد أي أشياء محددة لعرض جانب الخادم. إنه يعمل فقط.

مجرد البداية

مع وجود صفر config-of-the-box اليوم ، فإننا لا ننسى ما يمكن أن يبدو عليه الغد. مع إمكانية استخراج CSS الاختياري ، وتحويل CSS إلى شكل ذري ، وحتى القدرة على استخدام بيانات CSS للتحليل عبر قاعدة التعليمات البرمجية الخاصة بنا ، فإننا نفكر في غد مثير.

تضمين التغريدة
لقد بحثت في https://compiledcssinjs.com/ . ألا يزال وقت التشغيل css-in-js؟
يقوم بإنشاء فئات css في وقت الإنشاء ولكنه يطبق هذا النمط (ينشئ علامة نمط مع فئات css التي تم إنشاؤها في وقت الإنشاء) بعلامة <CC>...</CC> في وقت التشغيل.
إذا كان سريعًا مثل مجرد استخدام css النقي ، فهذا هو المستقبل حقًا (لأنه يستخدم متغيرات css). شكرا للمشاركة
أتساءل كيف أسرع مقارنة بالعاطفة.

ماذا عن مكتبة فعلية لوقت التشغيل الصفري؟ لم أر أحداً يذكر ليناريا.

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

لذا في حين أن وقت التشغيل الصفري هو على الأرجح الحل الأسرع ، فإنه يتطلب أيضًا مزيدًا من الاهتمام. أعتقد أن وجود حل خالٍ من التكوين يمكن تهيئته للتشغيل بدون وقت تشغيل سيكون مثاليًا على ما أعتقد.

لذا في حين أن وقت التشغيل الصفري هو على الأرجح الحل الأسرع ، فإنه يتطلب أيضًا مزيدًا من الاهتمام. أعتقد أن وجود حل خالٍ من التكوين يمكن تهيئته للتشغيل بدون وقت تشغيل سيكون مثاليًا على ما أعتقد.

لا يمكنني القول حقًا عن الحالة الحالية لـ Compiled ولكني كنت أتحدث عنها عدة مرات مع المشرف وهذه هي الخطة تقريبًا - الفكرة هي الحفاظ على دعم واجهات برمجة تطبيقات Emotion & Styled Components ، لذلك يجب أن يكون تحسين الكود المكتوب هذه مجرد مسألة تغيير الواردات بما في ذلك البرنامج المساعد للتحويل أو أداة تحميل webpack. من المؤكد أنه لن يتعامل مع جميع الكودات التي يمكن كتابتها (JS هي wild) ، ولكن يجب أن تكون قادرة على التعامل مع التعليمات البرمجية المكتوبة بشكل معقول. إذا لم تكن قادرة على تجميع شيء ما. سوف يرمي ببساطة - يجبر المرء على التخلي عن استخدامه أو إعادة كتابة جزء معين من الكود للمساعدة في التحليل الثابت.

لتلخيص ذلك - إذا ذهبت مع 0config Emotion (أو Styled Components) ، فيجب أن يكون من الممكن تكييف Compiled كتحسين اختياري في المستقبل (إذا كان المشروع سينجح في تقديم ما يعد به)

@ ko-toss أعتقد أنه يجمع في المكون المصمم في وقت البناء. في وقت التشغيل ، يتم نقل الأنماط من المكون إلى مكانها الصحيح.

كما يقولون على صفحة الويب:

يتم تضمين كل ما نحتاجه لاستخدام المكون بجانبه في حزمة JavaScript.

نأخذ الكود الأولي الخاص بك بكل مجدها:

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

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

ثم قم بتحويله إلى مكون مترجم:

...
...

ثم في وقت التشغيل سينقل الأنماط إلى رأس المستند.

يسمح لنا هذا النوع من التحول بتسليم المكون الخاص بك إلى أي مستهلك ، دون الحاجة إلى تكوين / إعداد أدواتهم. فقط استورد وانطلق. هذا أمر قوي ، والأهم من ذلك هو بالضبط نفس عمل CSS الحالي في مكتبات JS - مع صيد واحد.

لا يمكن إنشاء CSS في وقت التشغيل.

أعتقد أن وجود حل خالٍ من التكوين يمكن تهيئته للتشغيل بدون وقت تشغيل سيكون مثاليًا على ما أعتقد.

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

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

• التحليل الساكن - هذا كبير. فقط تخيل الحصول على البيانات المتعلقة بكيفية استخدامك لحل التصميم ، والحصول على توصيات بناءً على قاعدة X أو اصطلاح أو مواصفات ، وإظهار المكان الذي يمكنك تحسينه فيه
• التكوين الصفري - على الرغم من أنني سأعطي الأولوية لمزيد من الحرية لصالح الكسل (تثبيت مكون إضافي لـ x bundler)
• CSS-in-JSS إلى CSS خالص ، واستخراج الأنماط أساسًا في وقت التجميع لتضمينها بشكل ثابت ، دون الحاجة إلى وقت تشغيل.

فيما يتعلق بدعم IE11 ، كيف تنظر إلى الإحصائيات؟ أنا متأكد من أنه شيء قابل للتطبيق تمامًا. تعتمد Edge الآن على الكروم ، ويجب أن تقوم معظم الشركات بإجراء التبديل عندما يتوقف MS أخيرًا

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

سيكون من الجيد أن يكون لديك خيار عدم دعم IE11.

راجع https://github.com/mui-org/material-ui/issues/14420 لذلك.

لا نخطط لإسقاط دعم IE تمامًا. من المحتمل ألا يستهدف الإصدار الافتراضي IE 11 في الإصدار 5 ولكن لا يمكننا اختيار حل لا يعمل على الإطلاق في IE 11. أو بالأحرى يجب أن يكون حلاً يمكننا تبديله في وقت الإنشاء وإنتاج نفس الحل انتاج.

هذا يجعلني سعيدا.

هل هناك كود تعديل لتحويل jss الموجودة إلى نمط / عاطفة أتساءل؟

مرحبا جميعا. أنا أغتنم الفرصة لأتعمق في هذه المناقشة.

في الإصدار الحالي ، تستخدم واجهة المستخدم المادية استخدامًا مكثفًا لـ withStyles HOC بدون أي أنماط ديناميكية (النمط هو وظيفة تعتمد على الدعائم) ، والتي تستخدم داخليًا makeStyles . أداء makeStyles (بدون الدعائم الديناميكية) رائع جدًا ويمكن أن تكون واجهة المستخدم المادية أسرع إذا كانت تستخدمه مباشرةً ، بدلاً من withStyles ، مما يخلق غلافًا غير ضروري.

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

مقابل 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-components&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-components&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-components&cards=2500

بشكل عام ، emotion و styled-components متشابهة جدًا في الأداء. ومع ذلك ، يبدو أن makeStyles أسرع بمقدار 2-4x بشكل عام عند التركيب وإعادة العرض 6-8x أسرع للتحديثات.

الفرق كبير بما فيه الكفاية ، لا سيما عندما نعرض على أجهزة منخفضة الطاقة ، مثل هواتفنا .. وهناك الكثير من الهواتف الرديئة هناك.

كل هذا لأقول إنني قلق بشأن ترحيل المواد واستخدام emotion افتراضيًا ، مما سيقلل من أداء عرض واجهة المستخدم المادية والمواقع التي تستخدمها بعامل 3-5x. (هذا ليس صحيحًا في الواقع ، فهو يعتمد على المكون ؛ وكلما كان أكثر تعقيدًا ، قل الاختلاف).

بعض الأسئلة وطعام الفكر:

• هل يستحق DX حقًا مقايضة UX؟ حتى DX قابل للنقاش لأن الكثيرين يفضلون makeStyles
• مشكلة makeStyles يجب أن تتعامل مع الأنماط الديناميكية التي يبدو أنها قابلة للإصلاح من خلال تطبيق معرف ذاكرة التخزين المؤقت القطعي. في الوقت الحالي ، يحصل كل مثيل مكون على معرف خاص به للدعائم الديناميكية ، حتى إذا كانت الدعائم وأنماط الإخراج متماثلة ، مما يتسبب في زيادة وقت التشغيل ، والعديد من علامات الأنماط في الرأس ، وانخفاض أداء SSR. يبدو قابلاً للإصلاح باستخدام إستراتيجية التجزئة للأنماط الديناميكية ، تمامًا مثل العديد من CSS الأخرى في JS libs. ذات صلة: https://github.com/mui-org/material-ui/pull/16858
• هل هناك أي مجال لتحسين emotion و styled-components للاقتراب ، أو حتى أن تكون أفضل من makeStyles ؟
• هل ستدعم Material UI محول محرك JSS رسمي بحيث يمكن للمطورين اختياره للحصول على أداء أفضل؟

يمكنني العيش مع خسارة صغيرة في الأداء.

ليست خسارة أداء بنسبة 300٪ ، وليس بأي ثمن. 😅

satazor شكرا لاستكشاف هذا. لقد أجرينا اختبار أداء مكثف قبل بدء هذا الجهد ، راجع PR https://github.com/mui-org/material-ui/pull/22173 لمزيد من التفاصيل (لقد فعلنا ذلك في مكون ListItem) وكان اختلاف الأداء في معظم 10٪ لتقديم 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-5 مرات أكثر من اللازم بالنسبة لي ، وهذا يجعلني أتساءل لماذا يستخدم أي شخص emotion / styled-compoenents إذا كان هذا هو الحال .. يمكننا المحاولة لمعرفة مكان الاختلاف بين المعيارين ، في حالة فقد شيء ما. أيضًا ، سيكون إجراء معايير على مكون MUI حقيقي أفضل بكثير في رأيي ، لذلك سنحصل على أرقام أكثر واقعية ، لذا أخبرني إذا كنت تريد استكشاف المزيد في هذا الجانب. العلاقات العامة التي ربطتها هي نقطة انطلاق جيدة.

شكرا على الردmnajdova. أنت محق في أن الاختبار على مكون Mui سيكون أكثر واقعية. ما يحدث على الأرجح هو أن رمز Mui لمكونات القائمة هو عامل البطء السائد ، والفرق بينهما (حوالي 30 مللي ثانية) هو فرق وقت العرض الفعلي المرتبط بالأنماط. سآخذ رمز ذلك العلاقات العامة وأضيفه إلى المعيار ، لمعرفة النتائج.

هل هذا مهم في النهاية؟ ربما لا ، لكن ذلك يعتمد على التطبيق. سيزداد فرق الأداء بين مكونات Mui الحالية والمكونات المصممة لأن كود العرض نفسه أبسط. على سبيل المثال ، أتوقع أن أرى اختلافات متزايدة في مكونات الأيقونة أو الطباعة ، لكن الاختلافات انخفضت في البطاقات. لذلك ، يعتمد الأمر حقًا على التطبيق وكمية مكونات كل نوع يستخدمه التطبيق.

مما سيقلل من أداء العرض لواجهة مستخدم المواد والمواقع التي تستخدمها بعامل 3-5x.

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

باستخدام ملحق devtools ، رأيت 140 مللي ثانية للتثبيت العاطفي مقابل 120 مللي ثانية للتثبيت باستخدام makeStyles.

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

أنت على حق ، انظر تعليقي السابق.

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

باستخدام ملحق devtools ، رأيت 140 مللي ثانية للتثبيت العاطفي مقابل 120 مللي ثانية للتثبيت باستخدام makeStyles.

لقد قمت بتحديث معيار الأداء لاستخدام actualDuration بدلاً من baseDuration ، لذلك يجب أن نرى الآن قيمًا أكثر انسجامًا مع ما هو معروض في ملف تعريف devtools. يقيس baseDuration الوقت بدون مذكرات ، بينما actualDuration هو العكس. يرجى ملاحظة أن هذا التغيير لا يؤثر إلا على أداء العرض ، والآن أرى makeStyles 6-8x أسرع لعمليات إعادة العرض ، مما يعني أنه يحتوي على ذاكرة تخزين مؤقت / ذاكرة أفضل؟ ومع ذلك ، فأنا لا أفهم القيم التي تراها. هل يمكنك المحاولة مع الروابط المحدثة؟

satazor لا أعتقد أن حالات الاختبار الخاصة بك متكافئة. يجب أن نكون جيدين.

هناك بعض التغييرات التي يمكنك محاولة فهمها وسيؤدي ذلك إلى تقليل اختلاف الأداء:

• تركيب مكونات التفاعل له تكلفة ، خاصة عند تقديم الكثير منها. يستخدم makeStyles div مباشرة بينما تنشئ العاطفة / sc مكونات جديدة. في معيار الجدول الخاص بنا ، لقد جربت أن كل مكون إضافة يضيف وقت عرض خط الأساس ، لذلك إذا كانت 3 مستويات من المكونات => x3 (أو لماذا <MenuItem> أبطأ بـ x10 تقريبًا من <li> ).
• يُنشئ العرض التوضيحي الخاص بك مع makeStyles ورقة أنماط واحدة ، أما العاطفة / sc لا تفعل ذلك. حاول استخدام ورقة أنماط واحدة مع محددات CSS لاستهداف العناصر الموجودة في كل حاوية بطاقة. أو قم بالعكس ، قسّم ورقة أنماط makeStyles الرئيسية إلى عدة أنماط ، واحدة لكل عنصر.

في الواقع ،oliviertassinari. يبدو أن الأداء للمضي قدمًا مع عناصر العاطفة / الأنماط هو أكثر في عامل 1.5x-2x كحد أقصى حتى بالنسبة للمكونات البسيطة ، مثل Typography ، والذي قمت بتطبيقه هنا: https://codesandbox.io/ s / css-in-js-Comparison-forked-lr3sr؟ file = / src / element / EmotionTypography.js.

تحقق من بناء الإنتاج والمعيار على: https://csb-lr3sr-7lp24bj5l.vercel.app/

makeStyles أسرع بمقدار 1.5-2x في التركيب وأسرع بـ3-4 أضعاف في إعادة العرض. من المحتمل أن يكون هذا شيئًا يجب مراقبته ، لكنني أعتقد أن الانحراف سيكون أصغر بكثير بالنسبة للمكونات الأكثر تعقيدًا.

لذا ، في الختام ، لم أعد قلقًا بشأن الأداء وأنا أتطلع إلى رؤية كيف سيبدو هذا الجهد.

mnajdova إليك https://csb-lr3sr-3zi42510w.vercel.app/؟components=1000 ، منسوخة من العلاقات العامة التي ذكرتها. رابط Codesandbox: https://codesandbox.io/s/css-in-js-comparison-forked-6s4nl

makeStyles أسرع بمقدار 1.7 مرة عند التحميل ، و 2.2 مرة أسرع عند العرض. لا أحصل على 10٪ فرق الذي تراه. أفعل شيئا خاطئا؟

satazor ممتع ، شكرًا

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

مقابل (العاطفة).

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

مقابل (المكونات المصممة).

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

في هذه المرحلة ، من الصعب معرفة سبب إبطائها. قد لا يكون عنق الزجاجة في الأنماط. وتذكر أنني قمت بتشغيله في وضع dev!

لقد أضفت صفحتين جديدتين لإلقاء نظرة على أداء إصدار 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 :

• نصب المكونات: https://codesandbox.io/s/preact-material-ui-test-forked-lum1y؟file=/src/index.tsx mnajdova لالشوري، واضطررت الى استخدام الطرود، لم أستطع استخدام نموذج CRA.

لاحظ أيضًا أننا نعلم أنه يمكننا جعل إصدار JSS الحالي x1.1 أسرع باستخدام makeStyles بدلاً من withStyles: # 15023.

oliviertassinari في وضع المنتج تصبح الأمور أسرع قليلاً ، لكني أعتقد أن الاختلافات تبقى هناك. يمكنك النقر فوق "نشر> vercel" في وضع الحماية للكود للنشر السريع باستخدام علامات إنشاء الإنتاج.

بالنظر إلى كيفية تنفيذ makeStyles ، أرى كيف يكون الأمر أسرع عندما تستخدم فقط الأنماط الثابتة :

1. في كل مرة يتم استدعاء attach .
2. إذا كان هذا هو المثيل الأول لهذا النوع من المكونات ، فسيتم استدعاء stylesCreator.create ، والذي بدوره يستدعي fn المحدد بـ makeStyles(fn) .
3. في كل حالة أخرى ، يتم تخطي stylesCreator.create لأن عدد المرجع هو> 0.

للعرض:

1. في كل عملية إعادة عرض ، يتم استدعاء attach .
2. بعد ذلك ، تم تخطي stylesCreator.create لأن عدد المراجع> 0 ، لذلك لم يتم إنجاز أي عمل على الإطلاق.

يرجى ملاحظة أنه إذا كانت الأنماط الديناميكية قيد التشغيل ، فسيتم تحديث الأوراق هنا ، في كل تحميل وعرض.

على العكس من ذلك ، يبدو أن styled-components و emotion يقومان بتشغيل وظائف التصميم الخاصة بنا على كل مثيل مكون ، مما ينتج عنه المزيد من دورات وحدة المعالجة المركزية وضغط الذاكرة. اعتقدت أنهم يستطيعون بطريقة ما عمل ذاكرة تخزين مؤقت متعددة المذكرات بناءً على مجموعة الدعائم ، ولكن هذا من شأنه أن يفترض أن وظائف التصميم نقية ، وهو ما قد لا يكون كذلك ، فكر في:

     const someContext = useContext(FooContext);

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

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

أرى بعض الاتجاهات المحتملة التي يمكننا استكشافها:

• في وصف المشكلة الأولية ، قمنا فقط بقياس الأداء من خلال الدعم الديناميكي لـ Material-UI. يمكننا إضافة إدخال للحالة الثابتة (ما يستخدمه الإصدار 4). يمكن أن يكون لدينا أيضًا حالة رد فعل- jss ثابت وديناميكي. يجب أن يساعدنا هذا في فهم نطاق خيارات محرك النمط المتاحة.
• يمكننا التحقيق في مكان عنق الزجاجة. يمكننا تخيل وجود محول لـ jss ، كما هو الحال لدينا للمكونات المصممة ، ومعرفة ما إذا كان الأداء أفضل. يجب أن يكون الأمر أسوأ بكثير مع الإصدار الديناميكي من JSS ، لكن يمكننا مقارنته بالإصدار الثابت. ربما يأتي من التجريد غير المصمم.
• يمكننا اعتبار التباطؤ ثمنًا يستحق الإنفاق لفتح الأنماط الديناميكية وغير المنظمة. إذا كنت ترغب في عرض قائمة طويلة ، فستستخدم المحاكاة الافتراضية أو الاعتماد على محددات CSS المتداخلة.
  لقد أثبتت مكونات المشاعر والأناقة أنها توفر المرونة والسرعة الكافية من قبل الصناعة ، وكذلك فعلت React.

إذا بطريقة أو بأخرى emotion يتعرض useCss هوك مثل طلب في https://github.com/emotion-js/emotion/issues/1321 و https://github.com/emotion- js / emotion / issues / 1853 ، يمكننا الاحتفاظ بواجهة برمجة تطبيقات makeStyles وبالتالي ، فوائد "CSS الثابتة". ومع ذلك ، سنواصل استخدام CSS الثابت في كل مكان ، لتعزيز الأداء ، وهو ليس "نظيفًا" ولكن هذا ما نقوم به بالفعل في الإصدار 4.

في الواقع ، مع ClassNames API ، أعتقد أنه يمكننا عمل منفذ withStyles الوقت الحالي من شأنه أن يحتفظ بفوائد أداء CSS الثابت والأداء الجيد لـ CSS الديناميكي الذي تتمتع به هذه المشاعر. إذا كان const css = useCss() موجودًا ، فسيكون من السهل إنشاء منفذ API useStyles أيضًا.

المزايا الرئيسية للاحتفاظ بـ withStyles + makeStyles API التي تستخدم العاطفة تحت الغطاء هي:

• الترحيل الذي يجب أن تقوم به المادة ليس من الناحية العملية ، نحتاج فقط إلى إنشاء منفذ هاتين الوظيفتين.
• المستخدمون الذين يستخدمون بالفعل withStyles و makeStyles خارج واجهة المستخدم المادية ، لن يحتاجوا إلى الترحيل على الإطلاق. سوف يستفيدون من الأداء المحسن لـ CSS الديناميكي مجانًا.
• ليس هناك حاجة إلى منطق إضافي للاحتفاظ بواجهة برمجة تطبيقات CSS classes +. باستخدام styled سنحتاج إلى إنشاء className s عالميًا يدويًا أو باستخدام.
• في هذه الإستراتيجية ، useCss هي وظيفة المحول الخاصة بنا لـ CSS في حلول JS ، بدلاً من styled .
• لدعم CSS الأخرى في حلول JS ، سيحتاجون إلى توفير خطاف useCss أو ما شابه. من الناحية المثالية ، سنكون قادرين على عمل الاسم المستعار webpack / babel لتبديلهما ، تمامًا مثل styled .

لقد استكشفنا مشكلة الأداء بشكل أكبر في https://twitter.com/olivtassinari/status/1309247827839680512. أعتقد أنه يمكننا المضي قدمًا كما هو. بالنسبة للفرق التي تهتم بشدة بالأداء ، يمكنها الاشتراك في المكونات غير المنظمة ، فهي توفر أداءً أفضل. بالنسبة للآخرين ، مثل معظم الصناعة ، فإن العواطف والمكونات الأنيقة جيدة بما فيه الكفاية.

• أصلي: 7.71 مللي ثانية
• الإصدار 5 غير المصمم: 20.89 مللي ثانية
• الإصدار 4: 29.93 مللي ثانية
• الإصدار 5: 37.37 مللي ثانية
• أنتد: 53.48 مللي ثانية
• شقرا: 64.67 مللي ثانية

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

آسف لأنني أزعجتك هنا في وقت متأخر جدًا من المناقشة ولكني مندهش قليلاً لأنك لا تبحث عن كثب في style-jsx

استوفت قائمتهم متطلباتك بالضبط:

• يعمل الخادم والعميل
• دعم CSS الكامل ، لا مقايضات في السلطة
• حجم وقت التشغيل 3 كيلوبايت فقط (مضغوط ، من 12 كيلوبايت)
• عزل كامل: محددات ، رسوم متحركة ، إطارات مفتاحية
• بادئة مدمجة لبائع CSS
• شفط سريع جدًا ، بسيط وفعال (انظر أدناه)
• وقت تشغيل عالي الأداء - حقن CSS عند عدم عرض الخادم
• مقاوم للمستقبل: مكافئ لـ "Shadow CSS" الذي يمكن عرضه على الخادم
• دعم خرائط المصدر
• أنماط وموضوعات ديناميكية تدعم
• المعالجة المسبقة لـ CSS عبر المكونات الإضافية

أود أن أنتبه إلى حقيقة أنها عبارة عن واجهة برمجة تطبيقات قياسية لـ Shadow CSS . لذلك من خلال إزالة السمة jsx فأنت جيد للانتقال إلى مكونات الويب في المستقبل التي تعمل بالفعل في المتصفحات العادية راجع للشغل.

نعم ، أعلم أنه قد لا يكون الأكثر شعبية.
لكني أريد فقط أن أشير إلى أن Flash كان مشهورًا جدًا منذ بضع سنوات.
لكنها جفت في النهاية لعدم توافقها مع معايير الويب ، ولدينا SVGs الآن.
فقط للتسجيل ، كان معيار SVG موجودًا لفترة طويلة عندما كان Flash يحكم الصناعة.
أنا فقط أنظر إلى الأحداث التاريخية على أنها دروس جيدة وسأحاول تحديد النمط القائل بأن الشعبية هي المؤشر الأخير لكونها قابلة للصيانة وقابلة للصيانة في المستقبل.

mifrej لقد https://github.com/vercel/styled-jsx/issues/142.

لقد استكشفنا مشكلة الأداء بشكل أكبر في https://twitter.com/olivtassinari/status/1309247827839680512. أعتقد أنه يمكننا المضي قدمًا كما هو. بالنسبة للفرق التي تهتم بشدة بالأداء ، يمكنها الاشتراك في المكونات غير المنظمة ، فهي توفر أداءً أفضل. بالنسبة للآخرين ، مثل معظم الصناعة ، فإن العواطف والمكونات الأنيقة جيدة بما فيه الكفاية.

• أصلي: 7.71 مللي ثانية
• الإصدار 5 غير المصمم: 20.89 مللي ثانية
• الإصدار 4: 29.93 مللي ثانية
• الإصدار 5: 37.37 مللي ثانية
• أنتد: 53.48 مللي ثانية
• شقرا: 64.67 مللي ثانية

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

هل جربت ملحقات babel للعاطفة / المكونات المصممة؟ هل أحدثت فرقا في التوقيت؟

ماذا يعني التغيير من JSS للميزة classes المتوفرة على مكونات MUI الحالية؟ كيف سيبحث ترحيل الإصدار 5 عن المستخدمين الحاليين الذين يستفيدون من هذه الدعامة على نطاق واسع؟

نتصور أن يستخدم الأشخاص الصيغة التالية بدلاً من ذلك: https://next.material-ui.com/components/slider-styled/#unstyled -slider يتم استبدال الفئات أساسًا بمحددات الفئة المتاحة لكل فتحة في المكون. يمكنك أيضًا إلقاء نظرة على مثال التخصيص: https://next.material-ui.com/components/slider-styled/#customized -sliders

كميزة ، يمكنك فقط استخدام الدعائم وتطبيق أنماط ديناميكية بناءً عليها.

نتصور أن يستخدم الأشخاص الصيغة التالية بدلاً من ذلك: https://next.material-ui.com/components/slider-styled/#unstyled -slider يتم استبدال الفئات أساسًا بمحددات الفئة المتاحة لكل فتحة في المكون. يمكنك أيضًا إلقاء نظرة على مثال التخصيص: https://next.material-ui.com/components/slider-styled/#customized -sliders

كميزة ، يمكنك فقط استخدام الدعائم وتطبيق أنماط ديناميكية بناءً عليها.

أنا أحب واجهة برمجة التطبيقات هذه! تغيير مرحب به للغاية ، ويبدو أنه يلعب بشكل جيد مع محركات الأسلوب.

قبل v5 ، إذا كنت أتذكر بشكل صحيح ، فسيقوم مترجم JSS بتشويه أسماء الفئات ولا يمكنك استهدافها بشكل موثوق؟ ولكن يبدو الآن أنهم سيتعرضون لأغراض الاستهداف؟ 🙌 أيضًا ، كانت هناك مشكلة في أسبقية CSS. وهل يتم حل هذه المخاوف مع هذا النهج الجديد؟ شكرا لعملك على هذا المعيد!

ConAntonakos بالضبط يمكن استهداف هذه الفئات لكلٍ من الإصدارات غير المصممة والمُصممة من المكونات. يضمن الترتيب الذي يتم استدعاء النمط منه فوز الأنماط الجديدة ، بالطبع إذا كانت الخصوصية هي نفسها :)

قبل الإصدار 5 ، إذا كنت أتذكر بشكل صحيح ، فسيقوم مترجم JSS بتشويه أسماء الفئات ولا يمكنك استهدافها بشكل موثوق؟

يمكنك بالفعل استهدافهم في الإصدار 4.

يتم استبدال الفئات أساسًا بمحددات الفئة المتاحة لكل فتحة في المكون.

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

أعتقد أننا قررنا الاحتفاظ ببعض من واجهة برمجة التطبيقات القديمة لتقليل عدد التغييرات العاجلة.

قررنا الاحتفاظ بنفس واجهة برمجة التطبيقات لـ 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 العالمية التي تتسرب بين الأطفال: على سبيل المثال ، في .css-e7ylz8 .MuiTreeItem-group . ليس لديك ضمانات بأن المكون لا يطبق النمط على مكون فرعي (وليس التأثير الذي كنت تتوقعه ، مفاجأة!). ربما يكون جيدًا لمكوناتنا حيث سنكون حذرين.
2. اجعل التعامل مع البوابات أمرًا لا يحتاج إلى تفكير: https://material-ui.com/guides/interoperability/#portals. لتصميم التلميح ، سنحتاج إلى تصميم مكون بوبر ، وليس الجذر كما فعلنا مع شريط التمرير.
3. يحذر بناء الجملة $styleRule إذا كانت قاعدة النمط غير محددة.
4. السماح بتخصيص أسماء الفئات المستخدمة. الحل الحالي هو استخدام componentsProps . نقوم بدمج أسماء الفئات.

يوجد عالم بديل حيث يمكننا:

أ. السماح لحل 1. و 3. مع محددات المكونات المصممة .
ب. كشف واجهة برمجة تطبيقات classes للتوافق مع الإصدارات السابقة.
ج. من أجل الحصول على ملف. وب. بالعمل ، سنحتاج إلى تسوية كيفية كتابة أنماط المكون داخليًا. x مكون على غرار بدلاً من جذر واحد. لكن ⚠️ مع ضمني الكمال.

هل نحن حقا بحاجة لفعل ذلك؟

لقد ألقيت نظرة على تاريخ خاصية 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/components/slider-styled/#unstyled -slider يتم استبدال الفئات أساسًا بمحددات الفئة المتاحة لكل فتحة في المكون. يمكنك أيضًا إلقاء نظرة على مثال التخصيص: https://next.material-ui.com/components/slider-styled/#customized -sliders

كميزة ، يمكنك فقط استخدام الدعائم وتطبيق أنماط ديناميكية بناءً عليها.

واو ، هذا أفضل شيء على الإطلاق.
المكونات غير المصممة أو بدون رأس ستكون أفضل شيء للتخصيص (أعتقد أن أحد منتقدي mui).
هذا ليس شيئًا صغيرًا لإصلاح imo ، ولكنه ميزة إضافية لـ MUI.

ملاحظة: أتذكر بعض الوقت الصعب في تخصيص بعض المكونات في الماضي
PS2: هل ألقيت نظرة على https://github.com/modulz/stitches ؟

ستلاحظ أنني أخطأت في كتابة MuiSlider-rail عن طريق الخطأ. في السابق مع الفصول ، سيكون هناك شيء مثل class.rail ، وإذا أخطأت في كتابة الخاصية ، فسأحصل على تحذير وقت التشغيل من أن class.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 يمكننا أيضًا التفكير في إضافة eslint.

فيما يتعلق بالدعم الموجود على classes - لكي نتمكن من القيام بذلك بشكل موثوق ، سيتعين علينا إنشاء مكونات لكل جزء (فتحة) من المكون الأساسي. على سبيل المثال ، بالنسبة إلى Slider ، سنحتاج إلى إنشاء مكونات للسكك الحديدية ، والمسار ، والعلامة ، وتسمية العلامة ، والإبهام ، وعلامة القيمة. سيسمح لنا هذا بتحديد الأنماط مباشرة على تلك المكونات ، بدلاً من استخدام الفئات لزيادة الخصوصية. يمكن العثور على هذه التغييرات في هذه العلاقات العامة - https://github.com/mui-org/material-ui/pull/22893

من خلال هذه التغييرات ، أنشأنا رمزًا وصندوقًا ، يمكنه مقارنة أداء مكون Slider المحدث الجديد هذا مقارنةً بالإصدار v4 ، المصمم على الطراز الأصلي ، وغير المصمم ، بالإضافة إلى مكتبتين منافستين أخريين - https://codesandbox.io/s/ slider-Comparison-with-multiple-components-2tytc؟ file = / package.json

إذا قارنا هذه الأداء مع الأداء المتمثل في وجود مكون واحد فقط واستخدام محددات الفئات لأجزاء منه - https://codesandbox.io/s/slider-comparison-forked-jziv6؟file=/src/App.js سوف نلاحظ أن إضافة مكونات لكل فتحة لها تدهور بنسبة 20٪

إصدارات الإنتاج:

• مكون واحد - https://csb-jziv6-99lfgp8e6.vercel.app/
• مكون لكل فتحة - https://csb-2tytc-pz2xlac86.vercel.app/

لأكون صريحًا ، لا أعرف في هذه المرحلة ما إذا كان من الأفضل إضافة هذا التوافق مع الإصدارات السابقة أم لا.

هل هذه حالات استخدام حقيقية لدعم classes أم أنها فقط لتسهيل الترقية؟
هل نحن موافقون على وجود 20٪ تدهور في الأداء فقط لتسهيل مسار الهجرة؟
هل هناك بعض البدائل التي لا يمكننا رؤيتها ، والتي من شأنها أن تساعدنا على القيام بكليهما دون دفع تكلفة الأداء؟

ianschmitz @ eps1lon oliviertassinari وآخرون :) هل هناك أي أفكار حول هذا؟

طالما أنه يمكننا تحديد واستخدام السمات والأنماط مع TypeScript ، فلن أمانع في قضاء الوقت في الترحيل مقارنة بخسارة 20٪ من الأداء

أنا فضولي بشكل عام ، وأعذرني إذا لم أفهم التصميم الأساسي ، ولكن classes كان واجهة برمجة تطبيقات لـ JSS؟ إذا كان تصميم واجهة برمجة التطبيقات يتحول من JSS إلى المكونات المصممة ، فهل من المنطقي الاستمرار في دعم classes ؟

هل هذه حالات استخدام حقيقية لدعم classes أم أنها فقط لتسهيل الترقية؟
هل نحن موافقون على وجود 20٪ تدهور في الأداء فقط لتسهيل مسار الهجرة؟
هل هناك بعض البدائل التي لا يمكننا رؤيتها ، والتي من شأنها أن تساعدنا على القيام بكليهما دون دفع تكلفة الأداء؟

أعتذر إذا فاتني أي شيء مع واجهة برمجة التطبيقات المقترحة ، ولكن IMO حالة الاستخدام التي أراها في أغلب الأحيان داخل مؤسستنا هي تجريد نظام التصميم الأساسي الذي تستخدمه MUI. نعم أعتقد أن classes هو نوع من "API لـ JSS" كما ذكر ConAntonakos ، لكن بالنسبة للمستهلك لا يهم. كمستهلك ، يمكنني استخدام تقنية CSS المفضلة (هل هناك أي قيود اليوم مع classes ؟). لدينا عدد من المنتجات باستخدام مجموعة متنوعة من:

• ملفات Vanilla CSS
• SCSS
• JSS

حسب احتياجات وتفضيلات تلك الفرق.

يساعد تصدير أسماء الفئات إذا كنت تستخدم بعض نكهات CSS-in-JS ، ولكن ما هي الأفكار بالنسبة لأولئك الذين ليسوا كذلك؟

إعادة. 20٪ أداء ، أوافق على أنه من غير المحتمل أن تكون مقايضة مقبولة. في نهاية اليوم ، يجب أن تفعلوا ما هو الأفضل لغالبية المجتمع. مجرد عرض أفكاري 😄

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

mschipperheyn رد فعل الأصلي ليس هدفًا حتى الآن. إنها + 5٪ من إمكانية الاستخدام (شهر واحد من النمو) و + 50٪ جهد إضافي (تخمين). تكلفة الفرصة البديلة مرتفعة حقًا مع عدم وجود اتجاه واضح حول كيفية تسييلها (خارج نموذج Ionic). أيضًا ، ضع في اعتبارك أن الرفرفة يبدو أنها استحوذت على جزء كبير من الجمهور الذي يتفاعل مع الأهداف المحلية.

الآن بعد أن أصبح الإصدار 5 في إصدار ألفا ، هل هناك حل لهذه المشكلة؟ على وجه الخصوص ، هل لا يزال حل التصميم يعتمد على JSS؟ لقد رأينا مشكلات كبيرة في الأداء تتعلق بـ JSS ، لذلك كنا نتوقع بفارغ الصبر حلاً جديدًا.

zzzev هذه ليست مشكلة في حد ذاتها. إنه موضوع RFC (طلب التعليقات).

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

على أقل تقدير ، أفشل في الارتباط بكيفية الانتقال من JSS إلى Emotion (الذي يظهر في هذا الموضوع إلى احتمال حدوث بعض تدهور الأداء) من شأنه تحسين أي شيء.

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

عندما تقول إننا يجب أن نكتب الأنماط بطريقة مختلفة ، هل تقصد تجنب الأنماط الديناميكية؟ أو هل هناك أفضل الممارسات الأخرى التي يجب أن نفكر فيها؟

zzzev صحيح في الجزء الأول ، وليس في الجزء الثاني تمامًا (ما لم تحسب الانتقال من غير مدعوم إلى مدعوم باعتباره مكسبًا غير محدود في الأداء 🙂).

يتيح Emotion دعم الأنماط الديناميكية ، على حساب أداء أبطأ إلى حد ما للثابت.

انا مرتبك؛ ألا توجد أنماط ديناميكية في الطراز الحالي / v4 makeStyles؟ على سبيل المثال هذا النمط

انا مرتبك؛ ألا توجد أنماط ديناميكية في الطراز الحالي / v4 makeStyles؟ على سبيل المثال هذا النمط

هناك مشكلة كبيرة معروفة تتعلق بالأداء. يبقى فريقي بعيدًا عن أجهزة الصراف الآلي

أنا فقط أكره العناصر المكونة
jss جيد ولكن هناك بعض المشكلات في التصحيح والأداء وما زالت بعض الأخطاء لم يتم حلها مثل المتداخلة مثل &:after

إنها حزمتي التي يتم تجميعها من أجل تفاعل أصلي وتفاعل أصلي
https://www.npmjs.com/package/@material-native-ui/theme -provider

أحب شيئًا كهذا (إنه تراكم فوق RN و RNW)

إذن هل هناك استنتاج بشأن حل النمط الموصى باستخدامه مع Material UI v5؟ يبدو أن هناك نية للابتعاد عن JSS الذي يعتمد عليه حاليًا @material-ui/styles . أو سيتم إعادة هيكلة @material-ui/styles للاستفادة من حلول التصميم الأخرى مثل styled-components بدلاً من ذلك؟

إذن هل هناك استنتاج بشأن حل النمط الموصى باستخدامه مع Material UI v5؟ يبدو أن هناك نية للابتعاد عن JSS التي بنيت عليها @ material-ui / styles حاليًا. أو سيتم إعادة هيكلة @ material-ui / styles للبناء على حلول تصفيف أخرى مثل المكونات المصممة بدلاً من ذلك؟

@ matthewkwong2 لن نعتمد الحزمة @material-ui/styles للمحرك الجديد المصمم ، وسوف يستمر في دعم jss. في الإصدار الخامس ، سيتم عزله عن باقي قاعدة التعليمات البرمجية ونخطط لإزالته في الإصدار السادس ، بهدف المساعدة في الانتقال إلى محرك التصميم الجديد.

لV5، سيكون لدينا ممارسات جديدة ضربات بشأن حل التصميم، مثل sx دعامة و styled فائدة، ما زلنا العمل على وثائق حول هذا.

كما سيتم دعم تجاوزات السمات والمتغيرات في الإصدار الخامس.

بالنسبة إلى الإصدار 5 ، سيكون لدينا ممارسات إيقاعية جديدة فيما يتعلق بحل التصميم ، مثل دعامة sx والأداة المصممة ، ما زلنا نعمل على التوثيق حول هذا الأمر.
كما سيتم دعم تجاوزات السمات والمتغيرات في الإصدار الخامس.

لذا ، إذا فهمت بشكل صحيح ، لتصميم المكونات الفردية ، فمن الأفضل استخدام sx أو styled بدلاً من makeStyles .

ولكن ماذا عن السمة (أي createMuiTheme )؟ أعتقد أن هذا الجزء مبني أيضًا على JSS أليس كذلك؟ ما هي الطريقة الموصى بها لإنشاء سمة (أي بهدف رئيسي هو تحديد الأنماط العالمية) الآن؟

ما زلنا نحافظ على نفس الهيكل لإنشاء السمة ، نتوقع فقط أن القيم الخاصة بتجاوزات ومتغيرات المكونات تتبع بناء جملة مكونات العاطفة / الأنماط. لا توجد تغييرات في كيفية إنشاء السمة ، واجهة برمجة التطبيقات هي نفسها تمامًا ، كما يتم إعادة استخدام نفس سياق الموضوع للمحرك الجديد المصمم أيضًا. هل هذا منطقي @ matthewkwong2 ؟

mschipperheyn رد فعل الأصلي ليس هدفًا حتى الآن. إنها + 5٪ من إمكانية الاستخدام (شهر واحد من النمو) و + 50٪ جهد إضافي (تخمين). تكلفة الفرصة البديلة مرتفعة حقًا. أيضًا ، ضع في اعتبارك أن الرفرفة يبدو أنها استحوذت على جزء كبير من الجمهور الذي يتفاعل مع الأهداف المحلية.

لا أريد أن أأخذنا على قدر كبير جدًا من الظل ، لكني أرغب في صد بعض هذه الأسباب المنطقية.

• في الماضي ، عند إنشاء تطبيقات RN ، كان التصميم متعدد الأبعاد من أصعب الأمور للتعامل معها. في الواقع ، كانت مشكلة كبيرة بما يكفي ، فقد تقرر ما إذا كنت تريد إنشاء تطبيق جوال. سمعت أنه أفضل قليلاً مع وجود مكتبة جديدة واعدة. لكنني أشك في أنها واعدة كما لو كانت MUI في هذا المزيج. ربما أنا فقط ، لكن يمكنني رؤية MUI عبر الأنظمة الأساسية التي تزيد من استخدام RN. أعلم أنه ليس سوى جزء صغير من استخدام رد فعل دوم ، ولكن الويب ضخم ويهيمن رد الفعل نسبيًا ، فلا يزال من الممكن أن يكون عددًا معقولًا من الأشخاص كمطلق لاستخدامه. من المحتمل أن يكون استطلاع لمستخدمي MUI الحاليين مقياسًا أفضل من إحصائيات npm.
• أعلم أنني خارج الحلقة ، لكنني لا أشتري تمامًا Flutter لتولي React Native. مقارنة حركة المرور هذه ليست طريقة رائعة للمقارنة. يتأثر بالعديد من العوامل المربكة (Flutter أحدث لذا يعرف المزيد من الأشخاص بالفعل RN ولا يحتاجون إلى الرجوع إلى الوثائق ؛ قد يكون توثيق Flutter أكثر فائدة في إعادة الرجوع إلى زيادة حركة المرور الخاصة به ؛ قد تكون بعض زيارات قراءة المستندات الخاصة بـ RN إلى المعرض بدلاً من ذلك). هذه المقارنة المعيبة إلى حد ما في
• كانت JSS واحدة من أكبر المشكلات (في الواقع ربما تكون الأكبر) في جعل MUI يعمل مع React Native. أعلم أنه لا يزال هناك عدد قليل من العوامل المعقدة ، ولكن من المحتمل أن يكون التحول إلى العاطفة IMHO قد قضى على ثلثي الصعوبة في جعل MUI يعمل في RN على الأقل من الناحية التجريبية.

من المحتمل أن يكون التحول إلى العاطفة قد قضى على ثلثي الصعوبة في جعل MUI يعمل في RN

نحن نتطلع إلى رؤية POC 😄

نحن نتطلع إلى رؤية POC 😄

أحب أن ألعب بها إذا سنحت لي الفرصة. لكن الناس عمومًا لا يكلفون عناء صنع POCs للأشياء التي يُظهر المشرفون عليها عدم اهتمام. لا جدوى من بناء شيء ما عندما يكون الجو الحالي هو أنه من المحتمل أن ينتهي به الأمر مهجورًا. ولهذا السبب أريد الابتعاد عن رفض قيمة RN أو قيمة RN كاحتمال للمستقبل.

سؤالين:

1. هل يمكنك استخدام حل التصفيف الجديد بدون ترتيب ترتيب أفضل؟ أنا شخصياً أحب واجهة برمجة تطبيقات React hook التي تمتلكها MUI حاليًا ... لست متأكدًا مما إذا كانت البنية المصممة هي أيضًا HOC تحت غطاء المحرك ولكن هذا من شأنه التغلب على الجهود (إلى حد كبير في كل مكان في مكتبات React) في الابتعاد عن HOCs.
2. هل ستظل خاصية classes تدعم معظم المكونات (ستوفر مرونة كاملة في حل التصميم الذي يمكن للمستخدمين استخدامه)؟

يتم تمكين fast-refresh افتراضيًا في الإصدار 4 من تطبيق create-react-app . هل يجب أن نضيف دعم التحديث السريع كشرط جديد؟

جرب هذا مع غاتسبي. عندما أفعل 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 حصلت على:

لا يمكن حل "@ emotion / reaction" in "/ node_modules / @ emotion / style / dist"

ثم قمت بتثبيت @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 من حزم Emotion

أوه 11 هو الإصدار "الأحدث" الآن ، لذا أعتقد أن mui بحاجة إلى ترقية أو توثيق ذلك

أوه 11 هو الإصدار "الأحدث" الآن ، لذا أعتقد أن mui بحاجة إلى ترقية أو توثيق ذلك

لقد قمنا بتوثيقه عبر نطاقات الإصدارات في peerDependencies . لم نذكرها صراحةً في تعليمات التثبيت لأننا نخطط لتحديثها إلى الإصدار 11 قريبًا.

تذكير ودود بأن هذا هو ألفا وعاطفة 11 قبل أيام قليلة. كمتبني مبكر ، يجب أن تتوقع بعض الحواف الخشنة.

مرحبًا بالجميع ، أنا جديد هنا ، وكنت أبحث عن حلول المواد ذات واجهة المستخدم الخاصة بـ css وتناولت هذه المشكلة.
فقط أعطي 2 سنتي على هذا ، أود أن أقترح Linaria https://github.com/callstack/linaria.
إنها مكتبة وقت تشغيل صفري ، مع استخراج css ومتغيرات CSS كدعامات React.

آمل أن يساعد هذا في RFC 😄.