Material-ui: استخدم المكونات المصممة في جميع العروض التوضيحية

@oliviertassinari what is the exactly the tasks in hand? oliviertassinari ما هي بالضبط المهام التي في متناول اليد؟

Here is what I understand, هذا ما فهمته ،

1. Run the docs website قم بتشغيل موقع المستندات
2. Find all the example source code that uses material-ui/styles ابحث عن جميع أمثلة التعليمات البرمجية المصدر التي تستخدم material-ui/styles
3. Replace them with styled-components استبدلها بـ styled-components

Is this correct? هل هذا صحيح؟

@yordis I think that the timing is going to be key in this transition. yordis أعتقد أن التوقيت سيكون مفتاحًا في هذا الانتقال. I would imagine the following steps: أتخيل الخطوات التالية:

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. نستبدل استخدام @ material-ui / الأنماط في العروض التوضيحية بمكوِّن Box ، حيثما أمكن ذلك. Moving #16858 at the same time would help. نقل # 16858 في نفس الوقت من شأنه أن يساعد. This can be done in the near future. يمكن القيام بذلك في المستقبل القريب.
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. تم حل المشكلة رقم 15561 ، وقمنا بترحيل المزيد من العروض التوضيحية بعيدًا عن @ material-ui / الأنماط لاستخدام دعامات النظام. The sooner we solve this, the better. كلما أسرعنا في حل هذا الأمر ، كان ذلك أفضل.
3. We update the customization demos to use styled-components, leveraging the global Mui class names. نقوم بتحديث عروض التخصيص التوضيحية لاستخدام المكونات المصممة ، والاستفادة من أسماء فئات Mui العالمية. We might need to work on some helpers to make accessing the theme values easier. قد نحتاج إلى العمل على بعض المساعدين لتسهيل الوصول إلى قيم الموضوع.
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. قمنا بحل # 6115 ، ونقوم بترحيل آخر استخدامات @ material-ui / الأنماط إلى المكونات المصممة. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. هذه مهمة لـ v5 ، أعتقد أنه يمكننا البدء في Q1 2020 في إصدارات v5 alpha / beta.

oliviertassinari لدي فضول ، وأعتذر إذا تكرر هذا: لماذا لا تحتفظ بـ @material-ui/styles كغلاف أو تجريد مقابل styled-components ؟

@ConAntonakos it's an option. ConAntonakos هذا خيار. It could help if we need to extend/normalize some of the features of styled-components. يمكن أن يساعد إذا احتجنا إلى تمديد / تطبيع بعض ميزات المكونات المصممة.

oliviertassinari ، هل لدينا قائمة بما تبقى؟

@yordis We haven't done many efforts in this direction yet. yordis لم نبذل الكثير من الجهود في هذا الاتجاه حتى الآن. However, there is a probability that it will require breaking changes, v5 is planned for around Q4 2020. I think that we should explore a partial deployment strategy for developers that want to leverage it sooner. ومع ذلك ، هناك احتمال أن يتطلب الأمر تغييرات جذرية ، الإصدار 5 مخطط له في حوالي الربع الرابع من عام 2020. أعتقد أنه يجب علينا استكشاف استراتيجية نشر جزئية للمطورين الذين يرغبون في الاستفادة منها في وقت أقرب. Now, this effort has to be balanced with the other priorities, like the support of new advanced components (free and paid) or the release of an unstyled version of the library to increase our audience reach (with different themes, eg iOS style). الآن ، يجب موازنة هذا الجهد مع الأولويات الأخرى ، مثل دعم المكونات المتقدمة الجديدة (المجانية والمدفوعة) أو إصدار نسخة غير منظمة من المكتبة لزيادة وصول جمهورنا (بمواضيع مختلفة ، مثل نمط iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. النبأ السار هو أننا سننمي الفريق على الأرجح في الأشهر المقبلة ، مما سيمكننا من التحرك بشكل أسرع.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). أتخيل أنك تستخدم بالفعل مكونات مصممة أعلى Material-UI اليوم كما يفعل العديد من المطورين الآخرين (وليس @material-ui/styles ). What are the top pain points you hope to address with this migration? ما هي أهم نقاط الألم التي تأمل في معالجتها من خلال هذه الترحيل؟

From a product perspective, our incentive is about: smaller bundle size, better performance, steaming support, fewer bugs, CSS template strings support, larger community, enables to use the system props in the core components, allow true dynamic themes and props support, better docs. من منظور المنتج ، حافزنا يدور حول: حجم حزمة أصغر ، أداء أفضل ، دعم تبخير ، عدد أقل من الأخطاء ، دعم سلاسل قوالب CSS ، مجتمع أكبر ، يمكّن من استخدام دعائم النظام في المكونات الأساسية ، السماح للموضوعات الديناميكية الحقيقية ودعم الدعائم ، مستندات أفضل.

However, there is a high probability that it will require breaking changes, ومع ذلك ، هناك احتمال كبير أنه سيتطلب تغييرات متقطعة ،

Yeah, I tried to change some examples, but they require some integration with the theme provider, so we may need to inject material/style theme provider and styled-component theme provider I am assuming. نعم ، لقد حاولت تغيير بعض الأمثلة ، لكنها تتطلب بعض التكامل مع موفر السمة ، لذلك قد نحتاج إلى حقن مزود السمات material/style وموفر السمات styled-component الذي أفترضه.

v5 is planned for around Q4 2020. الإصدار 5 من المقرر إجراؤه في الربع الرابع من عام 2020 تقريبًا.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? هذا بعيد كل البعد ، هل سيكون من الأفضل تحديد قضايا مختلفة للظهور على ما يمثل أولوية في الوقت الحالي؟

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). أتخيل أنك تستخدم بالفعل مكونات نمطية أعلى واجهة المستخدم المادية اليوم كما يفعل العديد من المطورين الآخرين (وليس @ material-ui / الأنماط).

Actually, I am quite happy with @material-ui/styles and I am not using styled-components when I use Material UI (I would remove withStyles since I don't want to rely on programmer discipline 😉 , but I understand legacy software may no have hooks still )🤷‍♂️ في الواقع ، أنا سعيد جدًا بـ @material-ui/styles ولا أستخدم styled-components عندما أستخدم واجهة المستخدم المادية (سأزيل withStyles لأنني لا أريد الاعتماد على انضباط المبرمجين 😉 ، لكنني أفهم أن البرامج القديمة قد لا تحتوي على خطافات) 🤷‍♂️

What are the top pain points you hope to address with this migration? ما هي أهم نقاط الألم التي تأمل في معالجتها من خلال هذه الترحيل؟

I am trying to help with the migration, personally, no pain points. أحاول المساعدة في الهجرة ، شخصيًا ، لا توجد نقاط ألم. Unless you take into consideration that as an ecosystem, I have to maintain two ways to develop something, but meh, personally, it is okay for me. ما لم تأخذ في الاعتبار أنه كنظام بيئي ، يجب أن أحافظ على طريقتين لتطوير شيء ما ، ولكن ، شخصيًا ، هذا جيد بالنسبة لي.

Maybe styled-components fixes some interoperability with NextJS and Gatsby since the last time I tried was hard to make Mui work with those tools because of the SSR and styles (I am not sure if still painful) and most libraries using styled-components work out of the box. ربما يصلح styled-components بعض إمكانية التشغيل البيني مع NextJS و Gatsby منذ آخر مرة حاولت فيها أن أجعل Mui يعمل مع هذه الأدوات بسبب SSR والأنماط (لست متأكدًا مما إذا كان لا يزال مؤلمًا) ومعظم المكتبات تستخدم styled-components العمل خارج الصندوق.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org اسمحوا لي أن أعرف كيف يمكنني المساعدة ، كما قلت ، كنت أستخدم المشكلات المثبتة للعثور على ترتيب أولويات المؤسسة

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? هذا بعيد كل البعد ، هل سيكون من الأفضل تحديد قضايا مختلفة للظهور على ما يمثل أولوية في الوقت الحالي؟

It depends on the time horizon you are interested in. You can follow the issue with the label important , the roadmap page on the documentation and the monthly blog product updates. يعتمد ذلك على الأفق الزمني الذي تهتم به. يمكنك متابعة المشكلة مع التسمية important ، وصفحة خريطة الطريق في الوثائق وتحديثات منتج المدونة الشهرية.

I don't fully understand this point. أنا لا أفهم هذه النقطة بشكل كامل. Why not using styled-components when using Material-UI (today)? لماذا لا تستخدم المكونات المصممة عند استخدام Material-UI (اليوم)؟ We had 1/3 of our users going down this path when we did our last survey, 6 months ago. كان لدينا ثلث مستخدمينا يسلكون هذا المسار عندما أجرينا الاستطلاع الأخير ، قبل 6 أشهر.

I don't fully understand this point. أنا لا أفهم هذه النقطة بشكل كامل. Why not using styled-components when using Material-UI (today)? لماذا لا تستخدم المكونات المصممة عند استخدام Material-UI (اليوم)؟

@material-ui/styles works like a champ so far, no reason to migrate everything 😄 so I am one of those out of 3 that don't use it together today. @material-ui/styles يعمل كبطل حتى الآن ، لا يوجد سبب لترحيل كل شيء 😄 لذلك أنا واحد من بين 3 لا يستخدمونه معًا اليوم.

Thank you for the info about prioritization. شكرا لك على المعلومات حول تحديد الأولويات.

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. yordis راجع للشغل ، تم تقديم إجابتي على افتراض أنك كنت تتابع مشكلة المكونات المصممة الرئيسية. I haven't realized we were on the documentation one. لم أدرك أننا كنا على التوثيق.

@oliviertassinari do you have any suggestions about the issue with theme context? oliviertassinari ، هل لديك أي اقتراحات حول المشكلة مع سياق الموضوع؟

I tried to use props.theme inside an styled-components but didn't work, I am not sure if you have a suggestion for it, but I think we will require to add styled-components theme provider as well. حاولت استخدام props.theme داخل styled-components لكن لم ينجح ، لست متأكدًا مما إذا كان لديك اقتراح لذلك ، لكنني أعتقد أننا سنطلب إضافة styled-components مزود الموضوع كذلك.

Hey @oliviertassinari! ياoliviertassinari! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? هل تبحث عن علاقات عامة تقوم بتحويل عروض التخصيص التوضيحية الحالية لاستخدام المكونات المصممة كجزء من هذه المشكلة؟

I dont think styled-components is a good styling solution. لا أعتقد أن styled-components هو حل تصفيف جيد. current solution looks much much more readable, appealing, accessible and cleaner than styled. يبدو الحل الحالي أكثر قابلية للقراءة وجاذبية وسهولة الوصول إليه وأنظف من التصميم. i dont see any good reason to migrate. لا أرى أي سبب وجيه للهجرة.

I dont think styled-components is a good styling solution. لا أعتقد أن styled-components هو حل تصفيف جيد. current solution looks much much more readable, appealing, accessible and cleaner than styled. يبدو الحل الحالي أكثر قابلية للقراءة وجاذبية وسهولة الوصول إليه وأنظف من التصميم. i dont see any good reason to migrate. لا أرى أي سبب وجيه للهجرة.

And get almost fully typed. وتكاد تكتب بشكل كامل. Don't see any reason to migrate +1 لا ترى أي سبب لترحيل +1

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: الرابط الذي نشرته ، والذي يجب أن يُظهر اهتمامًا متزايدًا بالمكونات المصممة ، بدأ مؤخرًا في إظهار اتجاه تنازلي:

I feel that narrowing down a styling solution to a single library is going to give us the exact same problem as we have today. أشعر أن تضييق نطاق حل التصميم لمكتبة واحدة سيعطينا نفس المشكلة التي نواجهها اليوم.

What about integration with zero-runtime libraries such as linaria ? ماذا عن التكامل مع مكتبات وقت التشغيل الصفري مثل Linaria ؟ This was suggested as being looked at in May 2019 Update . تم اقتراح هذا باعتباره قيد النظر في تحديث مايو 2019 .

So far it only recovered to pre-v5-hype. حتى الآن تعافى فقط إلى الضجيج قبل v5. Let's see how the updated data point for January till now looks. دعونا نرى كيف تبدو نقطة البيانات المحدثة لشهر يناير حتى الآن.

@TheHolyWaffle Don't trust rank2traffic.com too much, data hasn't been very reliable nor up-to-date, its main advantage was the overall trend over 10 years (before it was made paid). TheHolyWaffle لا تثق في Rank2traffic.com كثيرًا ، فالبيانات لم تكن موثوقة جدًا ولا حديثة ، وكانت ميزتها الرئيسية هي الاتجاه العام على مدار 10 سنوات (قبل دفعها). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. للحصول على نافذة زمنية أقصر ، لذلك 6 أشهر ، تفضل https://www.similarweb.com/ باعتباره أكثر موثوقية.
Also take into account that once people know the API, they come back much frequently to the documentation. ضع في اعتبارك أيضًا أنه بمجرد معرفة الأشخاص بواجهة برمجة التطبيقات ، فإنهم يعودون كثيرًا إلى الوثائق.

I dont think styled-components is a good styling solution. لا أعتقد أن styled-components هو حل تصفيف جيد. current solution looks much much more readable, appealing, accessible and cleaner than styled. يبدو الحل الحالي أكثر قابلية للقراءة وجاذبية وسهولة الوصول إليه وأنظف من التصميم. i dont see any good reason to migrate. لا أرى أي سبب وجيه للهجرة.

And get almost fully typed. وتكاد تكتب بشكل كامل. Don't see any reason to migrate +1 لا ترى أي سبب لترحيل +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles هو السبب الرئيسي لترحيلنا إلى واجهة المستخدم المادية والابتعاد عن المكونات المصممة. It's too much CSS and refactoring it has proven to be a huge burden for us. إنها CSS كثيرة جدًا ، وقد أثبتت إعادة البناء أنها عبء ثقيل بالنسبة لنا.

Hi! أهلاً! First of all, thank you for providing a great component library, best one I've used so far. بادئ ذي بدء ، شكرًا لك على توفير مكتبة مكونات رائعة ، أفضل مكتبة استخدمتها حتى الآن. Our teams have written hundreds of thousands of lines of code using the components and methodology you created and once developers learn the basics of using classes , how to write the styles etc., it's a breeze to work with even on a massive enterprise scale type of codebase. لقد كتبت فرقنا مئات الآلاف من سطور التعليمات البرمجية باستخدام المكونات والمنهجية التي أنشأتها ، وبمجرد أن يتعلم المطورون أساسيات استخدام classes ، وكيفية كتابة الأنماط وما إلى ذلك ، فمن السهل التعامل معها حتى على نوع نطاق المؤسسة الضخم من قاعدة البيانات.

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI, and so any components and decision you make also trickle down to those libraries. لست متأكدًا مما إذا كان هذا هو الاستخدام الأكثر شيوعًا لمكتبتك ، لكنني أفترض أنك تدرك أن العديد من الفرق تبني مكتبات المكونات الخاصة بهم فوق واجهة المستخدم المادية ، وبالتالي فإن أي مكونات وقرار تتخذه تتسرب أيضًا إلى تلك المكتبات. On our end we've been very happy with both performance and APIs so far. من جانبنا ، كنا سعداء جدًا بكل من الأداء وواجهات برمجة التطبيقات حتى الآن.

I've been following recent development in the library and to be honest, I'm having trouble understanding some of the decisions and worried how that will affect our teams, and what's overall the benefit of this move would be, as opposed to for example forking MUI. كنت أتابع التطورات الأخيرة في المكتبة ولكي أكون صادقًا ، أجد صعوبة في فهم بعض القرارات وأشعر بالقلق من كيفية تأثير ذلك على فرقنا ، وما الفائدة الإجمالية من هذه الخطوة ، على عكس على سبيل المثال تفرع MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. أعرب آخرون عن قلقهم بشأن الانتقال إلى المكونات المصممة لذلك سأركز على العنصر الآخر بالنسبة لي - مكون Box.

I understand the utility of a Box component - to make it possible to use theme variables etc. in prop values, however the API and the consequences of using this component disqualify it from something I could recommend to our teams. أفهم فائدة مكون Box - لإتاحة استخدام متغيرات السمة وما إلى ذلك في قيم العناصر ، إلا أن واجهة برمجة التطبيقات وعواقب استخدام هذا المكون تحرمها من شيء يمكنني أن أوصي به لفرقنا.

First , it has a cryptic API for no reason I can discern (unless saving a few bytes is that reason): Instead of writing <Box margin={3} /> , it would be <Box m={3} /> . أولاً ، يحتوي على واجهة برمجة تطبيقات مشفرة بدون سبب يمكنني تمييزه (ما لم يكن حفظ بضع وحدات بايت هو هذا السبب): بدلاً من كتابة <Box margin={3} /> ، سيكون <Box m={3} /> .

Abbreviations like that seem needless, make things potentially ambigious, and introdue a new learning curve to developers, a mapping of abbreviations to actual properties they now need to memorize: "Is applying color done using c or color ?", "Is background a b , or bg , or background , or was b a border ?" تبدو الاختصارات من هذا القبيل لا داعي لها ، وتجعل الأمور غامضة ، وتقدم للمطورين منحنى تعليميًا جديدًا ، وتخطيطًا للاختصارات للممتلكات الفعلية التي يحتاجون الآن إلى حفظها: "يتم تطبيق color تم إنجازه باستخدام c أو color ؟ "أو" Is background a b أو bg أو background أو b a border ؟ " "Is background-size abbreviated as bs ?" "هل يتم اختصار background-size كـ bs ؟"

Second , components abstract most commonly recurring UI patterns, and create APIs that provide means of customizing those patterns to the extent that the design system permits. ثانيًا ، تجرد المكونات أنماط واجهة المستخدم المتكررة الأكثر شيوعًا ، وتقوم بإنشاء واجهات برمجة التطبيقات التي توفر وسائل لتخصيص تلك الأنماط إلى الحد الذي يسمح به نظام التصميم. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. يتجلى ذلك في إنشاء عناصر مثل gutterBottom على Typography ، أو dense على ListItem - بدلاً من قبول أي مساحة متروكة أو هامش. I feel like introducing Box to large extent undermines this effort and introduces a tool that will make a mess out of any attempt to follow a design system unless we define some very nitpicky ways that Box component can be used for and spend effort in code reviews to make sure the all the values in used Box props aren't beyond the accepted list. أشعر أن تقديم Box إلى حد كبير يقوض هذا الجهد ويقدم أداة من شأنها إحداث فوضى في أي محاولة لاتباع نظام تصميم ما لم نحدد بعض الطرق المعقدة التي يمكن استخدام مكون Box من أجلها وإنفاقها الجهد المبذول في مراجعات الكود للتأكد من أن جميع القيم في أدوات Box المستخدمة لا تتجاوز القائمة المقبولة. And at that point, the way to "automate" this would be to create a component that restricts the options, and we're backt to square one. وعند هذه النقطة ، فإن طريقة "أتمتة" هذا ستكون إنشاء مكون يقيد الخيارات ، ونعود إلى المربع الأول. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? لإعطاء مثال ، لماذا يكون استخدام Box mb={2} لتحقيق الهامش في ظل الطباعة أمرًا مقبولاً ، بينما لا يكون استخدام Box mb={6} ؟ This concern doesn't exist when we can rely on props to limit the options. لا يوجد هذا القلق عندما يمكننا الاعتماد على الدعائم للحد من الخيارات.

Third concern, or rather a question I have. القلق الثالث ، أو بالأحرى سؤال عندي. Since the Box component is potentially a quick way to build certain functionality, it would be also used by libraries built on top of MUI. نظرًا لأن مكون Box يُحتمل أن يكون طريقة سريعة لبناء وظائف معينة ، فسيتم استخدامه أيضًا بواسطة المكتبات المبنية على قمة MUI. How would one override the styles of Box components used within another component? كيف يمكن للمرء تجاوز أنماط مكونات Box المستخدمة في مكون آخر؟ As an example. كمثال. If we built ListItem using Box under the hood, would we need to introduce BoxProps={{ padding: 2 }} , or accept also dense prop based on which we write logic to apply a padding prop to a particular Box, or still something else? إذا قمنا ببناء ListItem باستخدام Box تحت الغطاء ، فهل سنحتاج إلى تقديم BoxProps={{ padding: 2 }} ، أو قبول أيضًا dense prop بناءً عليه نكتب منطقًا لتطبيق padding prop على مربع معين ، أو لا يزال شيء آخر؟

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI , and so any components and decision you make also trickle down to those libraries. لست متأكدًا مما إذا كان هذا هو الاستخدام الأكثر شيوعًا لمكتبتك ، لكنني أفترض أنك تدرك أن العديد من الفرق تبني مكتبات المكونات الخاصة بهم فوق واجهة المستخدم المادية ، وبالتالي فإن أي مكونات وقرار تتخذه تتسرب أيضًا إلى تلك المكتبات. On our end we've been very happy with both performance and APIs so far. من جانبنا ، كنا سعداء جدًا بكل من الأداء وواجهات برمجة التطبيقات حتى الآن.

@maciej-gurban This use case is an important one for us. @ maciej-gurban حالة الاستخدام هذه مهمة بالنسبة لنا. Our incentives are aligned to significantly improve it. تتماشى حوافزنا لتحسينها بشكل كبير. This is one of our objectives with v5. هذا هو أحد أهدافنا مع الإصدار 5.

For instance, we are investigating the feasibility to provide a design tool that could be put in the hands of designers (paid) and would output ready to use customized Material-UI components (MIT), corresponding documentation, Sketch & Figma kit. على سبيل المثال ، نحن ندرس جدوى توفير أداة تصميم يمكن وضعها في أيدي المصممين (مدفوعة الأجر) وستكون جاهزة لاستخدام مكونات Material-UI (MIT) والوثائق المقابلة ومجموعة Sketch & Figma. Basically, all we have been going it for Material Design but scaling it 🚀. في الأساس ، كل ما كنا نذهب إليه من أجل التصميم متعدد الأبعاد ولكننا نوسع نطاقه 🚀.
The end goal here would be to free the time of a couple of front-end developers in each company. سيكون الهدف النهائي هنا هو توفير وقت اثنين من مطوري الواجهة الأمامية في كل شركة. Why have front-end developers build a custom design system when it can be done by your own designers + Material-UI at a fraction of the cost? لماذا قام مطورو الواجهة الأمامية ببناء نظام تصميم مخصص بينما يمكن أن يقوم به المصممون الخاصون بك + واجهة المستخدم المادية بجزء بسيط من التكلفة؟ + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + قلل من المخاطر واجعل مطوري الواجهة الأمامية يقضون الوقت حيث يحققون أكبر قدر من الاختلافات: العمل على المنتج.

I'm having trouble understanding some of the decisions and worried how that will affect our teams أواجه مشكلة في فهم بعض القرارات وأخشى كيف سيؤثر ذلك على فرقنا

If you could list them, it would be awesome. إذا كان بإمكانك سردها ، فسيكون ذلك رائعًا.

Others have voiced their concern about move to styled components أعرب آخرون عن قلقهم بشأن الانتقال إلى المكونات المصممة

What's your concern with such a shift? ما هو قلقك من هذا التحول؟ Our objective on the styling side has a couple of layer: يتمثل هدفنا في جانب التصميم في طبقتين:

1. Unstyled component, expose the same existing components but without any styles. مكون غير منمق ، يعرض نفس المكونات الموجودة ولكن بدون أي أنماط. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). احتفظ بنفس واجهة برمجة التطبيقات classes (ظهرت لأول مرة في jQuery-UI) ، وقم بتوفير القيم الافتراضية المشفرة لكل فئة من الفئات (أسماء الفئات العامة). The objective behind this shift answer to a couple of incentives. الهدف من هذا التحول هو الإجابة على اثنين من الحوافز. First, it's to dismiss a fear our users have, same to CRA eject mode, you won't use it but it feels safe to be present. أولاً ، إنه لرفض الخوف الذي يشعر به مستخدمونا ، تمامًا مثل وضع إخراج CRA ، فلن تستخدمه ولكن من الآمن أن تكون موجودًا. Second, it's required to be able to build the paid design tool. ثانيًا ، يجب أن تكون قادرًا على إنشاء أداة التصميم المدفوعة. Third, it's required for the next layer ثالثًا ، إنه مطلوب للطبقة التالية
2. Multiple style engines. محركات متعددة الأنماط. The community is fragmented between different styling approaches. المجتمع مجزأ بين أساليب التصميم المختلفة. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. حسب الشهرة: المكونات المصممة ، CSS العادي ، وحدات CSS ، العاطفة ، JSS ، الفئات الأولى للمرافق. It still feels like we didn't find the holy grail for styling. ما زلنا نشعر أننا لم نجد الكأس المقدسة للتصميم. And until we do, better not bet too much on any styling solution. وحتى نقوم بذلك ، من الأفضل ألا تراهن كثيرًا على أي حل تصفيف. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. لذلك ، يكون للمكونات المصممة الإعداد الافتراضي ، ولكن تسمح للمطورين بتبديل المحرك ، والبقاء على JSS إذا كانوا سعداء أيضًا.
3. Baseline theme. موضوع الأساس. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. شيء أقل إبداءً للرأي من سمة تصميم المواد الافتراضية الحالية ، ولكن باستخدام نفس مواصفات السمة.
4. A couple of different themes on top of the baseline. زوجان من الموضوعات المختلفة أعلى خط الأساس. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). واحد لصفحات التسويق ، وواحد للسوق الصينية (قريب من Gmail المكافئ للصين).

I'll focus on the other one for me - the Box component. سأركز على العنصر الآخر بالنسبة لي - مكون Box.

Yeah, I can hear you! نعم ، يمكنني سماعك! I have been working with @gregberge in the past. لقد كنت أعمل مع gregberge في الماضي. At some point, we have considered hiding all the className props on @doctolib 's design system. في مرحلة ما ، فكرنا في إخفاء جميع دعائم className في نظام تصميمdoctolib. The interesting thought is that you can gain features (properties) in exchange of more constraints. الفكرة المثيرة للاهتمام هي أنه يمكنك اكتساب ميزات (خصائص) مقابل المزيد من القيود.

I wouldn't worry too much about this one. لن أقلق كثيرًا بشأن هذا. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. يمكن حل هذا من خلال خيار عام للحد من الوصول إلى ميزات "النظام" أو قاعدة eslint.

The abbreviation on the Box component is confusing. الاختصار الموجود في مكون Box محير. Code is being read more than being written, so it's important to keep clear what the code is meaning. تتم قراءة الكود أكثر من مجرد كتابته ، لذلك من المهم أن تكون واضحًا ما تعنيه الكود. Last day I found "Box py={2}" in our codebase and I'm totally confused. في اليوم الماضي وجدت "Box py = {2}" في قاعدة الشفرة الخاصة بنا وأنا في حيرة من أمري. After a search I figured out that means "paddingY". بعد البحث اكتشفت أن هذا يعني "الحشو". Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) لا ينبغي تشجيع هذه الاختصارات خاصةً الخصائص التي لا تنتمي إلى css (يمكنني تخمين أن pt تعني padding-top ولكن ليس لـ py)

@oliviertassinari Thanks for your patience oliviertassinari شكرًا على سعة صدرك

I'm having trouble understanding some of the decisions and worried how that will affect our teams أواجه مشكلة في فهم بعض القرارات وأخشى كيف سيؤثر ذلك على فرقنا

If you could list them, it would be awesome. إذا كان بإمكانك سردها ، فسيكون ذلك رائعًا.

I wouldn't want this to turn into a litany of things I disagree with, because ultimately you're the guys who maintain this library and our view of what makes sense will be shaped by our own needs which might and likely don't always align, and that's fine. لا أريد أن يتحول هذا إلى مجموعة من الأشياء التي لا أتفق معها ، لأنك في النهاية الأشخاص الذين يحتفظون بهذه المكتبة ، وسوف تتشكل نظرتنا لما هو منطقي من خلال احتياجاتنا الخاصة التي قد لا تكون دائمًا على الأرجح. محاذاة ، ولا بأس بذلك. I'm not against introducing the means of using other styling solutions - in fact I think it's great as it will bring more users who were holding off because of their dislike for JSS, but there's also us - the already existing users of your library who are sold on your solution, and if possible, would like to avoid massive refactor. أنا لست ضد تقديم وسائل استخدام حلول التصميم الأخرى - في الحقيقة أعتقد أنه أمر رائع لأنه سيجلب المزيد من المستخدمين الذين توقفوا عن العمل بسبب كرههم لـ JSS ، ولكن هناك أيضًا نحن - المستخدمون الحاليون لمكتبتك الذين تباع على الحل الخاص بك ، وإذا أمكن ، ترغب في تجنب إعادة البناء الضخمة.

Even if you decide that "we still provide support for JSS", refactoring all demos and your components to styled components will force the teams using JSS to migrate to styled components. حتى إذا قررت "أننا ما زلنا نقدم الدعم لـ JSS" ، فإن إعادة هيكلة جميع العروض التوضيحية ومكوناتك إلى مكونات مصممة ستجبر الفرق التي تستخدم JSS على الانتقال إلى المكونات المصممة. "Why are we still using X, when MUI team moved to Y?" "لماذا ما زلنا نستخدم X ، عندما انتقل فريق MUI إلى Y؟" - will be one of the many questions in light of which it would be really hard not to agree with needing to make that migration sooner or later. - سيكون أحد الأسئلة العديدة التي سيكون من الصعب حقًا عدم الموافقة على الحاجة إلى إجراء هذه الهجرة عاجلاً أم آجلاً.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. يمكنني بالتأكيد أن أتعاطف مع الرغبة في الوصول إلى جمهور أوسع باستخدام حل تصفيف أكثر شيوعًا. However, I think it's worth considering that "popular" is not always "best" and that a move to a different tech needs onsideration not only of advantages and disadvantages of both solution, but the context in which we're making the decision. ومع ذلك ، أعتقد أنه من الجدير النظر في أن "الشعبية" ليست دائمًا "الأفضل" وأن الانتقال إلى تقنية مختلفة يحتاج إلى مناقشة ليس فقط لمزايا وعيوب كلا الحلين ، ولكن أيضًا في السياق الذي نتخذ فيه القرار.

Starting fresh, looking merely at advantages of X over Y makes sense, but working on an already existing system we also need to consider the cost of switching over and domino effects this bring on downstream teams. البدء من جديد ، والنظر فقط إلى مزايا X على Y أمر منطقي ، ولكن العمل على نظام موجود بالفعل نحتاج أيضًا إلى النظر في تكلفة التحويل وتأثيرات الدومينو التي تجلب الفرق النهائية. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. لكي يكون هذا التحول منطقيًا ، يجب على مزايا الحل الآخر زيادة تكلفة الهجرة. It seems that for your team, that cost benefit analysis rules in favor of styled components, but from what I can tell looking at reactions at posts talking about styled components in your repo, your user base is far from the same conclusion. يبدو أنه بالنسبة لفريقك ، قواعد تحليل التكلفة والمزايا لصالح المكونات المصممة ، ولكن مما يمكنني قوله بالنظر إلى ردود الفعل في المنشورات التي تتحدث عن المكونات المصممة في الريبو الخاص بك ، فإن قاعدة المستخدمين الخاصة بك بعيدة عن نفس الاستنتاج.

Like you said, your aim is to open up MUI to more styling solutions. كما قلت ، هدفك هو فتح MUI لمزيد من حلول التصميم. To provide good support for those solutions, there would need to be good documentation, examples and smooth integration layer - otherwise developers would find it hard to translate what they see in demos into what their styling solution of choice needs. لتقديم دعم جيد لتلك الحلول ، يجب أن تكون هناك وثائق جيدة وأمثلة وطبقة تكامل سلسة - وإلا سيجد المطورون صعوبة في ترجمة ما يرونه في العروض التوضيحية إلى ما يحتاجه حل التصميم الذي يختارونه. I'm just not sure if you really need to migrate to styled components to achieve the goals. لست متأكدًا مما إذا كنت حقًا بحاجة إلى الانتقال إلى المكونات المصممة لتحقيق الأهداف. Seems like your solution is also perfectly capable, if not more so than others, to build the design tool you're after since you already use actual JS object for all the styles. يبدو أن الحل الخاص بك قادر تمامًا أيضًا ، إن لم يكن أكثر من غيره ، على إنشاء أداة التصميم التي تبحث عنها نظرًا لأنك تستخدم بالفعل كائن JS الفعلي لجميع الأنماط.

One question I have, does this mean that the core of Mui would still use jss, and this allows for a better way to use styled components on top of that? لدي سؤال واحد ، هل هذا يعني أن جوهر Mui سيظل يستخدم jss ، وهذا يتيح طريقة أفضل لاستخدام المكونات المصممة فوق ذلك؟ Or would there be a way to say the core is also styled? أم أنه سيكون هناك طريقة للقول أن اللب مصمم أيضًا؟ I just think it would add a lot of bloat if you have two css in js solutions. أعتقد أنه سيضيف الكثير من سخام إذا كان لديك اثنين من حلول css في حل js.

How would theming work if using styled-components? كيف سيعمل التصميم في حالة استخدام المكونات المصممة؟ I used to use helpers in the CSS portion, and it was really messy. اعتدت على استخدام المساعدين في جزء CSS ، وكان الأمر فوضويًا حقًا. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. بالنسبة لي ، فإن طريقة تطبيق دعائم السمة في كائن JS هي أنظف كثيرًا مما هي عليه في سلسلة مقولبة.

For me (scientific backend programmer by origin), MUI styles bring beautiful, calming, predictable, parameterisable logic to the mental, crazy, bonkers-rules why-the-hell tearing-hair-out world of CSS. بالنسبة لي (مبرمج الخلفية العلمية حسب الأصل) ، تجلب أنماط MUI منطقًا جميلًا ومهدئًا ويمكن التنبؤ به وقابل للمعايير إلى عالم CSS العقلي والجنوني وقواعد bonkers-why-the-hell-shear-out of CSS.

The styles library (and its tight integration with the theme) is the main reason I mandate use of MUI over any other components library in the two organisations I oversee tech for - it takes all the css agony away! مكتبة الأنماط (وتكاملها الوثيق مع الموضوع) هي السبب الرئيسي الذي يجعلني أصرح باستخدام MUI على أي مكتبة مكونات أخرى في المنظمتين اللتين أشرف على التكنولوجيا من أجلهما - فهي تزيل كل معاناة css بعيدًا! At first, all the developers I work with are like "what the hell's going on? Where's the css? Just give me css!!" في البداية ، كل المطورين الذين أعمل معهم هم مثل "ما الذي يحدث بحق الجحيم؟ أين ملف css؟ فقط أعطني css !!" and then they're like "Ohhhh. riiight. Got it. Magic." ومن ثم فإنهم مثل "Ohhhh.

In the longer term I think the current approach is going to become ever more powerful as the world moves to low/no code solutions (eg like sketch or figma, but outputting an actual routed app and set of components rather than a set of wireframes) - having styles expressed as an object unlocks the ability to introspect that - and create more new features in such an environment (like provision of a schema enabling direct use of MUI components within a CMS, or generation of 'theme from this' and hundreds I haven't thought of yet). على المدى الطويل ، أعتقد أن النهج الحالي سيصبح أكثر قوة من أي وقت مضى حيث ينتقل العالم إلى حلول منخفضة / بدون تعليمات برمجية (على سبيل المثال ، مثل الرسم أو الشكل ، مع إخراج تطبيق موجه فعلي ومجموعة من المكونات بدلاً من مجموعة من الإطارات السلكية) - إن وجود أنماط يتم التعبير عنها ككائن يفتح القدرة على استبطان ذلك - وإنشاء المزيد من الميزات الجديدة في مثل هذه البيئة (مثل توفير مخطط يتيح الاستخدام المباشر لمكونات MUI داخل CMS ، أو إنشاء "سمة من هذا" والمئات أنا لم أفكر بعد).

Moving back to the more raw-css kind of approach of styled-components doesn't preclude that - but it does make a lot of things (particularly parameterisation on the theme) a lot jankier and frustrating to achieve, and still requires much more in-depth knowledge of CSS's technicalities making it less accessible to new programmers and creative types alike. العودة إلى أسلوب Css الأكثر صرامة وهو styled-components لا يمنع ذلك - لكنه يجعل الكثير من الأشياء (خاصة تحديد المعلمات على السمة) أكثر تعقيدًا وإحباطًا لتحقيقها ، ولا يزال يتطلب معرفة أكثر عمقًا بتقنيات CSS مما يجعلها أقل وصولًا للمبرمجين الجدد والأنواع الإبداعية على حد سواء.

On the evolution of the state-of-the-art, I think styled-components has become really popular because it's a great step in the right direction from where the world was (which is why it became popular). فيما يتعلق بتطور أحدث التقنيات ، أعتقد أن styled-components أصبح مشهورًا حقًا لأنه خطوة رائعة في الاتجاه الصحيح من حيث كان العالم (ولهذا السبب أصبح شائعًا). But the existing MUI styles system is the next step on from that; لكن نظام أنماط MUI الحالي هو الخطوة التالية بعد ذلك ؛ not an incorrect side-step. ليس خطوة جانبية غير صحيحة. Once everyone's migrated to styled-components then the question will be "wait: why on earth are we doing this with these weird raw strings in our components...?" بمجرد انتقال الجميع إلى المكونات المصممة ، فسيكون السؤال "انتظر: لماذا نفعل هذا بحق بهذه السلاسل الأولية الغريبة في مكوناتنا ...؟"

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) ربما أكون مخطئًا تمامًا ، ولكن بالنسبة لي البالغ 0.02 دولارًا ، أتوسل إليك أن تستمر في الدورة للحصول على إصدار رئيسي آخر على الأقل :)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. thclark يبدو أن اهتمامك الرئيسي هو بناء جملة سلسلة قالب CSS مقابل واجهة برمجة تطبيقات كائن نمط جافا سكريبت. Is this accurate? هل هذا دقيق؟ It also seems to be the concern with most of the other comments of the thread. يبدو أيضًا أنه مصدر قلق لمعظم التعليقات الأخرى للموضوع.

Styled-components and emotions support both APIs. المكونات الأنيقة والعواطف تدعم كلا من واجهات برمجة التطبيقات. This wasn't the main purpose of the issue. لم يكن هذا هو الغرض الرئيسي من المشكلة. The objective of this issue was to anticipate the migration to a different styling solution. كان الهدف من هذه المشكلة توقع الترحيل إلى حل تصميم مختلف. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". ومع ذلك ، فإننا لا نتحرك أبدًا مع "استخدام المكونات المصممة في جميع العروض التوضيحية حتى لو لم نقم بنقل المحرك الأساسي". We have opted for keeping both synchronized. لقد اخترنا الحفاظ على كلاهما متزامن.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). في هذه المرحلة ، لا يضيف إبقاء المشكلة مفتوحة الكثير من القيمة خارج إثارة مناقشات مثل هذه :). We have to migrate the demos anyway for #22342. يتعين علينا ترحيل العروض التوضيحية على أي حال لـ # 22342.

I personally prefer the JavaScript API over the CSS string one because: أنا شخصياً أفضل واجهة برمجة تطبيقات JavaScript على سلسلة CSS الأولى للأسباب التالية:

• It doesn't ask for another linter/formater. انها لا تطلب لينتر / فورماتر آخر.
• I'm used to it. أنا معتاد على ذلك.
• It plays nicely with TypeScript. إنه يلعب بشكل جيد مع TypeScript.

However, it's unclear what the community, at large, will enjoy using most. ومع ذلك ، ليس من الواضح ما الذي سيستمتع به المجتمع بشكل عام. CSS template has its advantages too. قالب CSS له مزاياه أيضًا. It's easier to copy & paste code between the browser and the code. من الأسهل نسخ الشفرة ولصقها بين المتصفح والكود. A lot more people (overall: designers, developers, etc.) are familiar with the approach. كثير من الناس (بشكل عام: المصممون والمطورون ، وما إلى ذلك) على دراية بهذا النهج.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. وتجدر الإشارة إلى أنني أعتقد أنه يجب علينا استخدام أدوات الأنماط قدر الإمكان في العروض التوضيحية مع الإصدار 5.

@mnajdova any thoughts on the matter? mnajdova أي خواطر في الموضوع؟ Maybe it's worth asking the community on a poll. ربما يستحق الأمر سؤال المجتمع في استطلاع.

@oliviertassinari succinctly put, as usual. oliviertassinari ضع بإيجاز ، كالعادة. Yes, my main concern is retaining the Javascript API. نعم ، شاغلي الرئيسي هو الاحتفاظ بواجهة برمجة تطبيقات جافا سكريبت. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. بصراحة ، لم أكن أدرك أن المكونات المصممة احتفظت بذلك ، حيث يبدو أن جميع الأمثلة التي صادفتها عبارة عن قالب css.

That perhaps moots most of my points above. ربما هذا هو ما يوضح معظم نقاطي أعلاه. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. ومع ذلك ، يسعدني أنك لم تتحرك - وشكرًا لجهودك وجهود الفريق المستمرة هنا. I've built things I never could have without MUI existing. لقد قمت ببناء أشياء لم يكن بإمكاني امتلاكها بدون وجود MUI.

This issue is being resolved in v5. يتم حل هذه المشكلة في الإصدار الخامس. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. لقد قمنا بترحيل وثائق شريط التمرير إلى النهج الجديد: https://next.material-ui.com/components/slider-styled/. We use the sx prop anytime simple CSS are necessary then use the styled API for more heavy customizations. نستخدم sx prop في أي وقت يكون CSS البسيط ضروريًا ، ثم استخدم styled API لمزيد من التخصيصات الثقيلة. I believe the previous concern raised have been handled, if not, please comment :). أعتقد أنه قد تم التعامل مع المخاوف السابقة التي أثيرت ، إذا لم يكن الأمر كذلك ، يرجى التعليق :).