هل يمكننا التبديل إلى المكونات المصممة ؟
مقارنة عفا عليها الزمن
لديها العديد من المزايا ضد JSS
جدول المقارنة هنا ، والإصدار التالي سوف يتجنب إعادة تصيير أنماط SSR!
الميزات | مكونات على غرار | رد فعل jss
------------ | ------------- | -------------
لا توجد متطلبات بناء | ✅ | ✅
صغيرة وخفيفة الوزن | ✅ | ✅
يدعم CSS العالمية | ✅ | ✅
يدعم CSS | ✅ | ✅
مقلوب | ✅ | ✅
معزولة | ✅ | ✅
لا يكسر الأنماط المضمنة | ✅ | ✅
من السهل تجاوز | ✅ | ✅
تصميم | ✅ | ✅
عرض جانب الخادم | ✅ | ✅
لا توجد مكونات غلاف | ❌ | ✅
الدعم التفاعلي | ✅ | ❌
وسيلة إيضاح: ✅ = نعم ، ❌ = لا ، 😕 = Kinda ، أشر إلى الملاحظات أو الأقواس
kybarg شكرًا لفتح هذا العدد! يعد CSS-in-JSS مجالًا متحركًا ، وقد لا تكون الخيارات التي اتخذناها في الماضي صالحة مع تغير المشكلات والحلول.
لقد قمنا بمقارنة حل التصميم المختلف المتاح قبل اختيار JSS.
لم نختار المكونات المصممة للأسباب التالية:
<Grid />
: # 6010.في الواقع ، لم تكن المكونات المصممة حتى شيئًا (موجودًا) عندما بدأ nathanmarks العمل على الابتعاد عن النمط المضمّن.
يدعم CSS العالمية
باستخدام https://github.com/cssinjs/jss-global ، يمكنك كتابة أشياء مثل
const styles = {
'<strong i="35">@global</strong> body': {
color: 'green'
}
}
من السهل تجاوز
كيف هذا ليس سهلا؟ جانب مادة واجهة المستخدم لدينا جدول أوامر حقن محدد مسبقًا. على أرض المستخدم ، يمكنهم استخدام مثير للشهوة الجنسية التي تنفذ واجهة برمجة تطبيقات تجاوز أفروديت كبيرة.
لا توجد مكونات غلاف
ليس لدينا أي مكون غلاف على جانب Material-UI. كان من الممكن أن نستخدم withStyles
لكننا لا نستخدمه بسبب الأداء. نكشف عن هذا المكون ذي الترتيب الأعلى للمستخدمين لتلخيص تنفيذ السياق.
تصميم
نحن نستخدم مفاعل JSS-theme داخليًا. يعرض JSS واجهة برمجة تطبيقات ذات مستوى منخفض تجعل ذلك ممكنًا.
دعم تفاعلي
هذه نقطة جيدة ، واجهة برمجة تطبيقات التفاعل مع الأنماط مثيرة جدًا للاهتمام. هذا شيء يمكننا تحسينه!
للمضي قدمًا ، أعتقد أن المسار الواعد هو وجود واجهة برمجة تطبيقات تسمح بتبديل تنفيذ النمط. من شأن ذلك أن يجلب لنا فائدتان:
رد فعل الأدوات يتبع هذا المسار . قلقي الوحيد سيكون مع النفقات العامة التي تضيفها. أعني ، هل يستحق ذلك؟
أقوم بإضافة kof وmxstbr إلى الحلقة.
kybarg في الواقع ، لست متأكدًا من فهمي الكامل لما تقترحه.
نحن لا نستخدم react-jss
كما يوحي سؤالك.
عندما تقول نحن ، هل تتحدث عن المستخدمين أم واجهة المستخدم المادية؟
نقاطي هي:
styled-components
مكتبة ذات مستوى أعلى بكثير من JSS core ، يمكنك بالتأكيد استخدامها في طبقة التطبيق الخاص بك.هذا الجدول هو في الواقع شخصي للغاية ويعتمد على تجربتي الخاصة. يعمل FWIW ، styled-components
مع أي مكتبة مكونات تابعة لجهة خارجية:
import { Button } from 'material-ui'
const MyButton = styled(Button)`
// Only these styles will be overridden
background: red;
`
يعمل هذا طالما أن المكونات تربط الخاصية className
داخليًا ببعض عقدة DOM:
const MaterialUIButton = (props) => {
/* ... */
// As long as props.className is attached, the above usage will work
return <button className={`bla ${props.className}`} />
}
ما هو دعم رد الفعل الأصلي على أي حال؟ أليست مجرد مجموعة فرعية من منصة الويب؟
كلا ، ليس الأمر بهذه السهولة 😉 لا ينبغي أن تكون إضافة الدعم إلى JSS صعبة ، لأن كل ما عليك فعله هو تمرير كائن النمط إلى StyleSheet.create()
. يتطلب هذا مزيدًا من الجهد من جانب styled-components
لجعل سلاسل CSS تعمل.
لقد كنت أتحدث إلى javivelasco لفترة من الوقت الآن وأحب إلى أين يذهب مع react-toolbox
. إن تنفيذه مذهل ، وأود أن أرى جميع مكتبات مكونات الطرف الثالث تتبناه. أزعجه حتى يتمكن من التناغم مع أفكاره هنا!
لا يمكن تقديم التزامن من جانب الخادم. إنها تعتمد على مفردة لتجميع الأنماط بينما تقوم JSS بإنشاء مثيل جديد لتجميع الأنماط عند كل طلب. التبخير محدود حقًا.
غير مرتبط تمامًا ، هل تمانع في التعليق على هذه المشكلة بأفكارك لواجهة برمجة تطبيقات من شأنها أن تسمح بهذا الأمر؟ لم نقرر بعد ما سنفعله ، لذا فإن مساهمتك ستكون موضع تقدير كبير.
مرحبا ، لقد استفسرت عن هذا في gitter. فقط للحصول على آراء الآخرين ، سأقوم بنشرها هنا أيضًا:
أعرف أن material-ui _next_ مستثمرة بشكل كبير في حل jss مخصص.
هل اكتشف أي شخص أي ميزة جدية لاستخدام jss على المكونات المصممة؟
في حين أن jss جيد لأنه يتيح العديد من الأنماط مثل الزخارف (الحقن) والمكونات الإضافية ، أعتقد أن النهج المباشر للمكونات المصممة أكثر نظافة حيث لا توجد حاجة لمصممي الديكور والإعداد المخصص والمكونات الإضافية لأنها لا تحتاج إلى ذلك.
في التراكيب المصممة ، تم تصميم كل مكون بالفعل لذلك لا داعي لتمرير الأنماط. وتمرر الدعائم التي يمكن تقييمها لإنتاج نمط مختلف
لا يوجد إعداد (createJss)
لا إضافات (بادئة)
لا JSON DSL
يجب على شخص ما قفل هذا الموضوع.
لا يحتوي rainice jss على أدوات تزيين ، والمرتبط ذو الترتيب الأعلى هو أحد تفاصيل التنفيذ لـ response-jss ولا يتم استخدامه هنا.
لماذا يجب قفل هذا؟ إنها مناقشة عاقلة IMO
لأن المحتوى المستند إلى المستخدم النهائي هنا (وليس المشرفون على lib) سطحي للغاية وهذا مفهوم لأنهم لم يقرؤوا سطرًا واحدًا من التعليمات البرمجية وراء ما يستخدمونه.
نظرًا لأن اختيار حل التصميم قد تمت مناقشته مطولًا ، وتم توثيق السبب المنطقي وراء القرار ، واستمرار أعمال التطوير نحو الإصدار الرئيسي التالي ، فهذه ليست مشكلة مفيدة ، لذلك سأغلقها.
نأمل أن يكون الأشخاص ناضجين بدرجة كافية بحيث لا يستمرون في النشر في سلسلة رسائل مغلقة ، ولكن يمكننا قفلها إذا دعت الحاجة إلى ذلك.
أتمنى لو تمكنا من المضي قدمًا في هذا الخيط بحل تصفيف أقل اقترانًا!
ومع ذلك ، أعتقد أن أولويتنا ، في الوقت الحالي ، يجب أن تكون حول الانتهاء من الهجرة / التحسين الشامل للمكونات.
mxstbr شكرا للمكونات على غرار
يعمل هذا طالما أن المكونات تقوم بإرفاق خاصية className داخليًا ببعض عقدة DOM
قد يكون من المفيد تسليط الضوء في مكان ما في دليل الاستخدام الخاص بك عندما يتم إصدار mui: next . هذا التعليق أنقذني للتو.
لا تعمل الأنماط المرنة لـ IE10 مع jss ولكنها تعمل مع مكونات ذات طراز مثل السحر
yhaiovyi Material-UI لا تدعم IE10.
بادئة البائع evtl. سيتم إصلاحه قريبًا لـ jss ، لا يعني ذلك على الرغم من أنه سيصلح جميع المشكلات إذا لم يتم اختبار mui مطلقًا على IE10
على أي حال ، لم أجد أي مشاكل أخرى ، ثم css المرن مع IE10 حتى الآن
يبدو أن لدينا 3 طرق (يمكن أن تكون أسهل ، ولكن ليس كل شيء زهورًا) لتجاوز أنماط واجهة المستخدم المادية باستخدام المكونات المصممة. هنا هو جوهر بلدي.
يمكنك أيضًا الحصول على واجهة برمجة تطبيقات ذات مكونات على غرار مع بضعة أسطر من التعليمات البرمجية: https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-
يمكنك أيضًا استخدام style-jss أيضًا ، على سبيل المثال: https://codesandbox.io/s/32mvjyjyxq
الجانب السلبي الوحيد في JSS بشكل عام هو عدم وجود الإكمال التلقائي في محرري الكود ، كما هو مذكور هنا أيضًا ، ولكن الفوائد موجودة ، تحليل css إلى js كما هو الحال في المكونات المصممة هو حمل زائد قليلاً
تحرير: فقط لاحظت المشكلة المشار إليها أعلاه ، مثيرة للاهتمام
الأمر المزعج هو سياق Mui و withStyles
HOC لا يبدو أنه يلعب بشكل جيد مع رد فعل jss الأساسي و themeProvider على غرار jss https://codesandbox.io/s/32mvjyjyxq (حاولت وضع Typography
لكن هذا لا يعمل ، تحرير: nvm ، لا يزال يعبث به)
أتساءل عما إذا كان لاحقًا (المنشور v1 على ما أعتقد) لن يكون من المفيد تبسيط src/styles/withStyles
وطبقة مزدوجة MuiThemeProvider + JSSProvider ، ولديك شيء أكثر بساطة مثل كيفية تفاعل jss و style-jss
تماما لذلك!
في 13 مارس 2018 13:55 ، كتب "Cyril Auburtin" [email protected] :
ما هو مزعج هو سياق موي ومع أنماط HOC لا يبدو أنها تلعب
بشكل جيد مع رد فعل jss و ThemeProvider على غرار jss
https://codesandbox.io/s/32mvjyjyxqأتساءل عما إذا كان لاحقًا (بعد الإصدار 1 على ما أعتقد) لن يكون من المفيد التبسيط
src / styles / withStyles و MuiThemeProvider + JSSProvider طبقة مزدوجة-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.
يعد تحليل css إلى js كما هو الحال في المكونات المصممة أمرًا زائدًا بعض الشيء
تمامًا مثل تحليل الكائنات إلى CSS هو: wink: يتم تحليل السلاسل بنفس السرعة تقريبًا ، لا يهم بصراحة. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md
الحل | استخدم CSS | استخدم الأنماط المضمنة | وقت التحميل (مللي ثانية) | وقت العرض (مللي ثانية)
: --- | : --- | : --- | : --- | : -
...
مكونات على غرار | + | - | 182 | 146.84
مكونات منمقة فصل الخلية | + | - | 213.53 | 152.39
...
رد فعل jss | + | - | 198.97 | 297.74
mxstbr محلل css كامل مكتوب بلغة js في وقت التشغيل له سعر بالتأكيد. هذا المعيار لا يقيس تكلفتها.
محلل css الكامل المكتوب بلغة js وقت التشغيل له سعر بالتأكيد.
بالتأكيد ، ولكن ليس أكثر من محلل CSS كامل يتعامل مع الكائنات بدلاً من السلاسل. علاوة على ذلك ، تم تحسين محللات CSS التي تعمل على سلاسل CSS الفعلية واستكشافها لفترة طويلة ، ناهيك عن تلك التي تتعامل مع الكائنات. :احمر خدود:
سأكون فضوليًا بشأن تقييم bootstraps CSS ككائن باستخدام المحلل اللغوي الخاص بك مقابل bootstraps CSS باستخدام stylis ، المحلل اللغوي الخاص بنا ، لكنني متأكد تمامًا من أن الاختلاف سيكون ضئيلًا في أحسن الأحوال.
سأكون فضوليًا بشأن تقييم bootstraps CSS ككائن باستخدام المحلل اللغوي الخاص بك مقابل bootstraps CSS باستخدام stylis ، المحلل اللغوي الخاص بنا ، لكنني متأكد تمامًا من أن الاختلاف سيكون ضئيلًا في أحسن الأحوال.
نعم ، سيكون هذا معيارًا مناسبًا ، لقد اختبرت قليلاً ، والعمل مع الكائنات أسرع كثيرًا ، مثل 10-20x أسرع.
ولكن مرة أخرى ، يعتمد الأمر على مكونات jss الإضافية التي ستدرجها ، ولدينا الكثير من المكونات الإضافية النحوية للسكر.
أيضا tbh. لا يهم إذا انتقلنا جميعًا إلى ISTF.
لقد اختبرت قليلاً ، والعمل مع الكائنات أسرع كثيرًا ، مثل 10-20x أسرع.
بالتأكيد ، لكن 10 مللي ثانية (هذا هو الوقت الذي يستغرقه stylis لتحليل ورقة أنماط التمهيد بالكامل) مقابل 1 مللي ثانية لتحليل CSS بالكامل لتطبيق ما لن يكون مهمًا في المخطط الكبير للأشياء ، هل تعلم؟ لن يقوم بعمل أو كسر تطبيق أي شخص.
على أي حال ، دعنا نتوقف عن إزعاج الأشخاص في هذه المشكلة بإشعارات أكثر من اللازم.
بالمناسبة. يبدو أن هذا المعيار القياسي أكثر دقة: http://necolas.github.io/react-native-web/benchmarks/ لست متأكدًا من أنه لا يعتمد على ذاكرة تخزين مؤقت بعد التحليل الأول.
mxstbr بينما تم إغلاق هذه المشكلة الآن ، فإن القليل من المنافسة الصحية مفيد للجميع. ارجع في أي وقت - يمكنك أن تجدنا في الدردشة الجادة إذا لم تكن المشكلة هي المكان المناسب للمناقشة.
هذه القضية عمرها أكثر من عام. يا رفاق ، من فضلك توقف عن التعليق على ذلك. يمكننا نقل المناقشة إلى مناقشة جديدة. لقد تغير الكثير منذ بدء المناقشة.
لكن دعنا نحاول تجنب مشكلات الإغلاق. نحتاج إلى الاستمرار في جمع أكبر قدر ممكن من الملاحظات لاتخاذ قرارات أفضل.
أعتقد أن قفل المشكلة كأداة لإيصال ذلك بوضوح أمر جيد ، لم يسيء أحد من هذا ولم يتم الاستيلاء على حرية التعبير. في هذه الحالة إنه جيد حقًا.
أعيد فتح باب عملي لجمع المزيد من التعليقات ، ويساورني الفضول لمعرفة ما إذا كان هذا شيء لا يزال الناس مهتمين به:
لدينا مسح مطور قيد التشغيل وسنستخدم النتائج لتحديث ROADMAP.
لدينا المتطلبات التالية مع حل الأنماط:
classes
API ، وواجهة برمجة تطبيقات theme.overrides
والقدرة على الحصول على أسماء فئة حتمية عالمية.!important
ليس حلاً.لقد ذكرت فقط المكونات المصممة ، والعاطفة ، و JSS لكنها بدائل مختلفة: Linaria ، SASS ، إلخ.
أعتقد أنه قد يكون من المفيد إضافة المسألتين التاليتين لأنهما قد يساعدان في التأثير على القرار عندما يكون لديك الوقت للعمل على مكتبة CSS-in-JS التي تستخدمها Material-UI:
@ o-alexandrov هل تتبع JSS نفس الإستراتيجية التي تتبعها المكونات المصممة؟ أنا لا أفهم وجهة نظرك. هل يمكنك التوضيح؟ ماهو الفرق؟ كيف هو أفضل أو يستحق؟
تضمين التغريدة
في الرسالة السابقة ، لم أقل شيئًا عن styled-components
، باستثناء أنني أرحب بفكرة تقييم استخدام styled-components
أو أي مكتبة CSS-in-JS أخرى سيكون لها التوازن المثالي:
الروابط المؤدية إلى المسألتين أعلاه تناقش فقط الجانب السلبي الحالي للعمل مع JSS.
لقد نسيت أين رأيت ما يلي ، لكنني أتذكر أنك أوضحت نقطة جيدة وهي أن تكون قادرًا على اتخاذ القرارات ، يجب أن نضيف أولاً جميع أنواع المعايير حتى يمكن تقييم القرارات بشكل أسهل.
أنا شخصياً أحب:
@ o-alexandrov حسنًا ، في هذه الحالة ، أضع علامة على تعليقك الأول على أنه خارج الموضوع. في الإصدار الخامس ، نريد عزل المكونات الأساسية عن حل التصميم. أتمنى أن نتمكن من تقديم إصدارات عارية ، JSS ، وعاطفة ، وليناريا ، ومكونات نمطية (كإصدارات افتراضية) من المكونات. هذه هي الرؤية. الآن سيكون التنفيذ صعبًا!
حجم الحزمة
أثبت styled-components
أنه يتحسن 12.3kB
في الإصدار @ 5.0.0-beta.8
واجهة برمجة تطبيقات التخصيص
إذا قدموا https://github.com/styled-components/styled-components/pull/2625 سواء في الحزمة أو الحزمة الخارجية ، فأنا أعتقد أن تكافؤ واجهة برمجة التطبيقات لـ Mui لأنه يفتقر إلى واجهة برمجة تطبيقات لمكونات غير مصممة والتي قد نحتاجها في وقت ما ، خاصة في الأنظمة القديمة ولكن لا أعتقد أنك ستحتاج إلى واجهة برمجة التطبيقات هذه في Mui نفسها كثيرًا.
خارج ذلك ،
لست متأكدًا من المعلومات التي ترغب في جمعها نظرًا لأن تجربتي الشخصية توفر الميزات التي نحتاجها styled-components
خلال تجربتي الشخصية.
التوافقية.
ما هذا بالنسبة لك في هذا السياق؟ يمكنك تجاوز الأشياء في styled-components
مثل أي إطار عمل آخر على حد علمي.
دعم RTL
ألا يعتمد هذا على كيفية ترميز المكونات؟ ما الذي يجب أن تقدمه بالضبط مكتبة CSS-in-JS styled-components
أو أي مكتبة CSS-in-JS لهذا الغرض؟
لقد كان أبطأ مقارنة بالحلول الأخرى ولكن الدعم والجهد المذهل من المساهمين جعله أسرع من JSS.
أصبح v5
أكثر رشاقة كما قلت 12.3kB
من 16.2kB
والتي تمثل جهدهم في هذا الموضوع.
الناس على دراية بواجهة برمجة التطبيقات نظرًا لأنها الأكثر شيوعًا ، في الواقع ، يتصل معظم الناس بـ styled-components
في إشارة إلى واجهة برمجة التطبيقات بدلاً من الحزمة الفعلية عندما استخدمنا API styled(...) ...
للجزء الأكبر.
إنه وزن كبير بالنسبة إلى Mui هو الويب ، لكن الناس سيستمرون في تبني styled-components
بسبب ذلك.
فريق Strong Core ، اعتبارًا من اليوم 81 إصدارًا و 14 PRs مفتوحًا ، هذه أرقام جيدة بالنسبة لعدد الأشخاص الذين يستخدمون الحزمة.
أيضًا ، يستخدم أشخاص مثل mxstbr الحزمة في spectrum
لذلك لديه خبرة في العالم الحقيقي باستخدام الحزمة ، وهذا أمر مذهل ، وهذا يعني أنه يعرف بالفعل كيف يشعر باستخدام الحزمة.
حسنًا ، لا يمكن أن يكون أفضل https://www.styled-components.com/docs/tooling
اعتبارًا من اليوم ، ازداد اعتماد styled-components
لمكونات نظام التصميم كثيرًا ؛ Atlassian و GitHub و Orbit وغيرها الكثير.
هذا مفيد لموي لأنك لن تكون بمفردك ، لذا فمن المحتمل أن يتعامل الأشخاص بالفعل مع المواقف المحتملة التي قد تواجهها وقد توصلوا إلى كيفية التعامل معها.
أنا أدعم styled-components
.
أنا أحب JSS لأن بناء جملة الكائن لـ CSS أصبح أسهل بالنسبة لي ، وأحيانًا أكون كسولًا وأقوم بتمرير هذه الأنماط فقط مثل style={{styles.dialogTitle}}
أسلوب مضمّن ، من السهل إعادة بنائه لاحقًا
ويمكن استخدامه بطرق مختلفة ، مع غلاف عنصر مثل المكونات المصممة https://material-ui.com/styles/basics/#styled -components-api
caub https://www.styled-components.com/docs/advanced#style -objects
أنا حقًا أحب المكونات المصممة ، لكنني اكتشفت مؤخرًا أنها تقدم عددًا من المشكلات التي تجعل من الصعب جعل هز الشجرة يعمل باستمرار. أعلم أن فريق واجهة المستخدم المادية قد قام بالكثير من العمل للحصول على عمل اهتزاز الشجرة بشكل كامل لهذه المكتبة ، ومن الواضح أنه يجب تجنب أي تراجع في ذلك.
لحسن الحظ ، يتم حل معظم مشكلات اهتزاز الشجرة باستخدام مكونات babel-plugin-style وتعيين pure: true
(راجع https://www.styled-components.com/docs/tooling#dead-code-elimination ). ولكن لا تزال هناك بعض القضايا المتبقية. علي سبيل المثال:
https://github.com/styled-components/babel-plugin-styled-components/issues/245
آخر هو أن استخدام وظيفة مساعد خارجية داخل أنماطك يمكن أن يكسر اهتزاز الشجرة (ما لم تقم بتكوين terser / uglify لتجاهل هذه الوظيفة المحددة) ، على سبيل المثال:
const Button = styled.button`
font-size: ${externalHelperFunction()};
`
أعتقد أنه يجب أن يكون من الممكن إصلاح كل هذه المشكلات لجعل اهتزاز الشجرة يعمل بشكل صحيح ، ولكن من المؤكد أنه قد يكون خادعًا ولا يعمل فقط بطريقة مثالية خارج الصندوق كما هو الحال حاليًا. ما زلت أعتقد بالفعل أن التبديل إلى المكونات المصممة قد يكون فكرة جيدة ، ولكن فقط إذا كان من الممكن حل هذه المشكلات.
mbrowne لم أتمكن من إعادة إنتاج أي مشكلة مع اهتزاز الشجرة والمكونات المصممة. لا تتضمن المشكلة مثالاً قابلاً للتكرار ، لذا حاولت نسخه مع
// components.js
import React from "react";
import styled from "styled-components/macro";
const Wrapper = styled.div`
color: blue;
`;
export function MyComponent() {
return <Wrapper>styled</Wrapper>;
}
MyComponent.displayName = "FancyName";
export function OtherComponent() {
return "only";
}
// App.js
import React from 'react';
import { OtherComponent } from "./components";
/* code */
باستخدام create-react-app
افتراضيًا. لن يظهر MyComponent
في حزمة الإنتاج.
هل هذا شيء به مشكلات rollup
فقط؟ سأكون ممتنًا للحصول على مثال قابل لإعادة الإنتاج لفهم المشكلة.
@ eps1lon أعتقد أن المشكلة تظهر عند تعيين الخاصية الثابتة على المكون المصمم ، هل يمكنك تجربة ذلك؟
const Wrapper = styled.div`
color: blue;
`;
Wrapper.displayName = "FancyName";
export function MyComponent() {
return <Wrapper>styled</Wrapper>;
}
export function OtherComponent() {
return "only";
}
mxstbr نعم رغم أنه في كلتا الحالتين يتم تجميع المكونات المصممة. أثناء تعيين اسم العرض على MyComponent
لم يتضمن MyComponent
في الحزمة ، فإنه لا يزال يتضمن styled-components
. إنه يزيل بشكل أساسي أي شيء يتم إجراؤه على MyComponent
وهذا هو السبب في أنني اعتقدت في الأصل أنه يهز الشجرة بشكل صحيح (بحثت للتو عن FancyName
.
لكنها لا تزال تتضمن styled-components
. حتى لو كنت تفكر في أن مكالمة styled
لها آثار جانبية سأفكر فيها
import React from "react";
import styled from "styled-components";
export function Wrapper() {
// nonsense
return styled.div``;
}
export function MyComponent() {
return <Wrapper>styled</Wrapper>;
}
export function OtherComponent() {
return "only";
}
كخالية من التأثيرات الجانبية عند استيراد { OtherComponent }
لكن المكونات ذات الأنماط ستظل تظهر في الحزمة (حتى بدون الماكرو). لذا فإما أن يكون هذا خطأ أو أني أفتقد شيئًا كبيرًا. حتى في
// Wrapper.js
import React from "react";
import styled from "styled-components";
export default function Wrapper() {
// side-effect free module even if styled has side-effects
const Component = styled.div``;
return <Component />;
}
// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";
export function OtherComponent() {
return "only";
}
// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';
ReactDOM.render(<OtherComponent />, document.getElementById('root'));
// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();
سيشمل styled-components
(https://github.com/eps1lon/styled-components-shake).
قد يكون خطأ في البرامج النصية للتفاعل أو حزمة الويب أو المكونات المصممة. على أي حال ، يعد تصحيح هذه المشكلات أمرًا صعبًا للغاية بدون إعادة تعيين.
من المنطقي ، شكرا لك على التحقيق في ذلك.
بالنسبة لحالة الاستخدام هذه ، لا أعتقد أنه من المهم أن يتم تضمين styled-components
في الحزمة (حيث يجب أن تستخدمها جميع المكونات) ، ولكن بدلاً من ذلك ، ما إذا كانت المكونات التي لا تستخدمها مدرجة أم لا يبدو الأمر كذلك ، لذلك هذا جيد ، أليس كذلك؟
mxstbr قد يكون مصدر قلق مهم ، فلدينا مكونان غير منظمين وعامة (Modal و Popper و TextareaAutosize و useMediaQueries وما إلى ذلك) ، دعنا نقول أن أحدهم يستخدم
import { Modal } from '@material-ui/core';
مع SASS. نتوقع زيادة مقدارها +5 كيلو بايت gzip (اعتبارًا من اليوم) ، وليس + 20 كيلو بايت gzipped.
ومع ذلك ، بافتراض أننا دفعنا @material-ui/unstyled
للأمام ، من الناحية العملية ، فقد لا يحدث أي فرق حيث يمكن للأشخاص استخدام هذه الحزمة.
@ eps1lon معذرة ، اعتقدت أن مشكلة الخصائص الثابتة سيكون من الأسهل على الآخرين إعادة إنتاجها حيث يبدو أنها تؤثر على جميع مكوناتنا ... اتضح أن هناك الكثير من الأشياء المختلفة التي تسبب المشكلة ، ولكن على الأقل في بعض الحالات البسيطة يعمل.
لقد أنشأت عرضًا توضيحيًا قابلاً للتكرار هنا:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git
لاحظ كيف تهتز شجرة المكون 1 فقط بشكل صحيح.
النبأ السار هو أنني أعتقد أن جميع هذه المشكلات قابلة للحل ، ويبدو أن mxstbr مندمج للغاية هنا. سأعمل على العلاقات العامة قريبًا والتي ستعالج على الأقل مشكلة الدعائم الثابتة (لدي بالفعل POC عاملة باستخدام مكون Babel الإضافي المنفصل الذي كتبته).
لقد فتحت العلاقات العامة في مكونات على غرار المكون الإضافي babel لمعالجة مشكلات اهتزاز الشجرة. إذا أراد أي شخص هنا المساعدة في اختباره ، أتخيل أن mxstbr سيرحب بذلك (وأنا أيضًا بالطبع سأفعل):
https://github.com/styled-components/babel-plugin-styled-components/pull/248
مرحباً بالجميع ، أين هذه التذكرة حاليًا؟ سأكون أكثر من سعيد للمشاركة وكتابة بعض المكونات المصممة لـ MUI إذا كان هذا هو بالفعل الاتجاه الذي يتجه إليه المشروع في الإصدار الخامس
أعتقد ما لم نرغب في القيام بذلك دفعة واحدة (أشك في أننا نريد ذلك). يجب أن نبدأ إما بجعل المكونات المصممة تقرأ السمة من jss أو jss تقرأ السمة من المكونات المصممة. يجب أن يكون الهدف هو أنه يمكننا ترحيل الأنماط على أساس كل مكون.
من المحتمل أن يحدث هذا في فرع آخر. على الرغم من أننا لا نريد تغيير كل شيء على المستوى الرئيسي دفعة واحدة ، فمن المحتمل أن نصدره بتغيير واحد (في الإصدار 5). وإلا فإن هذا يصبح أكثر إرباكًا.
تم طلب حذف التعليق.
مرحبًا يا رفاق ، أنا مستعد للمساهمة أيضًا ... يبدو أن إنشاء فرع منفصل أمر منطقي بالنسبة لنا للقيام به ... لنفعل هذا ...!
@ caprica-Six شكرًا على الطاقة ولكن ليس من الضروري إنشاء فرع جديد. يجب أن نكون قادرين على توفير نسخة مكونة من نمط تدريجيًا (+ jss and emotion) (غير مستقر أثناء الإصدار 4) ، ونقل القصة غير المنظمة إلى الأمام في نفس الوقت. لديّ مستند إثبات رأي أحتاج إلى تقديمه. المكونات الأنماط (الإصدار 5 بيتا) + الدعائم الديناميكية تكون أبطأ قليلاً مما لدينا مع JSS والأنماط الثابتة ، ولكن هذا لا يزال مقبولاً.
oliviertassinari هل هناك مكان ما يمكننا المشاركة فيه؟ كنت أنتظر نوعًا ما من المشرف ليوجهني في الاتجاه الصحيح قبل القفز إلى أي شيء
لماذا لا تفضل العاطفة على المكونات المصممة؟ يبدو أن السبب هو أن "[المشاعر] يستخدمها عدد قليل من الناس. إذا ألقيت نظرة على إحصائيات التنزيل ، فإن 80٪ يأتي من القصص القصيرة؟" ، لكن هذا خطأ. إنها مستخدمة أكثر من المكونات المصممة ( المقارنة ) ولا أرى لماذا 80٪ من التنزيلات تأتي من القصص القصيرة. من الواضح أنها تنمو بشكل أسرع بكثير من القصص القصيرة.
أطرح هذا السؤال لأنني سئمت استخدام المكونات المصممة (بسبب العديد من المشكلات التي كنت أواجهها) وبحثت عن بديل ، واكتشفت Emotion. لقد اختبرت ذلك ووجدت مزايا فقط مقارنة بالمكونات المصممة.
إنه أخف وأسرع وله وظائف أكثر: إعادة توجيه الملكية ، TypeScript خارج الصندوق (ومدعوم بشكل مثالي مقارنة بالمكونات المصممة) ، Next.js SSR خارج الصندوق (دون الحاجة إلى الكتابة فوق التطبيق. js و _document.js ، ما استغرق مني ساعة واحدة للتعامل معه لأول مرة)
علاوة على ذلك ، فهو أكثر استخدامًا من المكونات المصممة وله قوة دفع واضحة.
lcswillems أعتقد أنه يجب علينا أيضًا دعم المشاعر للأشخاص الذين يفضلونها. لكنني لا أعتقد أنه ينبغي أن يكون الوضع الافتراضي.
شكرا لك على إجابتك وتصحيحك لي.
المشكلة الرئيسية التي أواجهها هي إعادة التوجيه / التصفية: https://github.com/styled-components/styled-components/issues/439 . يحدث هذا كثيرًا بالنسبة لي ، ويؤلمني إجراء التصفية يدويًا في كل مرة.
لكن مع ملاحظاتك ، يبدو أن العاطفة ليست بديلاً جيدًا.
"أخف": غير دقيق: https://bundlephobia.com/result؟[email protected] (12.2 كيلوبايت) مقابل https://bundlephobia.com/result؟p=@emotion/ على غرار + https://bundlephobia.com/result؟p=@emotion/core + https://bundlephobia.com/result؟p=emotion-theming (13.1 كيلوبايت دون أخذ
في حالة استخدام Emotion ، على الأرجح لن تستخدم حزمة @emotion/styled
لصالح css
props + @jsx
pragma. قد لا تحتاج أيضًا إلى حزمة emotion-theming
، فقد تم تضمين ThemeContext
بالفعل في @emotion/core
. إذن فهي 12.2 كيلو بايت مقابل 6.5 كيلو بايت.
مضمنة
مجرد فضول: ماذا تعني هذه التحديثات لمستخدمي مكتبة @material-ui/styles
للمكونات بخلاف MUI؟ في شركتي ، نستخدمها كأساس لمكتبة مكونة داخلية كبيرة ، بعد أن اخترتها عمدًا أكثر من styled-components
، ونحن سعداء جدًا بها.
فكرت فقط في أنني سأقوم بتسجيل الوصول في وقت مبكر إذا كان هناك أي نوع من الإهمال المخطط له لحزمة @material-ui/styles
، حتى أتمكن من التخطيط وفقًا لذلك.
على أي حال ، شكرًا على كل الأشياء الرائعة التي تواصل تقديمها جميعًا!
@ nickjohnson-dev يجب أن يكون الترحيل إلى رد فعل jss مباشرًا. هل هذا يعمل لمؤسستك؟
oliviertassinari أعتقد أنه من المحتمل أن يكون كذلك. طالما أنه يمكننا الاحتفاظ بواجهة برمجة التطبيقات العامة للمكونات نفسها في الغالب (تجاوزات محلية قائمة على الدعامة classes
، يمكن تجاوزات عالمية في السمة) ، لا أعتقد أن تغيير تفاصيل التنفيذ يمثل مشكلة.
هل تتوقع وجود أي وثائق رسمية للانتقال من @material-ui/styles
إلى خيارات التصميم الأخرى بعد انفصال MUI بشكل أكبر؟ للوهلة الأولى ، لا أرى أي ميزات تفتقر إلى react-jss
التي نستفيد منها في @material-ui/styles
، لكنني لست متأكدًا مما إذا كنت أفتقد أي شيء خاص تفعله حزمة MUI خلف الكواليس.
@ nickjohnson-dev سنبذل قصارى جهدنا.
إذا فهمت بشكل صحيح ستحدث المشكلة التالية.
لدينا ComponentA
القابل لإعادة الاستخدام. نصنع ComponentB
الذي يستخدم ComponentA
.
const ComponentA = ({className}) => (
<div className={className}>
<div className='inner' />
</div>
);
const ComponentB = ({ className, classNameInner }) => (
<div className={className}>
<div className='inner'>
<ComponentA className={classNameInner} />
</div>
</div>
)
const StyledComponentB = styled(ComponentB)`
???
`;
لاحظ كيف أن كلا من ComponentA
و ComponentB
يحتويان على العنصر بنفس className='inner'
. كيف نستهدف العنصر .inner
على ComponentB
فقط؟
مرحبًا oliviertassinari ، شكرًا لك على مشاركة كل الأفكار وراء التصميم للإصدار التالي من واجهة المستخدم المادية.
وشكرًا لك أيضًا على واجهة المستخدم المادية. الآن أقوم ببناء نظام تصميم فوقه.
فيما يتعلق بتبني styled-components
، يبدو أنه قرار تم اتخاذه ، والعمل على تحقيق هذا الهدف بدأ بالفعل.
ومع ذلك ، أشارك بعض الملاحظات التي قدمها croraf و lcswillems
شيء رائع من نمط واجهة المستخدم المادية الحالي هو خاصية classes
.
إنها فكرة بسيطة تساعد كثيرًا في تخصيص النمط وقابلية الصيانة لأن كتابة classes
جزء من الواجهة العامة. على سبيل المثال ، إذا كنت بحاجة إلى تخصيص شيء ما واستخدمت محددًا مثل & .Component-root
فلا شيء يضمن أن Component
سيحتفظ بفئة css عبر الإصدارات. من خلال الحصول <Component classes={{root: ....}} />
على الأقل يمكنني الحصول على خطأ التحقق من النوع (في حالة استخدام TypeScript) حول تغيير الواجهة.
بصفتي مؤلفًا مكونًا ، يمكنني أن أقرر توثيق الفئات العامة (والمدعومة) وترك الآخرين بدون وثائق.
لقد استخدمت style-components
لمدة عامين تقريبًا. صحيح أنه شائع وتطور كثيرًا. ولكن ، في أمثلة وثائق MUI ، أرى نفس المشكلة التي يذكرها croad : استخدام المحدد التابع & .inner
هش للغاية لأنه يمكنك نشر الأنماط إلى المكونات الفرعية (ومن تجربتي الخاصة يمكنني القول هذه ليست قضية زاوية ... لقد حدث لي عدة مرات). هناك حلان محتملان هما:
&.inner
ثم استخدم ${props.className}.inner
في كل مكان. لقد فعلت ذلك عدة مرات ، ومن المؤلم أن أكتب.> .inner
ولكن بعد ذلك يعتمد ذلك على بنية المكون. أضف بعضًا إضافيًا من div
في المنتصف وسيتكسر.صحيح أن JSS لا تحظى بشعبية. أتعلم عنها بسبب MUI. ولكن بعد العمل لفترة طويلة مع styled-components
، وجدت نهج أنماط MUI منعشًا وأسهل في العمل معه (بعد فترة من الوقت ، يضيف وجود Styled HOC في كل مكان الكثير من العمل الإضافي وبدأت أكره هؤلاء المراكز ... على الأقل هذه هي تجربتي الشخصية). تتطابق العاطفة بشكل أو بآخر مع النهج الحالي. وبعد قراءة تعليقاتك وبعض المشكلات المتعلقة بأداء JSS في حالات معينة ، أقوم بتقييم استخدام Emotion لنظام التصميم.
ومع ذلك ، أرى أنك مقتنع جدًا بشأن styled-components
لدرجة أنني سأحب أن أرى المزيد من الأمثلة حول كيفية حل تخصيص النمط باستخدام الدعائم classes
. تلك المتوفرة في مستندات MUI الحالية تشترك في المشكلات التي ذكرتها أعلاه.
هل هناك طرق أخرى لاستخدام styled-components
مع خاصية الفئات؟ ما هي أفكارك حول هذا الموضوع؟
JSS جيد بما يكفي وسهل الاستخدام. هل هناك سبب قوي للابتعاد؟
أنا شخصياً أعتقد أن المكون المصمم هو نوع من خطوة إلى الوراء وكان JSS هو السبب الرئيسي لبدء استخدام هذه المكتبة لأكون صادقًا.
powerfulj لماذا تفضل JSS على مكوّنات الأنماط؟ كان علي أن أختار بين المكونين ويبدو أن المكونات المصممة أفضل بالنسبة لي.
تضمين التغريدة
يعجبني لأنني أعتقد أنه لا يقدم مكونًا جديدًا ، وبدلاً من ذلك ، فأنت تعمل فقط على الخصائص. إذا كنت حقًا بحاجة إلى مكون جديد قابل لإعادة الاستخدام تم تصميمه ، فيمكنك إنشاؤه بسهولة باستخدام حل JSS.
كما أنه من الأسرع التحويل من النمط المضمن إلى نمط JSS ، وهو أمر مناسب لي لأنني عادةً ما أستخدم الأنماط المضمنة أثناء التنفيذ ثم تحويله إلى JSS إذا أصبح أكبر حجمًا وأعيد استخدامه.
الجانب السلبي هو أنه إذا كان لديك بعض CSS (مثل من أدوات تطوير المتصفح) وتحتاج إلى تحويلها إلى JSS ، فعليك قضاء بعض الوقت في ضبط بناء الجملة. مع المكون المصمم هذا يسير بشكل أسرع.
فقط لمشاركة ما توصلت إليه بشأن هذه القضية.
حاولت ترحيل بعض العروض التوضيحية إلى المكونات المصممة على النحو المطلوب في # 16947. المشكلة مع الموضوع الافتراضي. يقبل makeStyles
الخيارات حيث يمكن تمرير الموضوع الافتراضي. هناك غلاف makeStyles
سيوفر defaultTheme
. ثم useStyles
سوف يتحقق الخطاف مما إذا كان ThemeProvider
يوفر السمة ، وإذا لم يكن الأمر كذلك ، فقم بحقن defaultTheme
.
يبدو أنه لا توجد مثل هذه الوظيفة في المكونات المصممة. في حالة عدم وجود ThemeProvider
default لا يمكن حقن الموضوع إلا بطريقة .attrs
. قد نقوم بإنشاء شيء مشابه للغلاف makeStyles
import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';
const styled = Component => {
return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};
export default styled;
لكن طريقة .attrs
ستحل محل المظهر الذي يوفره ThemeProvider
إن وجد. وأنا لا أعرف حاليًا كيفية حل هذه المشكلة.
مشكلة أخرى هي أن makeStyles
يستخدم الإعداد المسبق للوحدة الافتراضية لـ jss-plugin ويبدو أن المكونات المصممة ليست كذلك. لذا فإن المكونات المصممة لا تضيف قيمة عائد px
للوظيفة spacing()
.
الحل المحتمل للمشكلة الأخيرة هو استخدام Styled-JSS وليس المكونات المصممة.
أنا سعيد هنا بأفكارك / اقتراحاتك.
تعمل @ fyodore82 .attrs
كوظيفة (راجع https://www.styled-components.com/docs/api#attrs) ، لذلك سيفعل ذلك:
شبيبة
.attrs (({theme = defaultTheme، ... props}) => ({... props، theme}))
""
تضمين التغريدة
يعجبني لأنني أعتقد أنه لا يقدم مكونًا جديدًا ، وبدلاً من ذلك ، فأنت تعمل فقط على الخصائص
أعتقد أنك فاتتك شيئًا رائعًا حقًا من المكونات المصممة: دعامة css
. يسمح لك بإضافة CSS إلى أحد المكونات دون الحاجة إلى إنشاء مكون جديد.
كما أنه من الأسرع التحويل من النمط المضمن إلى نمط JSS ، وهو أمر مناسب لي لأنني عادةً ما أستخدم الأنماط المضمنة أثناء التنفيذ ثم تحويله إلى JSS إذا أصبح أكبر حجمًا وأعيد استخدامه.
باستخدام خاصية CSS ، لاحظ أن المكون الذي يحتوي على خاصية CSS لا يحتوي على سمة style
، فقد تم تحويله بالفعل إلى مكون ذي نمط وبالتالي يحتوي على class
. إذا زاد حجم CSS وأعيد استخدامه ، يمكنك أيضًا إنشاء مكون جديد.
الجانب السلبي هو أنه إذا كان لديك بعض CSS (مثل من أدوات تطوير المتصفح) وتحتاج إلى تحويلها إلى JSS ، فعليك قضاء بعض الوقت في ضبط بناء الجملة. مع المكون المصمم هذا يسير بشكل أسرع.
أنا موافق. هذا هو السبب الرئيسي لعدم استخدامه. تتم كتابة معظم CSS المكتوبة على الإنترنت بلغة CSS ، وليس بلغة JSS. لذلك إذا كنت تريد استخدام بعض التعليمات البرمجية من StackOverflow ، فأنت بحاجة إلى تحويلها أولاً إلى JSS ، وهو أمر مؤلم للغاية.
الحجج الإضافية الأخرى التي جعلتني أستخدم المكونات ذات الأنماط:
إصدار JSS:
import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';
const useStyles = makeStyles(theme => ({
card: {
display: 'flex',
},
details: {
display: 'flex',
flexDirection: 'column',
},
content: {
flex: '1 0 auto',
},
cover: {
width: 151,
},
controls: {
display: 'flex',
alignItems: 'center',
paddingLeft: theme.spacing(1),
paddingBottom: theme.spacing(1),
},
playIcon: {
height: 38,
width: 38,
},
}));
export default function MediaControlCard() {
const classes = useStyles();
const theme = useTheme();
return (
<Card className={classes.card}>
<div className={classes.details}>
<CardContent className={classes.content}>
<Typography component="h5" variant="h5">
Live From Space
</Typography>
<Typography variant="subtitle1" color="textSecondary">
Mac Miller
</Typography>
</CardContent>
<div className={classes.controls}>
<IconButton aria-label="previous">
{theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
</IconButton>
<IconButton aria-label="play/pause">
<PlayArrowIcon className={classes.playIcon} />
</IconButton>
<IconButton aria-label="next">
{theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
</IconButton>
</div>
</div>
<CardMedia
className={classes.cover}
image="/static/images/cards/live-from-space.jpg"
title="Live from space album cover"
/>
</Card>
);
}
إصدار المكونات الأنماط:
import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';
export default function MediaControlCard() {
const theme = useTheme();
return (
<Card>
<Details>
<CardContent>
<Typography component="h5" variant="h5">
Live From Space
</Typography>
<Typography variant="subtitle1" color="textSecondary">
Mac Miller
</Typography>
</CardContent>
<Controls>
<IconButton aria-label="previous">
{theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
</IconButton>
<IconButton aria-label="play/pause">
<PlayArrowIcon />
</IconButton>
<IconButton aria-label="next">
{theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
</IconButton>
</Controls>
</Details>
<CardMedia
image="/static/images/cards/live-from-space.jpg"
title="Live from space album cover"
/>
</Card>
);
}
const Card = styled(MuiCard)`
display: flex;
`
const Details = styled.div`
display: flex;
flex-direction: column;
`
const CardContent = styled(MuiCardContent)`
flex: 1 0 auto;
`
const CardMedia = styled(MuiCardMedia)`
width: 151px;
`
const Controls = styled.div`
display: flex;
align-items: center;
padding-left: ${props => props.theme.spacing(1)}px;
padding-bottom: ${props => props.theme.spacing(1)}px;
`
const PlayArrowIcon = styled(MuiPlayArrowIcon)`
height: 38px;
width: 38px;
`
أخيرًا ، لم أجد أي ميزة لاستخدام JSS.
خاصية css لطيفة للغاية ، وهي تحل بشكل أساسي الجوانب السلبية التي ذكرتها. (المقلدة من مكونات نمطية: D)
فيما يتعلق بالمقارنة بين المثالين ، لا أجدها سهلة القراءة وتضاعف عدد المكونات.
تضمين التغريدة
لا تجادل في حل واحد أو آخر ، فقط اختر نقطتين من نقاطك:
إذا كنت تريد استخدام بعض التعليمات البرمجية من StackOverflow ، فأنت بحاجة إلى تحويلها أولاً إلى JSS ، وهو أمر مؤلم للغاية
يوجد امتداد VSCode لتحويل CSS إلى CSS-in-JS ، على الرغم من أنه لا يعمل دائمًا بشكل مثالي. بغض النظر ، لن أسميها مؤلمة.
ليس لديك تمييز لغوي
أنا لا أفهم هذه الحجة تمامًا. إنه مجرد كائن JS ، لذلك يعمل تمييز بناء جملة أي محرر:
(لكن ربما تبحث عن شيء أكثر تحديدًا؟)
فيما يتعلق بالمقارنة بين المثالين ، لا أجدها أكثر قابلية للقراءة. في حين أن الافتقار إلى دعائم className أكثر نظافة ، إلا أنه ليس من الواضح من كتلة كود JSX الرئيسية ما إذا كانت المكونات تشير إلى مكونات MUI الأصلية ، أو المكونات المعاد تصميمها دون الحاجة إلى الرجوع إلى مكونات styled()
. في مكون أكبر يمكن إزالتها بعيدًا.
استدعاءات styled()
(بالنسبة لي) أقل قابلية للقراءة من كائن JSS (على الرغم من أنني أتصور أنك تعتاد عليها).
powerfulj لماذا تفضل JSS على مكوّنات الأنماط؟ كان علي أن أختار بين المكونين ويبدو أن المكونات المصممة أفضل بالنسبة لي.
لأنني مطور إنشائي بنفسي وأنا أفضل بناء كل شيء في كائن Typescript. خاصة أنني أكره الأوتار.
على الرغم من أننا نحتاج إلى نقل كود CSS إلى كود JSS بسبب الاختلاف ، إلا أنني ما زلت أفضل قراءة كود JSS لأن الهيكل يشبه CSS التقليدي (موجه للفئة) ، إلا أنني سأقضي المزيد من الوقت في قراءة كود المكون المصمم لأنه أطول ويمكن أن تكون هنا وهناك.
أعتقد أن الناس ادعوا هذا التغيير فقط لأن لديهم خبرة في مكون النمط في الماضي. إنه يعطيني الشعور مثل "لماذا لا نختار مكتبة مألوفة لنا ولكن ليس لها فائدة واضحة؟".
من وجهة نظري ، يبدو أن JSS سهل الاستخدام ، يمكننا تنظيم الكائن باستخدام جميع طرق جافا سكريبت مثل
{
... مشاركة JSS1،
... مشاركة JSS2،
ما من أي وقت مضى
}
لدينا أيضًا سمات ديناميكية سلسة متكاملة مع الأنواع وحصلنا على جميع تلميحات الكتابة من كلا النوعين className و css.
للمطورين الجدد ، خاصةً مطورو Typescript ، فإنهم ببساطة يحبون JSS.
لمعلوماتك ، من الممكن إجراء بعض التداخل في المكونات المصممة إذا كنت لا تريد دائمًا مكونًا منفصلاً لكل شيء. إنه غير محبذ بشكل عام ، نظرًا لأن استخدام مكونات منفصلة بأسماء ذات مغزى يعتبر أكثر وضوحًا وقابلية للقراءة وفقًا لفلسفة المكونات المصممة ، لكن المستندات تقول إنه جيد إذا "تم استخدامها بشكل مقتصد". وبالطبع ، بالنسبة لأي شخص لا يشارك هذه الفلسفة ، فإنهم أحرار في فعل المزيد من التعشيش. كمثال على ما أعنيه بالتداخل:
const Wrapper = styled.div`
display: block;
.inner {
flex: 1;
}
`
...
<Wrapper>
<div class="inner">...</div>
</Wrapper>
راجع https://www.styled-components.com/docs/faqs#can -i-nest-rules لمزيد من التفاصيل.
يمكن أن تستمر المناقشات حول تفضيلات أسلوب الترميز إلى الأبد.
بعد استخدام styled-components
لفترة من الوقت ، أحب أسلوب JSS أكثر ، للأسباب التالية:
styled-components
أيضًا ، ووجدت أن useStyles
/ makeStyles
أسهل في الكتابة والقراءة والصيانة. على سبيل المثال. import useStyles from './MyComp.styles'
مقابل import {XStyled, YStyled,...} from './MyComp.styles'
... الحفاظ على تلك الأشكال ...Styled
مع كتاباتها في TS أمر مزعج.styled-components
أفعل ذلك باستخدام الفئات الداخلية (كما في المثال منmbrowne) ، لكنه يتطلب المزيد من أعمال إعادة البناء. لقد وجدت أن نهج useStyles
أكثر راحة للعمل مع سير العمل هذا.لكن هذه هي تفضيلاتي الشخصية ، قد تكون تفضيلاتك مختلفة.
أكبر سؤالي مفتوح حول التغيير هو استخدام classes
.
أمثلة استخدام className
والفصول الداخلية بها مشاكل (انظر تعليقي السابق). الخاصية css
في styled-components
ليست خيارًا لحل هذه المشكلات. على عكس الدالة css
في Emotion ، تعتمد الخاصية css
على الارتباط بمكوِّن (مما يعني أنه لا يمكنك استخدامها في نمط الكود useStyle/makeStyles/classes
).
لا يعد إرفاق الأنماط بمكون قرار تصميم بسيطًا. بالنسبة لي ، هذا هو الخير والشر في JSS. تعتمد المكونات ذات الأنماط والعاطفة على مكونات Babel الإضافية وتتفاعل مع React للتعامل مع التخزين المؤقت وتوليد اسم الفئة لـ SSR. الجزء الجيد من JSS ، هو أنه لا يحتاج إلى أي مكون إضافي من Babel. الجزء السيئ هو أن SSR في JSS يتطلب المزيد من العمل ، وقد رأيت أخطاء تم الإبلاغ عنها في هذا المجال.
بالعودة إلى MUI ، لدي انطباع بأن اعتماد مكونات النمط يعني استخدام className
والفئات الداخلية باعتبارها الطريقة الوحيدة لتخصيص الأنماط. يصبح التصميم أكثر اتساقًا عبر الأطر: يمكنك استخدام styled
أو css
prop ، طالما أن المكون يستخدم className
أنت جيد.
لكن بالنسبة لي فإن إزالة الخاصية classes
هي خطوة إلى الوراء. تساعد هذه الخاصية في توثيق وكتابة تخصيصات نمط التحقق. ربما من الممكن العثور على حل وسط ، مثل استخدام المكونات المصممة مع الاحتفاظ بالدعم مقابل classes
(دون الحاجة إلى اختراق الطبقة الداخلية). لم أتمكن من العثور على أي شيء في واجهة برمجة التطبيقات للمكونات المصممة يساعد في هذه الحالة. لهذا السبب قد يكون من الجيد تقييم المشاكل التقنية لـ JSS. لأنه إذا كانت الشعبية هي القضية الرئيسية ، فقد أصبحت العاطفة شائعة أيضًا (انظر https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview) ، وقد يكون ذلك سهلاً كطريقة أعد كتابة makeStyles
.
@ dfernandez-asapp ، لقد قدمت بعض النقاط الممتازة فقط بالرد على جزء صغير من هذه المكونات fwiw @ styleled تدعم استخدام كائن مشابه لـ jss بدلاً من سلسلة https://www.styled-components.com/docs/advanced# أسلوب الكائنات
على الرغم من أنه أمر مخيب للآمال إلى حد كبير ، إلا أن المكونات المصممة قد أزلت دعم الكتابة المطبوعة من الدرجة الأولى وأتفق معك بشكل عام على أنه يبدو وكأنه خطوة إلى الوراء بالطرق الأخرى التي وصفتها
لمعلوماتك ، من الممكن إجراء بعض التداخل في المكونات المصممة إذا كنت لا تريد دائمًا مكونًا منفصلاً لكل شيء. إنه غير محبذ بشكل عام ، نظرًا لأن استخدام مكونات منفصلة بأسماء ذات مغزى يعتبر أكثر وضوحًا وقابلية للقراءة وفقًا لفلسفة المكونات المصممة ، لكن المستندات تقول إنه جيد إذا "تم استخدامها بشكل مقتصد". وبالطبع ، بالنسبة لأي شخص لا يشارك هذه الفلسفة ، فإنهم أحرار في فعل المزيد من التعشيش. كمثال على ما أعنيه بالتداخل:
const Wrapper = styled.div` display: block; .inner { flex: 1; } ` ... <Wrapper> <div class="inner">...</div> </Wrapper>
راجع https://www.styled-components.com/docs/faqs#can -i-nest-rules لمزيد من التفاصيل.
أي نوع الدعم لهذا؟ أو علينا وضع الخيط في كل مكان؟
لا أفهم سبب وجود الكثير من الضجيج للمكونات المصممة. يبدو الأمر وكأنه خطوة إلى الوراء لنكون صادقين. تعد خصائص CSS المكتوبة لـ JSS مع TypeScript أكثر ملاءمة وأسهل في الصيانة ، بالإضافة إلى التحقق من بناء الجملة كجزء من JS - سيخبرك أي محرر حديث / تم تكوينه إذا قمت بأي خطأ إملائي ويساعدك في الإكمال التلقائي إذا كان ذلك مطلوبًا.
تحرير: يتم كتابته ، انظر رد South-Paw أدناه.
martinjlowm يبدو أنه يحتوي على كتابات لي؟
انظر: https://styled-components.com/docs/advanced#style -objects
أنت تقول إنك لا تفهم الضجيج ... لكنني لا أفهم كل الكراهية التي تحصل عليها أيضًا. 🤷♂
العاطفة والمكونات المصممة هي تحسينات كبيرة على كائنات نمط CSS IMO
martinjlowm يبدو أنه يحتوي على كتابات لي؟
...
انظر: https://styled-components.com/docs/advanced#style -objects
أنت تقول إنك لا تفهم الضجيج ... لكنني لا أفهم كل الكراهية التي تحصل عليها أيضًا. 🤷♂
العاطفة والمكونات المصممة هي تحسينات كبيرة على كائنات نمط CSS IMO
فهمت! لم أكن أعلم أنه يدعم كائنات من هذا القبيل. كان قلقي مرتبطًا بـ CSS في سلاسل القوالب - ولكن إذا كانت الكائنات خيارًا ، فليس لدي أي شيء ضدها!
من الواضح أن JSS ليس مثاليًا أيضًا ، أعلم أن الأوراق التي يتم إنشاؤها بواسطة الخادم القابل لإعادة الاستخدام ستكون ميزة قاتلة - هل تدعم المكونات المصممة ذلك بطريقة ما؟ هل يعلم أحد؟
في الوقت الحالي ، يبدو من الغباء أن تضطر إلى حذف أوراق الأنماط التي تم إنشاؤها بواسطة الخادم وإجبار العميل على إعادة عرض جميع الأنماط :(
martinjlowm يبدو أنه يحتوي على كتابات لي؟
...
انظر: https://styled-components.com/docs/advanced#style -objects
أنت تقول إنك لا تفهم الضجيج ... لكنني لا أفهم كل الكراهية التي تحصل عليها أيضًا. 🤷♂
العاطفة والمكونات المصممة هي تحسينات كبيرة على كائنات نمط CSS IMOفهمت! لم أكن أعلم أنه يدعم كائنات من هذا القبيل. كان قلقي مرتبطًا بـ CSS في سلاسل القوالب - ولكن إذا كانت الكائنات خيارًا ، فليس لدي أي شيء ضدها!
من الواضح أن JSS ليس مثاليًا أيضًا ، أعلم أن الأوراق التي يتم إنشاؤها بواسطة الخادم القابل لإعادة الاستخدام ستكون ميزة قاتلة - هل تدعم المكونات المصممة ذلك بطريقة ما؟ هل يعلم أحد؟
في الوقت الحالي ، يبدو من الغباء أن تضطر إلى حذف أوراق الأنماط التي تم إنشاؤها بواسطة الخادم وإجبار العميل على إعادة عرض جميع الأنماط :(
أود أيضًا أن أوضح أنه يمكن أيضًا كتابة القيم الحرفية للقالب الذي تم وضع علامة عليه. سيقوم TypeScript بتمييزها بشكل صحيح على أنها غير صالحة وستوفر خدمة اللغة اقتراحات الإكمال التلقائي ، إلخ.
@ جنوب باو
العاطفة والمكونات المصممة هي تحسينات كبيرة على كائنات نمط CSS IMO
ما زلت في حيرة من أمري لماذا سيكون أي مطور React في هذا الأمر. إذا كنت تريد وضع CSS في سلاسل القوالب ، فلماذا لا تستخدم Angular وتضع HTML في سلاسل القوالب أيضًا؟ تكمن قوة React في أن عناصر JSX هي في الحقيقة مجرد كائنات JS لديك الكثير من القوة لفحصها وتحويلها ، وينطبق الشيء نفسه على JSS.
كل ما يدفع CSS في حركة JS هو حقيقة أن JS تفوق بشكل كبير على CSS للقيام بالأشياء الديناميكية ، وقوة كائنات JS ليست جزءًا صغيرًا من ذلك.
حقيقة أن styled-components
يدعم الكائنات هو نوع من الرنجة الحمراء:
{
color: 'black',
'&$error': {
color: 'red'
}
}
حتى العاطفة تدفع الاحترام الواجب لقيمة الأشياء الأنيقة وتعاملها على أنها أكثر من مواطن من الدرجة الأولى:
تعد أنماط الكتابة باستخدام الكائنات نمطًا قويًا مدمج مباشرة في جوهر العاطفة.
lcswillems ، أنت تقلل من حجم الصعوبة التي ينطوي عليها إنشاء كل هذه المكوّنات ذات الترتيب الأعلى طوال الوقت (وحقيقة أن معظم أنظمة الاستيراد التلقائي ليست ذكية بما يكفي لمعرفة ما إذا كنت تريد استيراد @material-ui/core/Card
كـ Card
أو MuiCard
(وإذا كنت لا تزال تكتب بيانات الاستيراد يدويًا ، فأنت تضيع وقتك بشدة))
const Card = styled(MuiCard)`
display: flex;
`
const Details = styled.div`
display: flex;
flex-direction: column;
`
const CardContent = styled(MuiCardContent)`
flex: 1 0 auto;
`
const CardMedia = styled(MuiCardMedia)`
width: 151px;
`
يتسبب هذا النوع من الأشياء في إجهاد مروع في اتخاذ القرار حيث يتعين عليك باستمرار تحديد كيفية تسمية كل مكون مُغلف ومُغلف.
هذا ما يتحدث عنه @ dfernandez-asapp عندما يقول:
(بعد فترة من الوقت ، يضيف الحصول على Styled HOC في كل مكان الكثير من العمل الإضافي وبدأت أكره هؤلاء المرتبطين ... على الأقل هذه هي تجربتي الشخصية)
تحتاج المرافقة إلى حد كبير إلى الموت. إنه نمط عفا عليه الزمن. على سبيل المثال ، خرج react-redux
useSelector
بخطاف $ # $ 5 $ # $ وهو أكثر ملاءمة 100 مرة من connect
HOC ، انتقل Apollo من HOCs إلى الخطافات ، الأمر نفسه ينطبق على useStyles
ربط هذه المكتبة أكثر ملاءمة من withStyles
.
تعد مشكلة تحويل CSS الملصقة إلى JSS مشكلة أكثر قابلية للحل ، إذا كان هناك اهتمام ، فسوف أقوم بإنشاء امتداد VSCode لأتمتة ذلك أو موقع ويب.
إذا كان هناك اهتمام ، فسأقوم بعمل امتداد VSCode لأتمتة ذلك
@ jedwards1211 هناك paulmolluzzo.convert-css-in-js
، ولكن إذا كان بإمكانك تحسينه لـ JSS ، فأنا متأكد من أنه سيكون موضع ترحيب.
نعم يبدو أنه يمكنني بالتأكيد تحسينه ، فهو يحول خصائص CSS فقط ، وليس القواعد والمحددات.
@ jedwards1211 لقد قرأت ما قلته ، وأخذت خطوة للوراء بعيدًا عن هذا كله للحظة - إنه يذكرني فقط بتعليقات الأشخاص الذين يجادلون حول استخدام علامات التبويب فوق المساحات. الحقيقة هي أن ما تستخدمه لا يحدث فرقًا طالما أنه ينتج منتجًا مفيدًا في النهاية.
اترك آرائك / اللقاءات الساخنة على Twitter أو Reddit ويمكننا مناقشتها هناك - لكن دعونا لا نستمر في إخراج هذه المشكلة عن مسارها بحروب اللهب التي لا طائل من ورائها على سلاسل القوالب مقابل كائنات لـ CSS ... أعتقد أنه يمكننا أن نتفق جميعًا على أننا أفضل من ذلك 😄
شكرًا للإشارة إلى أنه لا يستحق تغيير الوضع الراهن في MUI؟ 😉
قلقي الرئيسي هو ما إذا كانت حزم webpack الخاصة بي منتفخة بمزيج من كود المكونات المصممة ورمز JSS ، لأن هناك الكثير من JSS الموجودة في تطبيقنا لاستخراجها واستبدالها بشيء آخر ، و / أو لأنني أرغب في التمسك بها JSS لأنماطنا على أي حال.
لكي نكون منصفين ، لا أهتم بعلامات التبويب مقابل المسافات ، لكن إذا اضطررت إلى كتابة نصف دزينة من المكوّنات ذات الترتيب الأعلى لكل مكون أقوم به ، فلن أستمتع بعملي. جميع الأدوات الموجودة لديها القدرة على إنتاج منتج مفيد ؛ إذا كان أي شيء مناسبًا تمامًا للاستخدام في جميع الحالات ، فلن يكون هناك تغيير مستمر في النظام البيئي ، ولن نجري هذه المناقشات. لذا فإن الأمر يحدث فرقًا حقًا عندما تفكر فيه.
@ jedwards1211 حتى إذا كنت مجبرًا على استخدام Styled Components ، فهناك بنية بديلة css prop
مقدمة في v4
يمكنك استخدامها - على الأقل ، بهذه الطريقة لن تقلق بشأن إعطاء بادئات للمكونات المصممة (MuiCard و StyledCard وما إلى ذلك).
import { Avatar } from '@material-ui/core';
// CSS is separate from the markup 👍
const avatarStyle = css`
width: 32px;
height: 32px;
border-radius: 50%
`;
// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
return <div> ... <Avatar css={avatarStyle} /> ... </div>
}
@ jedwards1211 يمكن أيضًا تبسيط مثالك إلى ما يلي إذا كنت تستخدم مكونات ذات نمط
const Card = styled(MuiCard)`
display: flex;
${MuiCardContent} {
flex: 1 0 auto;
}
${MuiCardMedia} {
width: 151px;
}
`
const Details = styled.div`
display: flex;
flex-direction: column;
`
koistya فإن الخاصية css
رائعة نوعًا ما ، على الرغم من التحذير المهم الذي تم تنفيذه باستخدام مكون إضافي من Babel ، لذلك فهي ليست للجميع ، وخاصة الأشخاص الذين يستخدمون tsc لتجميع ملفات tsx الخاصة بهم. أفترض أيضًا أنه سيتسبب في قيام TypeScript أو على الأقل Flow بالشكوى من عدم احتواء المكون على خاصية css
.
أعتقد أنني غير راضٍ بشكل أساسي عن الاضطراب المحتمل الذي قد يتسبب فيه تطبيقي. ذكر oliviertassinari قبل أيام أنه يفكر في جعل styled-components
الخيار الافتراضي في MUI v5. ونأمل أن يكون ذلك اختياريًا ولا يزال من الممكن استخدام JSS ، لكننا سنرى ما إذا كان بإمكانهم تنفيذ ذلك ، كما تعلم. لقد كانت بمثابة صدمة - هل كان هناك حقًا استفتاء شامل حول تفضيلات قاعدة المستخدمين بأكملها؟ كنت أتوقع Emotion إذا كان هناك أي شيء لأنه أكثر شهرة الآن.
أفترض أيضًا أن هذا قد يتسبب في قيام TypeScript أو على الأقل Flow بالشكوى من عدم احتواء المكون على خاصية css.
يمكن تهيئتها.
هل كان هناك حقًا استفتاء شامل حول تفضيلات قاعدة المستخدمين بأكملها؟
هذا مستحيل. يمكننا فقط أن نفترض حقًا أن الأشخاص الذين يشاركون على GitHub هم مستخدمون "لدينا". هذه القضية هي الأكثر تصويتًا على الإطلاق .
كنت أتوقع Emotion إذا كان هناك أي شيء لأنه أكثر شهرة الآن.
كيف تقيس الشعبية؟
⚠️ العاطفة يختارها المطورون بدرجة أقل من المكونات المصممة (/ 6 مما أتذكره). إذا كنت تفكر في التنزيلات على npm ، فقم بإزالة القصص القصيرة وقم بتحديد عدد التنزيلات (إنه ضخم).
@ eps1lon هنا ما كنت أنظر إليه: https://2019.stateofcss.com/technologies/css-in-js/
لكنني كنت مخطئًا ، لسوء الحظ كل ما تذكرته هو الاتجاه التصاعدي الظاهري ، على الرغم من أن هذا لم يكن مخططًا للشهرة بمرور الوقت (تصميم مخطط مشكوك فيه للغاية):
يمكن تهيئتها
هل هناك طريقة فعلاً لجعل TypeScript تفترض أن جميع عناصر JSX تدعم خاصية css
؟ لا أعرف طريقة لتكوين Flow للقيام بذلك.
تحرير : لحسن الحظ وجدت طريقة لـ TypeScript ، لست متأكدًا مما إذا كانت هناك طريقة لـ Flow.
هذه القضية هي الأكثر تصويتًا على الإطلاق.
أنا أرى. تنهد
يبدو أن FWIW ، أحد المساهمين الرئيسيين في styled-components
، لديه موقف غير ودي تجاه أنظمة الكتابة:
https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486
سأشعر بالاطمئنان أكثر بشأن فكرة الانتقال إلى المكونات المصممة إذا بدا أنهم يهتمون بتجربة مطوري TS / Flow لمستخدمي ...
@ jedwards1211 يوجد ماكرو Babel مقابل css
إذا كان ذلك يساعد. لا أعتقد أن الجميع يحب الانتقال إلى الطريقة "المصممة".
ما هي الأهداف بالرغم من ذلك؟ ماذا عن الأداء؟ على سبيل المثال ، تدعم بعض الأنظمة css الذرية. قادمة من Tailwinds ، تجعل الأشياء أكثر نظافة وربما أسرع.
@ hc-codersatlas يمكنك العثور على بعض المعايير في packages/material-ui-benchmark
.
koistya إذا قرأته بشكل صحيح تبدو العاطفة أسرع بكثير من البقية.
oliviertassinari هل يقوم معظم المطورين بالفعل "باتخاذ" هذا الاختيار؟ وفقًا لما ذكرته عن رد الفعل-التحديد وكتاب القصص ، من المرجح أن يستخدم معظم المطورين كل ما هو مجمّع مع مكونات واجهة المستخدم وكون واجهة المستخدم المادية كبيرة 1. ما لم يكن المجمّع فظيعًا ، فلن يزيد حجم الحزمة وينفقها مزيد من الجهد مع نظام مختلف بالإضافة إلى ما يستخدمه إطار عمل واجهة المستخدم بالفعل.
معظم أطر عمل واجهة المستخدم هذه من مجموعات كبيرة ، أي أن عددًا قليلاً من الأشخاص يقومون بالفعل بهذا "الاختيار".
على سبيل المثال ، تستخدم جروميت مكونات مصممة ، والتي تستخدمها / كانت الكثير من الشركات تستخدمها عند نقطة واحدة.
وفي هذه الملاحظة ماذا تعني تنزيلات npm؟ من المحتمل أن يعني استخدام الشركات جدران الحماية والتخزين المؤقت الداخلي لـ npm ، مما يؤدي إلى انحراف هذه المقاييس.
إذا كان هناك تغيير ، فيرجى التغيير إلى الأفضل 1 بناءً على الجدارة الفنية وليس شيئًا مثل الشعبية. أتوقع أنه إذا كانت واجهة المستخدم المادية تستخدم أي مكتبة ، فستكون هي الأكثر شعبية حيث أن mui هي نفسها واحدة من أكثر أطر عمل واجهة المستخدم شيوعًا.
@ South-Paw لن يعمل التبسيط المقترح ، لا يمكنك استخدام ${MuiCardContent}
في المثال الخاص بك لأن MuiCardContent
ليس مكونًا منمقًا.
https://styled-components.com/docs/advanced#referring- إلى- مكونات أخرى
في الأساس لا توجد طريقة لتجنب جميع أغلفة HoC الفردية. على الرغم من أنني بعد التفكير في الأمر لفترة ، أدركت أنه في الأساس نفس مقدار قرارات الكتابة / التسمية التي يتعين على المرء اتخاذها باستخدام JSS.
mbrookesoliviertassinari كيف سيتم التعامل مع الأنماط الشرطية وأنماط المكونات الداخلية؟
على سبيل المثال ، ماذا سيكون المعادل القائم على styled-components
لما يلي؟
// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>
// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>
لقد هدأت من فكرة التبديل إلى styled-components
، لكنني أريد التأكد من وجود خطة قوية للتعامل مع هذه الأنواع من حالات الاستخدام ، لأنني أفترض أن واجهة برمجة التطبيقات يجب أن تكون مختلفة تمامًا أو تعتمد على أسماء فئة نمط BEM.
@ jedwards1211 آه خطأي. كنت تحت انطباع أن المثال كان إذا كانت مكونات مصممة - لكن هذا لن ينجح إذا لم تكن كذلك 👍
@ jedwards1211 clsx هو شيء رأيته مقترنًا بمكونات نمطية في الماضي للفئات الشرطية - هل هذا هو ما تعنيه؟
تستخدم المشاريع التي أقوم بها في الوقت الحالي مكونات MUI المغلفة ذات النمط كما هو مطلوب ، لذا لم أستخدم أيًا من وحدات التصميم الشرطية MUI s'all
@ South-Paw (أو classnames
) يمكن أن تكون تفاصيل داخلية للحل ، لكن ما أعنيه هو أن أغلفة أغلفة styled-components
تقوم فقط بضخ ملف واحد className
AFAICT ، لن يكون هناك إنها حقًا طريقة ملائمة لتمرير عدة أسماء لفئات تجاوز إلى مكون. بدلاً من ذلك ، قد نضطر إلى القيام بشيء مثل <Dialog Paper={StyledPaper}>...</Dialog>
، ولست متأكدًا مما هو الحال بالنسبة لمثال فئة MenuItem
المحدد.
@ jedwards1211 ، هل سيكون لديك الوقت لتقديم مثال سريع حتى أتمكن من فهم حالة الاستخدام التي تصفها بشكل أفضل وأين تشعر بالمشكلة؟ أرغب في تجربة المساعدة في حل ولكني لا أفهم ما الذي ينطبق عليه هذا حتى الآن 😄
نعم ، لقد نفد الوقت الليلة ولكن غدًا سأفعل.
كما أنني حصلت على تقدم في العمل على jss-codemorphs ، وأخطط في النهاية لعمل امتداد VSCode لتحويل CSS الذي تم لصقه إلى JSS.
لم تكن أبدًا من المعجبين ببنية المكونات المصممة أو الطريقة التي يتم بها الحفاظ على الحزمة ، ولم تكن معجبًا بهذا الاقتراح. من أكثر الأشياء التي أحبها في واجهة المستخدم المادية هو حل التصميم الحالي.
من المثير للاهتمام ملاحظة أنني قرأت أن Facebook قد يكون مفتوح المصدر لحل CSS-in-JS أيضًا. قد يكون من المفيد إلقاء نظرة على ذلك أيضًا عندما يخرج.
بخصوص الموضوع الفعلي المطروح. أنا لا أحب المكونات المصممة نظرًا لأن تجربة Typescript ليست رائعة. غالبًا ما تضر الأنواع أكثر من المساعدة. أوقات التجميع البطيئة ، واجهات مجنونة (محاولة فهم كيفية عمل المكونات المصممة من خلال الواجهة هي كابوس بسبب كل تلك العناصر السحرية المتداخلة Pick
). طالما أن المكونات المصممة تحتوي على هذا النوع من DX ، فسيكون ذلك بمثابة خطوة إلى الوراء بالنسبة إلى واجهة المستخدم المادية لاعتماد هذا.
من المثير للاهتمام ملاحظة أنني قرأت أن Facebook قد يكون مفتوح المصدر لحل CSS-in-JS أيضًا.
venikx ما احتمالية حدوث ذلك؟ في المرة الأخيرة التي سمعت فيها عن شيء قد يوحي بأنه كان في https://reactpodcast.simplecast.fm/75 ، بدا أنه هدف مدته 5 سنوات.
حقا؟ لم أكن أعرف أنهم قد قدموا بالفعل "جدول زمني". لسبب ما افترضت أنه سيأتي في نفس الوقت تقريبًا مع الوضع المتزامن. سيئة للغاية.
ومع ذلك ، فإن وجهة نظري حول المكونات المصممة لا تزال قائمة. أفضل استخدام طريقة التعامل مع الأنماط المادية الخالصة مقابل استخدام المكونات المصممة. يبدو أن الأنواع من المكونات المصممة موجودة للمترجم وليس للتوثيق.
شيء مزعج آخر (ولكن ربما يكون هذا تفضيلًا شخصيًا مرة أخرى) هو كيفية تعاملك مع تطبيق الأنماط ديناميكيًا على أحد المكونات. أنا أفضل إضافة أو إزالة classNames على تضمين هذا المنطق في المكون المصمم.
واجهة واجهة المستخدم المادية نظيفة حقًا في الوقت الحالي.
أنا لا أحب المكونات المصممة نظرًا لأن تجربة Typescript ليست رائعة.
لقد استخدمت مكونات نمطية و Typescript معًا في 4 مشاريع كبيرة على الأقل حتى الآن ولم أواجه أي مشاكل مع الأنواع - يمكن أن تكون مشعرة قليلاً عند القيام بأشياء في مكتبة مكونة ، ولكن هذا سيكون في نهاية MUIs - ليس على المستهلكين.
مرات الترجمة البطيئة
لم أختبر هذا في أي مشروع عملت فيه ويستخدمها - هل لديك مثال في مكان ما عما تقصده؟
واجهات مجنونة (محاولة فهم كيفية عمل المكونات المصممة من خلال الواجهة هي كابوس بسبب كل تلك العناصر المتداخلة Pick magic)
يمكنك أيضًا التفكير في المساهمة في مشروع types من أجله إذا كنت تعتقد أنه يمكنك تحسينها بطريقة ما - أنا متأكد من أن الجميع سيقدر أي عمل هناك إذا كان هناك تحسن على ما هو موجود الآن!
أنا أفضل إضافة أو إزالة classNames على تضمين هذا المنطق في المكون المصمم.
لا يوجد ما يمنعك من استخدام الفئات ذات المكونات المصممة:
const Box = styled.div`
height: 160px
width: 160px;
background-color: black;
.red {
background-color: red;
}
`;
// simple usage
<Box className="red" />
// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />
تجدر الإشارة إلى أنه على الرغم من بعض التعليقات التي تدعي خلاف ذلك ، هناك 150 و 27 حول المسألة الأم و 18 👎 و 9 فقط. يبدو أن هناك أقلية صوتية لا تحب هذا النقاش وأغلبية تعتقد أنها خطوة إيجابية 🤷♂
@ South-Paw مشكلة التصويت هي أن الخيار الوحيد هو: JSS مقابل المكونات المصممة. يتعلق الجزء الصوتي بعدم الإعجاب بالمكونات المصممة وليس إعجابهم بـ JSS. ربما إذا كان التصويت
في نهاية اليوم أي شيء أفضل من JSS. انها قديمة. إنها بطيئة وضخمة (حجم الحزمة) ويجب نقلها. لذا فإن الأصوات لا تدعم استنتاجك على الإطلاق.
هل يمكن أن تنتقلوا جميعًا إلى دردشة Spectrum أو أي شيء لا يملأ هذه المشكلة بالضجيج حول تقاتل الأشخاص مع بعضهم البعض لمعرفة من سيفوز بالحجة؟
أنا أتابع سلسلة المناقشات حول هذا الموضوع من الفريق الأساسي.
أعتقد أنك تقلل من تقدير الفريق الأساسي ، وأنا شخصياً أشعر أنه يجب عليك التوقف عن الجدل حول هذا الموضوع والثقة بالفريق الأساسي أكثر ؛ في نهاية اليوم ، الأمر متروك للفريق الأساسي لتحديد اتجاه واجهة المستخدم المادية.
إذا كنت تشعر حقًا برأي قوي حيال ذلك ، فإن واجهة المستخدم المادية مرخصة بشكل مذهل من معهد ماساتشوستس للتكنولوجيا ، قم بتشكيلها ، واستمر في الرؤية التي لديك ، وأنا أشجعك على القيام بذلك ، وربما نتعلم في المستقبل من البيئة المتنوعة.
لكن ، من فضلك ، أتوسل إليكم ، دع الفريق الأساسي يقوم بعمله ، وثق بهم ، لأنهم حقًا أشخاص أكفاء يتمتعون بمهارات مذهلة.
هنا شيء جميل لمشاهدته
في نهاية اليوم أي شيء أفضل من JSS. انها قديمة.
@ hc-codersatlas old == mature - هل يمكنك توضيح سبب كون هذه مشكلة؟
حسنًا ، تبدو مشكلة ساخنة ، ولكن هل يمكن لشخص ما أن يؤكد هذه المعلومات البسيطة: هل من الممكن حاليًا استخدام بناء جملة يشبه styled-components
، مع قوالب حرفية ذات علامات تشبه CSS ، في إصدارات Mui الحالية (4 أو 5) ؟
لم أجد أي إجابة واضحة بنعم أو لا على هذا السؤال. أنا لا أهتم حقًا بالتكنولوجيا الأساسية ، فقط براحة المطورين. يعد نسخ ولصق CSS من InVision مفيدًا جدًا في الأساس في بعض الحالات.
تتعلق هذه المشكلة بحل التصميم المستخدم في Material-UI ، ويبدو أن سؤالك يتعلق بكيفية تصميم تطبيقك / إعادة تصميم المكونات ، والتي يمكنك استخدام أي حل لها:
https://material-ui.com/guides/interoperability/
يحتوي JSS على دعم أساسي للقوالب الحرفية كمكوِّن إضافي.
لقد انتهيت للتو من تنفيذ محول CSS إلى JSS شامل للغاية:
نأمل أن تخلصك من متاعب نسخ CSS ولصقها في أنماط JSS.
@ jedwards1211 انظر هذا
https://css2js.dotenv.dev/
nainardev لقد لاحظت أن الأدوات المساعدة الأخرى محدودة للغاية ، فهي تقوم بتحويل سمات CSS ، لكن لا تقوم بتحويل المحددات ، أو المحددات المتداخلة ، أو الإطارات الرئيسية للرسوم المتحركة ، أو استعلامات الوسائط ، وما إلى ذلك ، وبسبب ذلك ، جعلت أداتي شاملة للغاية ، ويمكنها التحويل نأمل أي CSS كاملة ترميها عليه.
ربما فاتك هذا الرد في مكان ما ، لكنك تريد رفعه على أي حال. نحن في طور الترحيل إلى مكونات واجهة المستخدم المادية بالإضافة إلى تقييم حل التصميم الخاص بنا ( less
مقابل makeStyles
مقابل styled-components
) ، يتم تنفيذ معظم التصميم لدينا من خلال أقل الملفات ومعظم كود MUI الجديد يستخدم makeStyles
، ما أريد أن أوضحه هو أن هذا سيكون جزءًا من v5 ، ما الذي يمكننا فعله لتقليل الدين الفني حول التصميم؟
makeStyles
موجودًا في الإصدار الخامس؟ كيف ستعمل مع styled-components
والموضوعات؟ على سبيل المثال ، كيف سيبدو هذا بـ styled-components
:const useStyles = makeStyles((theme) => ({
paper: {
padding: theme.spacing(2),
textAlign: 'center',
color: theme.palette.text.secondary,
},
}));
theme
في سلسلة قالب ذات نمط أفضل من ذلك ، لذا يمكنني استخدامه عدة مرات؟const StyledContainer = styled.div`
color: ${({ theme }) => theme.palette.primary.main};
padding: ${({ theme }) => theme.spacing(1)};
background-color: ${({ theme }) => theme.palette.background.paper};
`;
makeStyles
في الإصدار الخامس ، فهل نتوقع أي نتيجة أداء إذا كنا نستخدم كل من موفر السمات styled-components
وموفر سمة واجهة المستخدم المادية لقاعدة رموز كبيرة؟أحب استخدام واجهة المستخدم المادية ، شكرًا على العمل الشاق!
تضمين التغريدة
const StyledContainer = styled.div`
${({ theme }) => `
color: ${theme.palette.primary.main};
padding: ${theme.spacing(1)};
background-color: ${theme.palette.background.paper};
`}
`;
شكرا على الرد السريع ، مقدر جدا.
- نعم material-ui.com/guides/interoperability/#theme
هذا رائع جدا. من المحتمل أن تتبع بعض الأعمال حول الأدوات هذا ، فالمشروع الذي أقوم بترحيله لا يستخدم TS ولكن لا يبدو أن خادم VSCode / اللغة لديه أي فكرة عن ماهية theme
في هذه الحالة وأخسر styled-components
تسليط الضوء على النحو كذلك.
شكرا مرة أخرى ، سوف تستمر في متابعة هذا التطور.
oliviertassinari إذا كان هناك ترحيل إلى المكونات المصممة ، فهل هذا يعني أنه لم يعد بإمكاننا الاعتماد على واجهات برمجة تطبيقات CSS مثل <ListItem classes={{ selected: myCustomClassName}}>
للتواجد؟
@ jedwards1211 ستبقى واجهة برمجة التطبيقات classes
.
تمام. أنا مرتبك قليلاً في كيفية استخدام MUI للمكونات المصممة داخليًا بعد ذلك ، حيث لا يمكن للمكونات المصممة إلا تطبيق فئة واحدة على عنصر الجذر.
const MyRoot = styled('div')`
// some nice styles
`;
const MyAwesomeChild = styled('div')`
// some nice styles
`;
export function AwesomeRoot(props) {
return (
<MyRoot className={props.classes?.root}>
<MyAwesomeChild className={props.classes?.child}/>
{props.children}
</MyRoot>
);
}
هل هذا منطقي @ jedwards1211 ؟
yordis أعلم أن الأمر يبدو بهذه البساطة ، لكن كيف يمكنك إعادة تشكيل المحددات المركبة مثل https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js # L75 ؟
لا أستطيع حقًا التفكير في طريقة للحفاظ على هذا السلوك الحالي باستخدام styled-components
، لذلك قد يتسبب في تغييرات مفاجئة أكثر مما يتوقعه الناس.
outlined: {
'&$disabled': {
border: `1px solid ${theme.palette.action.disabledBackground}`,
},
},
من المحتمل أن تعتمد التعليمات البرمجية الحالية والإلغاءات المخصصة للأشخاص على خصوصية CSS في بعض الحالات أيضًا.
ربما هذا؟ لست متأكدًا من المتابعة نظرًا لأن هذا يبدو أساسيًا بالنسبة لي ، فربما أفتقد بعض السياق و / أو المعلومات.
const MyOutlinedComponent = styled('div')`
${props.disabled && `
border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
`}
`;
<MyOutlinedComponent disabled/>
yordis ربما. كما قلت ، على الرغم من أن الناس ربما لا يفكرون في عدد التغييرات العاجلة التي سيحدثها هذا للمستخدمين ، لا أعتقد أن هذا المثال سيمنع كسر التغييرات.
هل تمانع في مشاركة أمثلة حقيقية ، وتغييرات حقيقية محتملة؟
من الصعب متابعتك عندما لا تشارك القضايا القوية. استنادًا إلى رسائلك ، أعتقد أنك لا تفهم هذا الموضوع تمامًا ، أو ربما أكون قد أصدرت أحكامًا خاطئة. الرجاء مساعدتي على فهم ، قد أكون الشخص الخطأ.
oliviertassinari هل ستظل تجاوزات الموضوع تعمل دون تعديل في الإصدار الخامس؟ لكي يعمل مثال التجاوز التالي ، يبدو أنه لا يزال يتعين على MUI تطبيق أسماء الفئات التي تم إنشاؤها بواسطة JSS بالإضافة إلى اسم فئة الجذر الذي تم إنشاؤه styled-components
.
const theme = createMuiTheme({
overrides: {
MuiButton: {
root: {
'&$disabled': {
color: myCustomColor,
},
},
},
},
});
بعد أن فكرت yordis في الأمر أكثر ، أدركت أن المحددات المركبة للأنماط التي تم تمريرها عبر classes
ستظل تعمل ، لحسن الحظ. لست متأكدًا من أنماط تجاوز السمة بالرغم من ذلك.
لقد كان من دواعي سروري استخدام كل من المكونات ذات الأنماط على MUI جنبًا إلى جنب مع نمط MUI البسيط باستخدام style = {object}.
خذ صفحة قائمة النتائج ، التي تحتوي على 50 بطاقة ، كل منها به دوارات وسائط ، ومعلومات ، ومعالجات النقر ، والأزرار ، وما إلى ذلك.
يضيف استخدام المكونات المصممة نصف ثانية تقريبًا إلى وقت العرض ؛ بالمقارنة مع const useStyles = makeStyles
أو style = {object}.
يجب أن أقبل نتيجة تخطيط خارطة الطريق هذه ؛ ولكن من المؤكد أنه سيؤدي إلى حدوث خلل في خططنا لاعتماد واجهة المستخدم إذا لم يتم تجاوزها بشيء آخر من أعلى إلى أسفل تمامًا.
Icehunter ، هل يمكنك نشر نتائجك وأخذ عينة من المشروع عبر الإنترنت ليطلع عليها الأشخاص؟
Icehunter ، هل يمكنك نشر نتائجك وأخذ عينة من المشروع عبر الإنترنت ليطلع عليها الأشخاص؟
سيكون مشروع العينة صعبًا لأنه سيحتوي على كود الملكية. سأقوم بنشر صورة معروضة وقسم نتائج التوقيت في علامة تبويب الأداء قريبًا.
خذ صفحة قائمة النتائج ، التي تحتوي على 50 بطاقة ، كل منها به دوارات وسائط ، ومعلومات ، ومعالجات النقر ، والأزرار ، وما إلى ذلك.
Icehunter هل ترسل أي دعائم لتلك الأنماط؟ سواء كانت 50 بطاقة أو 500 بطاقة ، يجب أن يكون عدد الفئات التي تم إنشاؤها هو نفسه. يبدو أن المثال الخاص بك يحتوي على رمز ملكية لا يمكن مشاركته ولكن هل سيكون من الممكن لك إعادة إنتاج هذه المشكلة باستخدام التعليمات البرمجية التي يمكنك مشاركتها؟
styled()
/ styled.div
تضيف واجهات برمجة التطبيقات مقدار الحمل إلى عرض _ كل عنصر_ ، لذا حتى مع التخزين المؤقت لأسماء الفئات يمكن أن يكون أبطأ. باستخدام makeStyles
يمكنك إرفاق مجموعة من الأنماط مرة واحدة ثم تطبيق أسماء الفئات يدويًا ، والتي غالبًا ما تكون أسرع بشكل ملحوظ.
جمعت مثال CodeSandbox لتوضيح أن الحلول التي تعتمد على المكونات المصممة styled
يمكن أن تكون أبطأ بمقدار 3-4 مرات من MUI makeStyles
:
تعد واجهات برمجة التطبيقات styled
لطيفة للراحة ، لكنني أردد شعورIcehunter بأنه يمكن أن يكون مصدر قلق للأداء عند استخدامه بكثافة في القوائم / الجداول. من الجيد أن يكون لديك makeStyles
كنسخة احتياطية.
schnerd شكرًا لك على تجميع هذه الأمثلة ، فهي توضح القلق جيدًا حقًا. تمامًا كما تعتقد ملاحظة جانبية أن مقدمة المنشور بعبارة "ليس من الصعب رؤية ..." يمكن أن تؤتي ثمارها كنوع من التنازل ولا تضيف حقًا إلى مجموعة ممتازة من الأمثلة
tuxracer الاعتذار - محدث.
Icehunter لا أفهم ما تعنيه بذلك ، هل استخدمت الأنماط الشائعة مع SC أو JSS؟
Icehunter لا أفهم ما تعنيه بذلك ، هل استخدمت الأنماط الشائعة مع SC أو JSS؟
كلاهما في الواقع. انتهى بنا الأمر باستخدام makeStyles ولكن إما أن يكون ذلك أو باستخدام style = {object} حصلنا على نفس نتائج الأداء.
نحن بصدد عملية ترحيل للحصول على أداء أفضل عبر مكتبة المكونات بالكامل والموقع الرئيسي.
كومة من الحكمة أنه مكتوب في nextjs.
فقط لأكون واضحا (عدل):
لقد استخدمت SC على النحو المنشود ، لف مكونات mui. تبين أنها بطيئة للغاية.
ثم استخدمت مكونات mui باستخدام makeStyles و / أو style = {object} من إعداد ملف مشترك ، ومحلي (محاكاة متتالية). أسرع بكثير.
لا أريد منع هذه الفكرة على الإطلاق ؛ ولكن إذا كان ذلك افتراضيًا ؛ إذًا يجب أن تكون هناك طريقة لتجاوز الخيار الافتراضي عالميًا من أعلى إلى أسفل وإدخال الخيار الخاص بك.
ربما هذا؟ لست متأكدًا من المتابعة نظرًا لأن هذا يبدو أساسيًا بالنسبة لي ، فربما أفتقد بعض السياق و / أو المعلومات.
const MyOutlinedComponent = styled('div')` ${props.disabled && ` border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`, `} `; <MyOutlinedComponent disabled/>
ربما أنا في وقت متأخر لهذه اللعبة. لكني أعتقد أن @ jedwards1211 يبحث عن طريقة لكيفية التعبير عن ذلك مع SC: https://codesandbox.io/s/magical-snow-5bzd8
أنا نفسي لدي هذا في بعض الأماكن. لذلك سيكون من الجيد أن يكون الانتقال إلى الإصدار 5 أمرًا سهلاً عندما يأتي ذلك اليوم
في الواقع لست متأكدًا من كيفية عمل شيء كهذا باستخدام المكونات المصممة.
على سبيل المثال ، إذا كانت واجهة المستخدم المادية ستدعم تجاوز المتغيرات الافتراضية لـ Typography
في المستقبل ، أعتقد أن JSS أسهل من المكونات المصممة.
@ heb-mm هناك RFC مفصل هنا والذي ذكر oliviertassinari هذا الموضوع في 7 مارس.
استغرق الأمر أقل من دقيقة للتمرير لأعلى وأرى الإشارة.
تحرير: لأولئك الذين يتساءلون ، قام heb-mm بحذف تعليقهم الآن.
لقد جمعت مثال CodeSandbox لتوضيح أن الحلول التي تعتمد على المكونات المصممة
styled
يمكن أن تكون أبطأ بمقدار 3-4 مرات من MUImakeStyles
:
schnerd لقد قمت بتحديث مقياس الأداء الخاص بك ليشمل واجهة المستخدم المادية styled
api والتي يجب أن تحاكي styled-components
. لقد فوجئت برؤية مدى بطئها بشكل لا يصدق مقارنة بالخيارات الأخرى. راجع https://codesandbox.io/s/css-in-js-comparison-ljtjz؟file=/src/App.js
هل يعرف أي شخص ما إذا كان @emotion/styled
(الذي يحتوي بشكل أساسي على نفس واجهة برمجة التطبيقات مثل المكونات المصممة) سيكون بطيئًا بنفس القدر؟ أنا فقط أتساءل عما إذا كان هناك أي شيء بخصوص تنفيذها يمكن تحسينه بشكل أفضل.
هل يعرف أي شخص ما إذا كان
@emotion/styled
(الذي يحتوي بشكل أساسي على نفس واجهة برمجة التطبيقات مثل المكونات المصممة) سيكون بطيئًا بنفس القدر؟ أنا فقط أتساءل عما إذا كان هناك أي شيء بخصوص تنفيذها يمكن تحسينه بشكل أفضل.
https://codesandbox.io/s/css-in-js-comparison-sej1m
حول بأسرع ما يمكن للمكونات المصممة. ما زالت ليست بالسرعة التي تقدمها MakeStyles. المشكلة التي أراها في الغالب هي إنشاء الكائن واختلافات التخزين المؤقت / حفظ الكائنات.
حسنًا ، قد يسبب هذا مشكلة في خطط الترحيل إلى MUI قليلاً. نحن نتحرك حاليًا بعيدًا عن styled-components
لصالح نظام تصميم واجهة المستخدم المادية بعد أن واجهنا الكثير من المشاكل في إدارة CSS ، والتخصيص ، والأداء. كان styled components
جيدًا في البداية ، فقد أنشأنا حل السمات الخاص بنا فوقه ، ولكن عندما نمت واجهة المستخدم ، نمت CSS أيضًا. نحن نستخدم TypeScript ، لذا فإن حقيقة أنه يمكننا إعادة تشكيل كائن JS بسهولة بدلاً من سلسلة CSS المضمنة كانت نقطة بيع ضخمة. 😕
لذلك أنا جديد تمامًا على Material UI وشاهدت للتو الإصدار ألفا من الإصدار الخامس. @ ldiego08 قلت:
نحن نتحرك حاليًا بعيدًا عن المكونات المصممة لصالح نظام تصميم واجهة المستخدم المادية
عادةً ما أستخدم المكونات المصممة عند العمل مع التفاعل. ما هو نظام تصميم واجهة المستخدم المادية وما هي الطريقة الموصى بها لاستخدام الأنماط و CSS في واجهة المستخدم المادية من الآن فصاعدًا؟ قرأت من خلال هذه الصفحة وليس من الواضح بالنسبة لي ما إذا كنت تؤيد CSS-IN-JS أم لا: https://material-ui.com/system/basics/. عادةً ما أفضل كتابة CSS ليس في بناء جملة الكائن ، وقد استمتعت بفوائد استخدام CSS-IN-JS ، حيث يمكنك استخدام "بناء جملة css العادي" ، ولكن لديك أيضًا قوة JS في متناول اليد.
شكرا على اي مساعدة للبدء!
لا أعرف لماذا تحظى واجهة برمجة تطبيقات المكونات المصممة بشعبية كبيرة. إنه أبطأ ، يجب عليك لف كل شيء في مكون بدلاً من مجرد إنشاء اسم فئة. وأيضًا ، ما هو الشيء الذي يحتوي على حرفية للقالب الموسوم؟ لم نرغب في كتابة css في ملفات css ، لأنه من الأفضل كتابتها في سلسلة جافا سكريبت؟ يعتبر بناء جملة الكائن D أكثر قوة عندما يتعلق الأمر بالتكوين وإعادة البناء ، وما إلى ذلك. بالنسبة لي ، فإن وظائف css و cx للعاطفة البسيطة التي تأخذ كائن css وتعيد اسم الفئة هي واجهة برمجة التطبيقات الأكثر مرونة وقوة. لذلك ، فإن إنشاء أسماء الفئات مع العاطفة واستخدام فئات API هو أمر مرن وقوي للغاية. لذلك لا أفهم لماذا تستبدل الأداء والمرونة بـ "واجهة برمجة تطبيقات أكثر ملاءمة للمطورين" (بالنسبة لبعض الأشخاص ، إنها واجهة برمجة تطبيقات رهيبة).
لا أعرف لماذا تحظى واجهة برمجة تطبيقات المكونات المصممة بشعبية كبيرة. إنه أبطأ ، يجب عليك لف كل شيء في مكون بدلاً من مجرد إنشاء اسم فئة. وأيضًا ، ما هو الشيء الذي يحتوي على حرفية للقالب الموسوم؟ لم نرغب في كتابة css في ملفات css ، لأنه من الأفضل كتابتها في سلسلة جافا سكريبت؟ يعتبر بناء جملة الكائن D أكثر قوة عندما يتعلق الأمر بالتكوين وإعادة البناء ، وما إلى ذلك. بالنسبة لي ، فإن وظائف css و cx للعاطفة البسيطة التي تأخذ كائن css وتعيد اسم الفئة هي واجهة برمجة التطبيقات الأكثر مرونة وقوة. لذلك ، فإن إنشاء أسماء الفئات مع العاطفة واستخدام فئات API هو أمر مرن وقوي للغاية. لذلك لا أفهم لماذا تستبدل الأداء والمرونة بـ "واجهة برمجة تطبيقات أكثر ملاءمة للمطورين" (بالنسبة لبعض الأشخاص ، إنها واجهة برمجة تطبيقات رهيبة).
كان لدي نفس القلق :) ربما يوضح الأمور قليلاً:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539
martinjlowm ، نعم ، نحن في نفس الصفحة :) أعتقد أن أذكى طريقة للذهاب إلى فريق واجهة المستخدم المادية هو تنفيذ نوع من الحلول القابلة للتوصيل وليس الاقتران بأي حل css في حل js ، والسماح للأشخاص باختيار ما يريدون استخدامه و حفظ بعض حجم الحزمة بهذه الطريقة. وأيضًا الاحتفاظ بالفئات وإنشاء واجهة برمجة تطبيقات MuiTheme ، لأن هذا هو أقوى جزء فيها. بالنسبة لي ، يتعلق css in js بتصميم ديناميكي سهل يعتمد على حالة المكون ، والثقة عند إعادة بناء أو حذف css أو مكونات كاملة (حيث يكون نهج الكائن متفوقًا) ، والأداء (وليس تنزيل مجموعة من الأنماط غير المستخدمة من مجموعة من أوراق الأنماط الخارجية) ، إلخ .. ومرة أخرى ، لا أفهم لماذا يحب الناس كتابة السلسلة مع إبراز بعض المحررين. أعني ، عليك استخدام $ {} للوصول إلى الدعائم من السياق. لأي شيء أكثر تعقيدًا من تعيين خلفية عنصر div ، فإن هذا النهج فوضوي وغير قابل للقراءة في رأيي. أنا لا أقوم بضربها ، فقط أقول ما أعتقده وأحاول إثبات نقطة أنه ليس كل مطور يحب المكونات المصممة ، وحتى لو فعلوا ذلك ، لا أرى كيف أنها صفقة جيدة لتداول الأداء والمرونة لذلك :)
vdjurdjevic في الواقع ، اقتران material-ui بواحد css في حل js يكاد يكون وصفة مضمونة للنزاع عندما تنمو ممارسات css-in-js حتمًا في اتجاهات مختلفة.
ماذا عن بعض نمط المحول الذي يطبق التصميم مع موفر css-in-js معين؟ يجب تحديد الأنماط نفسها بتنسيق متسق داخل حزم واجهة المستخدم المادية. إنه تطبيق تلك الأنماط التي يتم إجراؤها بشكل مختلف بواسطة المحولات المقابلة.
شيء على غرار:
import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return
(<ThemeProvider theme={theme} adapter={EmotionAdapter}>
...
</ThemeProvider>)
vdjurdjevic أتفق تمامًا مع أفكارك حول https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320. قد يعجبك هذا الملخص للاتجاه الذي نتخذه والذي شاركته مؤخرًا في https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178.
لا أفهم لماذا يحب الناس كتابة سلسلة مع إبراز بعض المحرر
هناك سببان من وجهة نظري:
React.createElement('div', {})
.oliviertassinari حسنًا ، هذه بعض النقاط الصلبة ، أوافق عليها :) ولكن مع ذلك ، بالنسبة لي (لست مصممًا ، وليس مبتدئًا ، أو مطورًا أول) ، لن تكون المكونات المصممة والقوالب ذات العلامات الحرفية خيارًا أبدًا. لقد قرأت ملخصك لمعرفة اتجاه التطوير الإضافي ، ويسعدني أن أسمع أن محرك css سيكون اختياريًا. لا أمانع في أن تكون المكونات المصممة افتراضيًا (إذا كان هذا ما يحبه غالبية المستخدمين) ، طالما يمكنني تبديل ذلك. ولكي أكون صادقًا ، أعتقد أنني سألتزم بـ JSS مع الإصدار 4 لمشروعي التالي ، فهو يحتوي على بعض الميزات الرائعة (مثل توسيع وإنشاء المكونات الإضافية). اضطررت إلى كتابة البرنامج المساعد stylis للعاطفة للحصول على شيء مشابه.
ملاحظة. أنا لست من كبار المعجبين بـ JSX أيضًا :) إنه سريع الفوضى ، ينتهي بك الأمر برمز السهم وللمكونات التي يجب أن تقدم عناصر ديناميكية ، ليس لديك خيار سوى استخدام createElement. عدم القول إن العمل مباشرة مع createElement أفضل ، فقط قل أن JSX ليس مثاليًا. في رأيي ، Flutter لديه أفضل DX ، وآمل أن يكون قادرًا على التعامل مع منصة الويب بشكل جيد يومًا ما.
oliviertassinari وفقًا لاختبار الأداء المستمر لدينا كما هو مذكور في https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 ، آمل فقط ألا يختار فريق المواد المكونات المصممة فقط لأنها تحظى بشعبية. انه بطئ. لقد كان دائما. شخصيًا ، من المهم أن تكون مطورًا تحتاج إلى تعلم أشياء مثل تدوين JS لـ CSS.
إنه جزء من الوظيفة.
إن جعل حياة المطورين أسهل هو جزء من عملنا كمسؤولين عن صيانة الحزم (بالنسبة لمشاريعي الخاصة التي أتحدث عنها) ولكن هناك خط فاصل بين جعل الأمر سهلاً وجعله فعالاً.
هذا هو السبب في أنني لا أستخدم سوى makeStyles ودائمًا ما أستخدمها منذ طرحها.
لم يستمع مهندس فريقي الأخير واستمر في استخدام المكونات المصممة ، والآن أصبح الموقع بطيئًا. لقد قمت بالتبديل إلى makeStyles في فرع اختبار ووفرت 50٪ (10 ثوانٍ) على TTI على الأجهزة المحمولة ، ولكن كما قلت في هذا التعليق ، فإن تدوين JS غير معروف من قبل الجميع لذا لم يتم قبوله.
داخليًا ، يمكن للمادة أن تختار ما تريد ولكن يرجى جعلها فعالة بشكل افتراضي.
[تم نقل السؤال إلى StackOverflow.]
haysclark الرجاء استخدام StackOverflow لأسئلة الدعم بدلاً من معالجتها في RFC.
haysclark الرجاء استخدام StackOverflow لأسئلة الدعم بدلاً من معالجتها في RFC.
mbrookes شكرًا على التنبيه!
هل يعرف أي شخص ما إذا كان
@emotion/styled
(الذي يحتوي بشكل أساسي على نفس واجهة برمجة التطبيقات مثل المكونات المصممة) سيكون بطيئًا بنفس القدر؟ أنا فقط أتساءل عما إذا كان هناك أي شيء بخصوص تنفيذها يمكن تحسينه بشكل أفضل.https://codesandbox.io/s/css-in-js-comparison-sej1m
حول بأسرع ما يمكن للمكونات المصممة. ما زالت ليست بالسرعة التي تقدمها MakeStyles. المشكلة التي أراها في الغالب هي إنشاء الكائن واختلافات التخزين المؤقت / حفظ الكائنات.
كنت أتساءل ما هو أداء مكون Box الذي سيتم مقارنته بالتنميط الخاص بك ، وأضفت Chakra-UI's Box لقياس جيد ، وكانت النتائج ... مفاجأة: P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx؟file=/src/App.js
Nvveen هل جربت Chakra-UI v1؟ تمت إعادة كتابته ونأمل أن يكون أفضل. هناك أيضًا عاطفة v11 ، على الرغم من أنها لا تزال في مرحلة تجريبية.
Nvveen هل جربت Chakra-UI v1؟ تمت إعادة كتابته ونأمل أن يكون أفضل. هناك أيضًا عاطفة v11 ، على الرغم من أنها لا تزال في مرحلة تجريبية.
لقد جربتها للتو مع أحدث إصدار من RC ، ولكن دون اختلاف ملحوظ ؛ لا يزال بطيئًا بمعدل 1.5x إلى 2x مثل SC العادي. أكبر سؤال لي هو لماذا يكون MUI Box بطيئًا جدًا.
Nvveen هل جربت Chakra-UI v1؟ تمت إعادة كتابته ونأمل أن يكون أفضل. هناك أيضًا عاطفة v11 ، على الرغم من أنها لا تزال في مرحلة تجريبية.
لقد جربتها للتو مع أحدث إصدار من RC ، ولكن دون اختلاف ملحوظ ؛ لا يزال بطيئًا بمعدل 1.5x إلى 2x مثل SC العادي. أكبر سؤال لي هو لماذا يكون MUI Box بطيئًا جدًا.
يستخدم Jss. SC هي على الأقل أفضل إلى حد ما.
على جهازي ، يؤثر الترتيب الذي يتم تشغيل حالات الاختبار به على النتائج. قارن
oliviertassinari جمع القمامة و jit من الإصدار 8 هو سبب ذلك. من الأفضل إجراء اختبارات منفصلة / منفصلة حقًا. الاختبارات اللاحقة لها أداء أفضل ، ولكن من حين لآخر ستؤدي إلى جمع القمامة.
يبدو أن Emotion و SC و Chakra كلها قريبة من الحد الأقصى النظري للكمال عندما يكون لكل مكون صغير أنماطه الخاصة ليتم تركيبها ، مع عدم تصميم MUI بشكل كامل بعد. يبدو أن الطريقة الوحيدة للحصول على أداء أفضل من ذلك هي الحصول على ورقة نمط واحدة لشجرة المكونات بالكامل كما هو الحال في makeStyles / pure CSS. أعتقد أن 30 مللي ثانية إضافية للعاطفة ، SC وما إلى ذلك هو الحمل الزائد الذي لا مفر منه لكل مكون صغير يجب التأكد من تركيب أنماطه.
@ jedwards1211 إذا كان الأمر يتعلق بالحفاظ على dx ، فقد قام Atlassian بعمل lib يقوم بترجمته إلى css ، يسمى مترجم
التعليق الأكثر فائدة
oliviertassinari وفقًا لاختبار الأداء المستمر لدينا كما هو مذكور في https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 ، آمل فقط ألا يختار فريق المواد المكونات المصممة فقط لأنها تحظى بشعبية. انه بطئ. لقد كان دائما. شخصيًا ، من المهم أن تكون مطورًا تحتاج إلى تعلم أشياء مثل تدوين JS لـ CSS.
إنه جزء من الوظيفة.
إن جعل حياة المطورين أسهل هو جزء من عملنا كمسؤولين عن صيانة الحزم (بالنسبة لمشاريعي الخاصة التي أتحدث عنها) ولكن هناك خط فاصل بين جعل الأمر سهلاً وجعله فعالاً.
هذا هو السبب في أنني لا أستخدم سوى makeStyles ودائمًا ما أستخدمها منذ طرحها.
لم يستمع مهندس فريقي الأخير واستمر في استخدام المكونات المصممة ، والآن أصبح الموقع بطيئًا. لقد قمت بالتبديل إلى makeStyles في فرع اختبار ووفرت 50٪ (10 ثوانٍ) على TTI على الأجهزة المحمولة ، ولكن كما قلت في هذا التعليق ، فإن تدوين JS غير معروف من قبل الجميع لذا لم يتم قبوله.
داخليًا ، يمكن للمادة أن تختار ما تريد ولكن يرجى جعلها فعالة بشكل افتراضي.