Material-ui: [الأساسية] يجب أن يكون هناك حل تصفيف أكثر تطوراً.

تم إنشاؤها على ٢٢ أبريل ٢٠١٦  ·  100تعليقات  ·  مصدر: mui-org/material-ui

@ callemall / material-ui يرجى ترك بعض المدخلات هنا عندما تستطيع 👍

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

مما أفهمه ، الإجماع العام هو أننا نريد حلًا بأسلوب JS لديه القدرة على كتابة أنماط إلى ورقة أنماط فعلية في DOM.

فيما يلي بعض الحلول التي تم الحفاظ عليها والتي تقوم بذلك:
https://github.com/rofrischmann/react-look
https://github.com/Khan/aphrodite
https://github.com/jsstyles/react-jss

فيما يلي بعض النقاط التي يجب مراعاتها عند تنفيذ الحل الجديد (IMO):

  1. هل يتوافق مع أهدافنا؟ (تم لمسه قليلاً أعلاه)
  2. تنفيذ استعلامات الوسائط التي تتبع نقاط التوقف عالية المستوى المفصلة في المواصفات التي يمكن استخدامها بسهولة في المكونات التي تحتوي على مزيج من ورقة الأنماط (أو أيًا كان التطبيق الذي نستخدمه يطلق عليها). إذا كنا نقوم بإصلاح تطبيق النمط ، فهذه هي اللحظة المناسبة لزرع البذور للحصول على دعم واجهة مستخدم أفضل استجابة في هذه المكتبة. سيكون من الأفضل إذا كانت هذه الأدوات متوفرة في userland أيضًا 👍
  3. هل يجب علينا إنشاء مكونات مساعد التخطيط و / أو mixins للمساعدة في توحيد تطبيقات تخطيط Flexbox عبر lib؟
  4. هل يحتاج أسلوبهم إلى التغيير لتحقيق أقصى استفادة من الحل الجديد؟ في حين أن التخصيص هو أحد مكونات التصميم المتسق ، يجب أن ننظر أيضًا في إنشاء متغيرات للعديد من أنماط المواد الشائعة مثل خطوط المفاتيح العامة / أحجام الخطوط / المسافات / الهوامش / إلخ. أوصي بشدة بتحسين تناسق الطباعة لدينا من خلال إنشاء أنماط كتابة محددة مسبقًا تتطابق مع دليل طباعة واجهة المستخدم المادية ، ومحاولة مطابقة عناصر المكونات مثل العناوين وما إلى ذلك على أفضل وجه ممكن مع متغيرات نمط الكتابة العامة هذه بشكل افتراضي.
  5. إذا كنت تستخدم مكتبة بحجم react-look ، فحاول أن ترى كيف يمكننا استيراد الوحدات بأدنى حجم بناء. سيكون من الرائع لو تمكنا من تقليل التأثير على حجم البناء. أدركت أن 9 كيلوبايت من ذلك هو https://github.com/rofrischmann/inline-style-prefixer الذي نستخدمه بالفعل ... 😄
discussion performance umbrella

التعليق الأكثر فائدة

هل تم الانتهاء من حل التصميم؟

ال 100 كومينتر

بعض الأسئلة الأخرى:
6) هل سنزيل أو نهدف إلى إزالة عناصر xxxxStyle ونجعل المستخدمين يمررون xxxClassName لتجاوز الأنماط؟ أم أنها ستكون مجانية؟
7) هل نسمح بتجاوز الأنماط عبر CSS وتبسيط واجهات المكونات لدينا. لذا إذا أردت تجاوز menuItemStyle في IconMenu ، فهل أقوم بإنشاء تجاوز للنوع style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ؟

chrismcv رأيي الشخصي هو أننا نحتاج بالتأكيد إلى الاستفادة من الحل لإزالة هذه الدعائم فائقة التحديد التي نراها مقترحة: [TextField] إضافة floatingLabelFocusStyle prop # 4043

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

أرى العديد من المشكلات مثل "كيفية تنسيق XXXX" ، "لا يمكن تنسيق XXX داخل YYYY" ، "أضف somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop إلى XXX من فضلك"

chrismcv في 6. بخصوص xxxxStyle props مقابل classNames ، ما رأيك؟ مع بعض مكوناتنا ، ستحتاج إلى أن تكون قادرًا على الوصول بطريقة أو بأخرى (لحسن الحظ ، سنتمكن من استخدام :hover وما إلى ذلك!).

chrismcv أعتقد أن عناصر xxxxStyle يجب أن تنتقل إلى خاصية style ، وليس كائن النمط className .

nathanmarks شكرًا على بدء المحادثة. هذه بالتأكيد إحدى المشكلات الرئيسية التي نحتاج إلى معالجتها للإصدارات القادمة 💯.

خارج قضايا الأداء

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

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

أنا ألعب مع اثنين من حلول أسلوب JS في الوقت الحالي. من المثير للاهتمام ولكن من الواضح أنه ما زالت "الأيام الأولى" إذا جاز التعبير.

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

يبدو كما لو أنه مع libs نمط JS ، للحصول على أقصى أداء ، يجب عليك استخدام طريقة StyleSheet.create() مرة واحدة والحصول على مفاتيح ("فئات" css) في هذا الكائن للوظائف / الحالات مثل open={true} بدلاً من البناء الحرفي لكائن النمط ديناميكيًا بخصائص شرطية وتمريره إلى طريقة مصنع ورقة الأنماط لكل عرض لكل نمط.

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

هممم ... تركت تعليقًا هنا أمس (الأحد). هل تم حذفه؟

@ rvbyron أتذكرها بوضوح. أنا بالتأكيد لم أحذفه بالرغم من ذلك.

rvbyron أنا أتذكره أيضًا. ليس لدي أي فكرة عما حدث.

rvbyron - كان

حسنًا ، أود أن أرى عددًا من الأشياء تحدث.

أ) نعم ، بكل الوسائل تخلص من استخدام متغير نمط العنصر على مستوى المكتبة. يجب تحديد جميع المكونات باستخدام className. يؤدي استخدام المكونات إلى تدمير جميع عروض CSS القوية.
ب) سيكون من الرائع أن يتم إرفاق classNames تلقائيًا بالعنصر الجذر لكل مكون (على سبيل المثال ، سيكون للمكون RaisedButton ضمنيًا className = "mui-lift-button" على العنصر الجذر للمكون). سيجعل التصميم أسهل كثيرًا. يمكن أن يكون حتى شكلي.
ج) احصل على سمة من ملفات muiTheme.js تمامًا. سيكون ملف muiTheme.SCSS الخاص بالسمات أفضل بكثير من حيث أنه سيسمح بتطبيق أي خصائص يختارها منشئ القالب وليس فقط تلك التي يسمح بها المكون تحديدًا. بالطبع قد يتطلب هذا أن يتم تنفيذ B وتنشيطه.
د) يبدو أن React-look هو حل وسط جيد لأنه يحول كائنات JSON التي تحتوي على خصائص النمط إلى classNames. يسهل تجاوز الأمور. ومع ذلك ، كما قلت في C أعلاه ، ما زلت أرغب في إنشاء قاعدة السمات في SCSS. أنا منفتح جدًا على حزمة مساعدة CSS التي يجب استخدامها. لكنني سأبقى بعيدًا عن أي شيء يريد استخدام معلمة نمط العنصر على معلمة className.

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

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

من المهم مراعاة جميع الزوايا هنا.

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

شيء واحد أدركته حول react-look هو أنك تحتاج إلى لف جميع مكوناتك في render() ، ويخزن super.render() في const وينفذ عمليات دقة النمط بهذه الطريقة. تتطلب بعض الحلول الأخرى مثل Khan / aphrodite فقط styles.xxxx من Stylesheet.create() داخل className={} .

يبدو لي أن اختطاف الوظيفة render() لـ css مُبالغ فيه. يخبرني أن React المدمج في الأدوات / الدعم لهذا النوع من وظائف الأنماط المدمجة بعمق ليس موجودًا ، لست متأكدًا من فكرة أن CSS المساعد HoC يتحكم في عرض جميع مكوناتنا.

أفكار؟

مرحبًا فريق Material-UI!

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

  • تأتي بعض الأنماط من الإعدادات الافتراضية للمكون (والتي يتم تعيينها في مجلد العقدة ولا يمكن لمسها)
  • يأتي بعضها من معلمات المكون (على سبيل المثال ، تحدد معلمة مكون الصورة الرمزية size={40} العرض والارتفاع وارتفاع السطر إلى 40px )
  • عندما يتم تخصيص الإعدادات الافتراضية للمكون (ألوان السمة) ، تأتي الأنماط من مكان تخصيص السمة
  • عندما يتم تعديل بقية أنماط المكونات ، تأتي الأنماط من تطبيق مكون ، وهو جزء آخر في الكود

عندما يتعلق الأمر بضبط الأنماط ، فهناك ما لا يقل عن 4 مواقع مختلفة (👆) للنظر فيها ، مما يجعل من الصعب التحقيق في المشكلات.

عندما تأتي الأنماط مع css ، سترى المحدد وتعرف بالضبط مكان الإصلاح. مع الأنماط المضمنة ، يستغرق الأمر وقتًا لفهم مصدر الخاصية المعينة ، وأين وما يجب تعديله. وإذا قام المطور بتعديله في المكان الخطأ (دعنا نقول في منطقة styles بدلاً من size ، حيث لا يوجد شيء يشير في الواقع إلى أن size هو النمط) فسيؤثر ذلك على أداء كتلة width=height=line-height=40px بالكامل ، أو سيؤدي إلى إعادة كتابة width/height/line-height مما يجعل المعلمة size غير قابلة للتطبيق.

بالإضافة إلى ذلك ، فإنه يجعل من الصعب أيضًا التحقق من العناصر الرئيسية التي لها خصائص معينة مطبقة ، لأن كل ما يمكنك رؤيته في المفتش هو element.style .
image

عندما تأتي الأنماط مع محددات (أسماء الفئات) فإنها تعطي تحكمًا أكبر في بنية الأنماط أكثر من الأنماط المضمنة.

تحديث: نسيت ذكر الاقتراح (الذي يدور حوله هذا الموضوع):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

ستحافظ هذه البنية على المكون في النطاق ، ولكنها ستمنح مزيدًا من التحكم في التصميم. وستساعد اصطلاحات BEM className على تجنب التداخل غير الضروري:

.mui-component {}
.mui-component__child {}

والذي سيساعد بشكل عام في تنفيذ أنماط واجهة المستخدم المادية وتعديلها والحفاظ عليها.

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

شكرًا على العثور على البريد الإلكتروني ووضعه في التعليق!

أفضل نهج السلوك في العالمين؟

ماذا عن مفهوم "السلوك" لاستيراد تقنية التصميم التي تناسب احتياجاتك على أفضل وجه. يمكن استخدام استيراد "StyleTheme" أو "ClassTheme" لتحديد السلوك. يمكن أن يشير StyleTheme إلى واجهة المستخدم المادية لكائن muiTheme الموجودة اليوم ويجعل مطوري التصميم المركزي للمكون سعداء. أو ، ClassTheme التي قد تستخدم ملف SCSS تم إنشاؤه من كائن muiTheme.js (متزامن) مما يجعل مطوري CSS المركزيين سعداء. هذا يعني أن جميع المكونات ستحتاج بعد ذلك إلى استيعاب {... theme.ComponentName} في عناصر العرض.

لتقديم مثال مبسط للغاية ، سيكون لمكوِّن RoundButton طريقة العرض مثل:

render() {
    return (<button {...theme.RoundButton} />);
}

بالنسبة لسلوك StyleTheme ، قد يحتوي theme.RoundButton على:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

بالنسبة لسلوك ClassTheme ، قد يحتوي theme.RoundButton على:

{ 
    className: 'mui-round-button'
}

يمكن استرجاع مزيج من الاثنين كسلوك ClassStyleTheme ، theme.RoundButton سيحتوي على كلا:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

سيتم إنشاء ملف mui-theme.scss من ملف muiTheme.js ويعكس في SCSS الخصائص الدقيقة التي يحتوي عليها ملف JS. سيتم تحويل غلاف الجمل لأسماء JS إلى المزيد من أسماء الفئات القياسية:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

أي تخصيص CSS لمكونات MUI سيكون ببساطة فئات متطابقة يتم تحميلها بعد تحميل ملف mui-theme.scss ، وبالتالي تجاوز خصائص سمة mui.

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

أعتقد أن استخدام شيء من هذا القبيل scss (+ حدات المغلق لمساحة الاسم / التجزئة) لديها الكثير من الفوائد. هل هذا شيء تعارضه 100٪؟ ربما أكون متحيزًا بعض الشيء لأن هذا ما اعتدت استخدامه في العمل ، لكن الكثير من الناس في نفس القارب.

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

أعتقد أن لدينا مخاوف مختلفة بشأن هذا.

  1. مكان وضع الأنماط الثابتة (سهل ، يمكن لملف css القيام به)
  2. كيفية تبديل بعض الأنماط اعتمادًا على الإدخال (تبديل اسم الفئة)
  3. كيفية تطبيق الأنماط الديناميكية (يمكن للأنماط المضمنة القيام بذلك)

كل شيء يبدو جيدًا عند كتابة تطبيق ، فلا يحتاج أي شخص خارج الكود إلى تغيير أي شيء.

لكن في المكتبات تختلف الأشياء ، كل المخاوف المذكورة أعلاه موجودة ، بالإضافة إلى ما يلي:

  1. كيفية تمكين المستخدمين من تخصيص الأنماط الثابتة؟
  2. كيفية تنفيذ السمة بطريقة يسهل التبديل والتخصيص والعزل (موضوع مختلف للشجرة الفرعية)؟
  3. كيف نتجنب تلويث مساحة الأسماء العالمية حتى نتمكن من اللعب بشكل جيد مع الآخرين؟
  4. كيف يمكن للمستخدمين تجاوز الأنماط الديناميكية المضمنة؟
  5. محولات! (rtl ، بادئة ، إلخ)

ما لدينا الآن يعالج بطريقة ما كل تلك المخاوف مع هذه التحذيرات:

  1. أداء!
  2. يصعب تخصيص المكونات المتداخلة بعمق ، كما قال nathanmarks : somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
  3. لا يمكننا الاستفادة من قوة بعض ميزات css.

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

في رأيي المتواضع ، أعتقد أن CSS وما يجمعها ليس جزءًا من المستقبل. أعتقد أننا نتفق جميعًا على أن الأساليب المضمنة جعلت حياتنا أسهل كثيرًا. بصراحة ، القيد الوحيد الذي أراه مع الأنماط المضمنة هو :hover !

يمكننا حل هذه المشكلات من خلال القيام ببعض التصميم.

  1. حفظ كائن الأنماط في الذاكرة ، بالنسبة للمكونات التي لها حالة ، يمكننا تفكيك الحالة ووضعها في مكون أصغر بحيث يمكن حفظ كائن النمط الموجود فيه استنادًا إلى العناصر التي تم تمريرها وهي حالة المكون الأعلى. هذا قابل للحل بسهولة!
  2. تحطيمهم! لماذا لدينا ListItem مع الكثير من الوظائف الصغيرة المضمنة فيه؟ يمكننا تقسيمه وجعله قابلاً للتكوين ، ثم لا نضطر إلى إضافة أشياء شائنة مثل somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
  3. مه! كل ما نحصل عليه من الأداء هو :hover أعتقد أنه يمكننا التعايش مع ذلك حتى تفعل المتصفحات أو تتفاعل شيئًا حيال ذلك.

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

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

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

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

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

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

أوافق على محاولة تقليل مقدار التغيير والاضطرار إلى إعادة حل المشكلات التي تم حلها بالفعل. هناك هدفان مهمان هنا في ذهني:

  1. أداء
  2. تجربة المطور (تساعد ملفات أسلوب JS كثيرًا هنا من خلال تمكين المطورين من استخدام الفئات في تطبيقاتهم بسهولة)

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

ملاحظة عشوائية أخرى - سيكون أمرًا رائعًا إذا كان لدينا طريقة آلية لفرض بعض قواعد التعليمات البرمجية وأنماط التصميم لـ inline / jsstyle / أيًا كان عبر lib.

هل هذا شيء تعارضه 100٪؟

nathanmarks أنا لست 100٪ أعارض استخدام SCSS (_أنا أستخدمها في العمل_). لكن من وجهة نظري ، إنه طريق مسدود .
تتمثل إحدى المزايا الرئيسية لـ React في تجريد خصوصية عرض المتصفحات: DOM.
بقدر ما أعرف ، فإن الهدف طويل المدى لفريق React Core هو توفير واجهة برمجة تطبيقات لكتابة مكون عبر الأنظمة الأساسية. في الواقع ، إنهم يجرون حاليًا تجارب في هذا الاتجاه. لن تساعد SCSS.

أتفق تمامًا معalitaheri. يمكننا البدء بهاتين الخطوتين:

  • استخدم النمط getStyles كل مكان حتى نتمكن من الترحيل بسهولة أكبر لاحقًا.
    هل سنتمكن من استخدام كود كود؟ من تعرف.
  • تقسيم كل مكون على النحو الذي اقترحهalitaheri.

oliviertassinari أتفق مع النتيجة المسدودة - إنه ليس المستقبل. لقد طرحته إلى حد كبير لتحفيز المحادثة حول كيفية جعل أنماط JS تعمل من أجلنا. كنت أعرف أن بعض الأشخاص هنا لديهم بعض الأفكار الجيدة حول المشكلات 😄 أتمنى أن يكون FB قليلًا جدًا إلى جانب تجاربهم!

أعتقد في الواقع أن النمط getStyles() الذي نستخدمه حاليًا به مشاكله الخاصة. أجرينا محادثة جيدة جدًا اليوم مع

في الأسبوع القادم سأكون في إجازة وسأقوم بتجربة حل لمشاكلنا الحالية مع الحفاظ على جميع أنماط JS.

ما عليك سوى قراءة هذا المنشور عن الدروس المستفادة في React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) وكان أحد العروض التقديمية حول حلول التصميم في React: http : //slides.com/kof/javascript-style-sheets#/ عرض تقديمي في الوقت المناسب لهذه المناقشة.

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

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

شكرا لتقاسم هذا العرض!

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

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

بدلاً من ذلك ، يمكننا دائمًا إنشاء ارتباطات تفاعلية خاصة بنا مقابل jss يمكن أن تعمل مع mixout .

قال مؤلف lib أيضًا هذا ، وهو ما يتماشى مع أفكاري الخاصة حول هذه المسألة 👍:

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

nathanmarks التنفيذ صغير جدًا وسهل الاختلاط: ابتسامة:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
أعتقد أن هذه المكتبة يمكن أن تساعدنا في: +1:

alitaheri نعم أوافق!

أقوم بتجربة بعض الارتباطات المخصصة مقابل jss أيضًا - هناك بعض المشكلات / القيود التي أرغب في محاولة معالجتها. (على الرغم من أن واحد قد يتطلب العمل على lib الأساسية)

يبدو أن هناك شعورًا سائدًا في مجتمع React بأن تصميم JavaScript هو الحل الأفضل. هذا الشعور جيد ، أنا لست على خلاف مع أولئك الذين لديهم. ومع ذلك ، فإن الطريقة التي يتم بها تنفيذ تصميم JavaScript هي دائمًا تقريبًا بغض النظر عن مطور CSS. يفضل التنفيذ في كثير من الأحيان style=/[element property]= على className= ويمنع مطور CSS من القيام بعملهم.

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

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

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

rvbyron أحد الأسباب الرئيسية التي تجعلنا نرغب في تغيير نهجنا الحالي هو تسهيل تخصيص المكونات باستخدام css أيضًا. باستخدام مكتبة مثل jss سيسمح لنا باستخدام ميزات css مع الاستفادة من أنماط js. ونظرًا لأنه يحول هذه الأنماط إلى css ، يمكن تجاوزها بسهولة باستخدام اسم فئة إضافي بدون الاختراق القبيح !important .

alitaheri عظيم أن نسمع! إنني أتطلع حقًا إلى رؤية واجهة المستخدم المادية تستوعب نهجًا قائمًا على className.

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

  • كيف تعتقد أن اصطلاح تسمية اسم الفئة قد يبدو؟
  • هل ستحتوي جميع أسماء الفئات على "mui-" أو بادئة أخرى عليها؟
  • هل سيكون الفصل عبارة عن علامة شرطة لاسم المكون؟
  • هل سيتم تطبيق اسم فئة على العنصر الجذر لكل مكون؟

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

بشكل مثالي:

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

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

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

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

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

wtgtybhertgeghgtwtg نحن نعمل على إيجاد حل يستخدم أوراق أنماط حقيقية بحيث يتم دعم وظائف مثل :hover .

بالنظر إلى أن النقاط الرئيسية قد تم تحديدها (تصميم JSS عبر className و root element classNames) ، هل هناك أي خريطة طريق وجدول زمني لإصدار material-ui v0.16.0؟

rvbyron ليس لدينا جدول زمني موعود به ، ولكن اعتبارًا من الآن ، نهج التصميم والأداء هو تركيزنا الأساسي لإصدار v0.16.0 وهو شيء نعمل عليه بنشاط الآن. من المحتمل أن نستخدم هذه المشكلة في المستقبل القريب للحصول على تعليقات المجتمع بمجرد أن نقرر الاتجاه الصحيح في عدد قليل من المجالات الأخرى من حيث صلته بالداخلية وواجهة برمجة التطبيقات (API) والترحيل وما إلى ذلك.

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

newoga هنا تم استدعاء jss كمستقبل لنظام تصميم واجهة المستخدم المادية. هل هذه خطة ملموسة بما فيه الكفاية بحيث يمكن للآخرين بدء تشغيل jss في مشاريعنا الآن ، تحسبا لإصدار 16.0؟

sorahn ليس بعد

sorahn تم تصميم هذه المشكلة للحصول على تعليقات المجتمع حول ما لا يزال يمثل مشكلة

للتسجيل ، لا يتمثل الهدف من تغيير التصميم هذا في ترحيل الجميع إلى معيار مختلف ، ولكن لتسهيل استخدام مكونات Material-UI وتصميمها بغض النظر عن أسلوب التصميم الذي تستخدمه معها.

TL ؛ دكتور لا! افعل ما هو أفضل لك ، وليس ما يقوله أي شخص آخر :)

nathanmarksnewoga شكرا للتحديث!

نحن نواجه قيود التصميم سريع الاستجابة + العرض من جانب الخادم مع جميع الأنماط المضمنة ، لذلك نحن نبحث في البدائل. لا توجد آراء قوية بشكل خاص حول (ق) وحدات css أو csx أو أي شيء آخر ، لكننا نحب واجهة المستخدم المادية لذلك سيكون من الرائع متابعة ما ستفعله يا رفاق :)

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

أنا حقًا أحب حل JSS + CSX (من منظور مطور _joy_).

فوائد وأداء JSS

على غرار sorahn ، سأكون سعيدًا لاعتماد معيار مادة واجهة المستخدم ، وآمل أن تعمل nathanmarks في هذا الاتجاه على التحقق من صحة هذا النهج. أيضًا ، يبدو أن كلا من مطوري CSX / JSS حريصون على المساعدة في تبني مكتباتهم وتعزيزها.

rosskevin العمل عليها بينما نتحدث - هناك أشياء يجب مراعاتها هنا لم يتم تناولها في أي من الحلول حتى الآن.

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

sorahn سؤال سريع - ماذا تفعل بشأن بادئات البائع مع عرض جانب الخادم؟ هل تقوم فقط بعرض جميع البادئات على الخادم؟ أم أنك تمر على UA؟

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

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

sorahn ستتمكن من فعل ما تريد ، بادئة ، وليس بادئة ، وتمرير all ، وتمرير UA ، وما إلى ذلك

nathanmarks لقد أصدرت للتو [email protected]. التغيير الأكثر أهمية - إنشاء المعرّف القطعي ، هنا مثال على ssr مع التفاعل http://jsstyles.github.io/examples/index.html

مجرد رمي $ 02 الخاص بي هنا ... بينما أحب حقًا فكرة الأنماط المضمنة والأفروديت التي تروق لي ، يبدو الأمر وكأنه سيكون أسهل إذا كانت الأنماط مبنية على تنسيق مكتبة في scss مثل bootstrap 4.

ما أفعله عادةً هو نسخ ملف bootstrap.scss وملف _variables.scss حرفيًا أثناء إنشاء ملف _mixins.scss ... بهذه النسخة تحت ./lib/style ، أقوم بتحديث ملف bootstrap.scss المحلي للإشارة إلى الملف المحلي المتغيرات والمزج ، أثناء استخدام المسار إلى إصدارات node_modules لكل شيء آخر ...

ثم أقوم بإعداد تهيئة حزمة الويب الخاصة بي لجعل ./lib/style جزءًا من مسار البحث لتكوين sassLoader.

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

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

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

هل تم الانتهاء من حل التصميم؟

هل هناك أي تحديثات على هذا؟

نعم ، يستخدم الفرع next jss

لقد صادفت للتو هذا المشروع وكنت متحمسًا للغاية بشأنه لأنه بدا رائعًا ، جعلت صفحة المثال من السهل جدًا معرفة كيفية استخدام المكونات وبدا أنها مستخدمة على نطاق واسع ؛ ومع ذلك ، أشعر بخيبة أمل كبيرة من السلالم المضمنة ويسعدني أن أراكم يبتعدون عنها. أحد الأشياء التي أود الإشارة إليها هو أن أي شيء يتعلق بالتخطيط خارج هذه المكونات يجب إزالته والسماح بتصميم المكون الرئيسي للتعامل مع ذلك. لا ينبغي أن يحتوي مكون المستوى الأدنى على هوامش أو حشوة بأي طريقة من شأنها دفع العناصر المحيطة بعيدًا ... خاصة أنه من المستحيل تجاوزه دون العبث بالخطوات المضمنة مما يعني أنني بحاجة إلى التنقيب ومعرفة كيفية القيام بذلك ذلك. لم أتعمق أكثر في هذا المشروع لأنني للأسف أجده غير قابل للاستخدام. لقد قرأت بالتأكيد الكثير من المناقشات حول التصميم المضمّن مقابل التصميم المغلق. على أي حال ، لقد فقدتني في TextField. يوجد هامش في الأعلى 14 بكسل وأسفل 16 بكسل. لا أمانع كثيرًا في كتابة أسلوب بسيط لتجاوز ذلك ، لكن هذا مستحيل بسبب التصميم المضمن وسيكون من الجنون تمامًا بالنسبة لي أن أضطر إلى إنشاء مكون ذي مستوى أعلى لمجرد عكس ذلك كما هو الحال في تغليف المكون الخاص بك بـ div وتنفيذ الهامش: -14px 0 -16px أو تعديله قليلاً بحساب بالطريقة التي أريدها ، لكن الاضطرار إلى تصحيح ذلك بأي شكل من الأشكال ليس ضروريًا حقًا. سأفضله أكثر إذا سمحت بتمرير className كدعم كما تفعل بالفعل ، لذلك يمكن تطبيق تصميم التخطيط على المكون بالطريقة التي يريد مجتمعك تصميمها. على أي حال ، هذا هو بلدي .02 دولار.

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

أنا مع @ jbsmith969 تمامًا

سيكون من الجنون تمامًا بالنسبة لي أن أضطر إلى إنشاء مكون ذي مستوى أعلى فقط لعكس ذلك كما هو الحال في تغليف المكون الخاص بك بـ div وتنفيذ الهامش: -14px 0 -16px أو تعديله قليلاً بحساب بالطريقة التي أريدها

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

oliviertassinari @ jbsmith969 هذا بالضبط ما فعلناه! أنشأنا مكوّننا CustomTextField والذي قمت بتمريره مثل معلمتين إلى (اسم الحقل واللون) ، وهو يفعل القليل من المنطق حول هؤلاء ، ثم يقدم material-ui/TextField بأي شيء نحن تريد.

إنها مكونات على طول الطريق!

لذلك مع رد الفعل ، نأخذ html الخاص بنا ونضعه في js وهذا جيد ورائع. ولكن هل أخذنا css ودفعه إلى html؟ ألا ينسجم هذا مع أي شخص آخر؟

ما هي ميزة الابتعاد عن ساس؟

اتصل بي على الطراز القديم ، ولكن ما الخطأ في الفصل بين js / html و css؟

أنا أبحث بشكل شرعي عن بعض الإجابات هنا ...

فيما يتعلق بـ https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805 ، يصبح التصميم ببساطة مكونات.

أرى فئات CSS كمكونات جديدة: (على سبيل المثال ، btn-danger -like من boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

التحولات هي الألم رغم ذلك ..

(بالنسبة إلى @ jbsmith969 ، تتبع MUI مواصفات التصميم

vizath حق لدي بالتأكيد نفس الفكر. لكن ما هي مزايا هذا الحل؟

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

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

nathanmarks هل يمكنك تقديم المشورة حول كيفية تجاوز أنماط المكوّنات باستخدام JSS؟ أنا أستخدم أحدث رمز في next

تحرير: حسنًا ، اكتشفت أنه لا يزال غير مطبق بالكامل. خطأي! 😬

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

مثال عشوائي في أحد مكونات فرع next (الذي لم ينته): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
لا يمكنني العثور على طريقة لإيجاد أن الفصول الدراسية primary و accent غير مستخدمة.

لم تعجبني الطريقة التي كانت MUI تدير بها الأنماط المضمنة من قبل ، لنفس السبب (كان من الممكن أن يمسك النسالة بالمتغيرات غير المحددة إذا تم تعريف الأنماط بشكل منفصل ، راجع https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

ما هي ميزة الابتعاد عن ساس؟

gdaunton يعتمد الأمر على الجانب الذي أنت فيه فيما يتعلق بعدم استخدام أسلوب inline-style / sass.

من وجهة نظر المستخدم ، سيوفر التحسين التالي:

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

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

    • يجب أن يكون المستخدمون قادرين على تقصير مفاتيح أسماء الفئات في الإنتاج.

  • لا تبعية سلسلة مضمّنة مثل _scss-loader_ أو _Webpack_.

من وجهة نظر المساهم / المشرف ، سيوفر التحسينات التالية:

  • لا مزيد من CSS لينتر
  • لا مزيد من CSS قبل المعالج
  • لا توجد بنية CSS للتعلم
  • لغة أكثر فاعلية لتصميم المكون: JavaScript
  • افتح إمكانية تجريد محرك النمط. على سبيل المثال باستخدام أساليب التفاعل مع الأنماط

لماذا يحاول هذا الريبو تبني ما يبدو أنه فكرة مرحلة ألفا

يعتمد على ما تقصده بفكرة مرحلة ألفا.
نحن بعيدون عن كوننا الشخص الوحيد الذي استخدم هذا النهج. على سبيل المثال AirBnB ، Khan Academy ، ReactNative.

عملت على الأقل بنفس جودة عمل CSS

تم تصميم CSS من البداية إلى نمط المستندات ، وليس المكونات .
هذا تحول كبير في صناعتنا.

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

نعم ، الفرع التالي يستخدم jss

nathanmarks أين يمكنني أن أشارك في هذا التغيير؟

تم العثور عليها: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

يبدو أن bramick ليس حول next لأن هذا العمل بدأ من 0.15.0

حسنًا ، فاتني ما هو الجديد ... هل من أحد؟

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

oliviertassinari نجاح باهر! شكرا على الرد المتعمق.

لا أستطيع أن أقول إنني أتفق تمامًا ، لكنك أوضحت بتحد بعض الأسئلة التي كانت لدي.

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

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

gdaunton اقرأ عن أداء jss على https://github.com/cssinjs/jss/blob/master/docs/performance.md

إنه ملف css قياسي كما تم تقديمه وإضافته إلى الصفحة ولكنه مؤلف داخل المكون. أنا أستخدم الفرع next وهو يعمل بشكل جيد.

newoga هل يمكنك أن ترسل لي رابطًا لما تشير إليه؟

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

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

أكثر ما يقلقني هو أن معلومات النمط ستؤدي في النهاية إلى تشويش تعريف المكون . يعد CSS المعبر عنه باستخدام كائنات JavaScript أكثر تفصيلاً ويصعب تنظيمه . على سبيل المثال ، في المكون Button المشار إليه في المنشور السابق ، ما يقرب من نصف الرمز هو معلومات النمط. لم يعد هناك فصل للمخاوف بعد الآن. أعلم أنه يمكنك نقل رمز النمط إلى ملف منفصل ، ولكن بعد ذلك لا فائدة من وجوده في JavaScript في المقام الأول.

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

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

أكثر ما يقلقني هو أن معلومات النمط ستنتهي في تشويش تعريف المكون.

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

يعد CSS المعبر عنه باستخدام كائنات JavaScript أكثر تفصيلاً ويصعب تنظيمه.

إنه في الواقع أقل إسهابًا لأن لديك مستوى أعلى من إعادة استخدام الكود وأقل تكرارًا.

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

أعتقد أن الهدف هنا هو منح مستخدمي واجهة المستخدم المادية خيارًا لاستخدام ما يريدون للتصميم. الإكمال التلقائي لـ CSS هو حجة أسمعها كثيرًا. في الغالب يأتي من الأشخاص الذين لم يستخدموا أي cssinjs كثيرًا وخوفًا من فقدان بعض وسائل الراحة التي اعتادوا عليها.

لا أمانع في إضافة التعقيد إلى مشاريعي ، إذا كان ذلك يجلب المزيد من القيمة.

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

أكثر ما يقلقني هو أن معلومات النمط ستنتهي في تشويش تعريف المكون.

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

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

تحقق من هذا https://styled-components.com/

لقد تأخر الوقت كثيرًا في تغيير التقنيات في اللعبة ، لكنني أوافق على أن المكونات المصممة واعدة جدًا. يعالج SSR ، واستعلامات الوسائط ، وبناء الجملة الجميل وما إلى ذلك. مقارنةً بـ JSS ، فإنه يتعامل أيضًا مع التجديد التلقائي والثيم.

بقدر ما أعلم أنه يستخدم postcss بالداخل ، والذي لن يعطي أداءً مقبولاً عند استخدامه في وقت التشغيل ، لأنه محلل css كامل مع الكثير من التعامل مع حالات الحافة والمكونات الإضافية. يمكنني أن أتخيل معالجة هذا مسبقًا لـ JSS JSON ، ولكن لأكون صادقًا ، لا أرى قيمة كبيرة في استخدام لغة CSS وخلطها مع متغيرات JS واستدعاءات الوظائف مقابل استخدام JS على طول الطريق.

فقط لذكر ، البناء الحالي للمكونات المصممة هو 250 كيلو بايت ، تم تصغيره بالفعل . لكي نكون منصفين ، هذا لأنهم يجمعون React و co ، ولكن لا يزال ، حتى محلل PostCSS وحده يحتوي على 13 كيلوبايت (غير محدود ، قد يكون 2 كيلوبايت ~) وهو بالفعل تقريبًا حجم JSS أو Fela.

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

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

لقد استخدمت أدوات رد الفعل مؤخرًا ، فهم يستخدمون وحدات CSS من أجل التخصيص الذي يعتمد بشكل أساسي على webpack's sassLoader . بالنسبة لي عملت بشكل جيد. ربما يستحق الأمر التحقيق.

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

لا أعتقد أن أي شخص يجب أن يتوقع أبدًا أن يكون تصميم CSS القديم الجيد مواطناً من الدرجة الأولى في واجهة المستخدم المادية ، وهذا هو السبب في بدء react-toolbox

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

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

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

بالنسبة لي ، أنا أقدر الطريقة التي تقوم بها Material-UI بالتصميم بدلاً من شيء مثل رد الفعل ، وإليكم السبب: في أحد مشاريعنا ، لدينا القدرة على تحديد السمات الديناميكية:

Imgur

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

في رد فعل الأدوات وآخرون. آل. ، يبدو أن هذا أكثر من عمل روتيني مما يمكنني رؤيته.

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

DominikGuzei يمكنك تخصيص فرع next باستخدام jss. هذا _لا _ ما تراه في الإصدار الحالي.

يا رفاق ، أشعر وكأننا نتغلب على حصان ميت هنا. اختار الفرع next مسارًا مختلفًا (مُحسَّنًا كثيرًا) مع تحديد السمات ويسمح بالتجاوزات. لم يعد يستخدم الأنماط المضمنة ويوفر المرونة التي رأيتها مطلوبة. بالنسبة للآخرين الذين يرغبون في المزيد من التخصيص ، يمكنهم استخدام المكوّن الإضافي HOC عبر مكونات next وكتابة أوراق الأنماط الخاصة بهم.

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

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

fgarcia لقد قدمت عرضًا تقديميًا في حدث محلي في باريس في وقت سابق من هذا الأسبوع فيما يتعلق بتطور نهج التصميم الذي تستخدمه Material-UI. قد تكون مهتمًا بإلقاء نظرة على الشرائح و _notes_: رحلة نحو أسلوب أفضل . أركز على التحديات والمشاكل والحلول.

المستخدم لتحديد الموضوعات الديناميكية

إن جانب توليد النمط الثابت لوحدات CSS له بعض النتائج.
أسلوب الحقن في وقت التشغيل أقل فعالية من حيث التكلفة ولكنه يتيح لنا:

  • يمنحنا المزيد من المرونة في تنفيذ النمط. على سبيل المثال ، يحتوي CircularProgress على thickness ثابتًا مرتبطًا بكيفية تنفيذ الرسوم المتحركة للإطار الرئيسي لـ CSS. باستخدام النمط الديناميكي ، يمكننا إضافة خاصية سمك بحيث يمكن للمستخدمين تغيير القيمة ديناميكيًا. ⚠️ لا يساء معاملتها.
  • في التطبيق واسع النطاق ، يسمح بإدخال الأنماط المطلوبة فقط للمكون المعروض على الشاشة. تقليل مقدار العمل الذي يحتاجه المستعرض لبدء تشغيل الصفحة. وبالتالي ، وقت أسرع للطلاء الأول بعد التفاعل. على سبيل المثال تضمين CSS الحرجة مع SSR.
  • السماح للمستخدمين باستخدام سمة ديناميكية وتنوع المكونات. على سبيل المثال ، تغيير لون الزر بكل تنوعات الألوان المطلوبة.

oliviertassinari من الرائع سماع ذلك. قد يكون لدي وجهة نظر غير قياسية فيما يتعلق بوحدات CSS ، لكنني لا أعتقد أنها تستحق كل هذا العناء. كنت متحمسًا لسماع JSS من خلال واجهة المستخدم المادية لهذا السبب. يبدو أكثر انسجاما مع فلسفة JavaScript من وحدات CSS.

oliviertassinari شكرا لملخص الفوائد. إنه بالتأكيد مثير للاهتمام عندما تنظر إلى هذه الجوانب. يتمثل الجانب السلبي لـ JSS ونظامه البيئي (أيضًا postcss) في الوقت الحالي في أن كل ما يمثل حافة النزيف ولا يمكنك الاعتماد على سلسلة الأدوات وقاعدة المعرفة الراسخة مثل وحدات css-modules البسيطة + SASS. ولكن هذا هو السعر الذي تدفعه مقابل الابتكار ، فالأمر يعتمد فقط على ما إذا كانت لديك متطلبات معينة / كنت على استعداد لدفع ثمن الأخطاء والمسار الأقل توثيقًا.

تم إنشاء JSS قبل وحدات css. أصبحت وحدات CSS شائعة بشكل أسرع لأنها حلت مشكلة لغالبية المستخدمين دون تغيير البنية بشكل جذري.

ومع ذلك ، فأنت تستخدم رد فعل ، وهي أيضًا تقنية "جديدة" نوعًا ما. إذا كنت تريد SASS ، فربما يجب عليك أيضًا اختيار Vanilajs أو backbonejs)

kof React هي قصة مختلفة تمامًا حيث يستخدمها مئات الآلاف من المطورين ويديرها Facebook (لن تختفي خلال الليل) ، لذلك قد تكون "جديدة" ولكنها قوية جدًا (لم تصطدم بها العديد من المشكلات معها حتى الآن).

يعد SASS واحدًا من أكثر المعالجات المسبقة لـ css ويمكن استخدامه في أي مشروع - فهو قوي جدًا ويضفي قيمة كبيرة على الطاولة. لذلك سأختار شيئًا مثل JSS فقط إذا كان ذلك ضروريًا للغاية (على سبيل المثال: بسبب السمات الديناميكية) ولكني لا أحب التخلي عن سنوات من الخبرة / الأطر / قاعدة المعرفة وما إلى ذلك في مشروع برمجيات تجاري مع العديد من المطورين. لذلك أنا أفكر في بناء جانب السمة الديناميكية فقط في JSS والباقي باستخدام وحدات sass / css.

أنا أفهم طريقة التفكير هذه ، لكنني أعتبرها أيضًا غير منتجة وألقي باللوم عليها في إبطاء الابتكار والصناعة.

لماذا لا تدعم كليهما؟ الأنماط المكتوبة في JavaScript وأنماط مكتوبة في وحدات css؟ إذا ألقيت نظرة على https://github.com/callemall/material-ui/blob/next/src/Button/Button.js على سبيل المثال ، فسيكون من السهل جدًا استخدام أسماء الفئات التي تم تمريرها بواسطة الدعامة ( https://github.com/javivelasco/react-css-themr) بدلاً من استخدام:

const classes = this.context.styleManager.render(styleSheet);

أليس كذلك؟

لا يبدو أن المناقشة حول استخدام JSS أو CSS تجد نهاية (حتى الآن؟). بالنسبة لي يبدو وكأنه خمسون / خمسين شيء في الوقت الحالي.

فيما يتعلق بـ SASS ، فإن أدوات رد الفعل تهاجر حاليًا

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

ضع في اعتبارك إضافة خاصية * className أينما كان هناك دعم نمط *. فترة.

الإفصاح الكامل: أنا مستخدم أفروديت سعيد.

ستظل إضافة className تتطلب اختراق !important لأن الأنماط المضمنة (من خاصية style ) لها الأسبقية.

ligaz بالطبع ، أنت على حق. يضيف Aphrodite !important لكل شيء بشكل افتراضي ، لذلك ربما يكون تفكيري حول "مجموعة واسعة من الاستخدام" منحرفًا بشكل سيئ.

ligazestaub - next بالفعل مشفرة _without_ style ويسمح للمستخدمين من المكونات لتجاوز خلال توفير className (وأسماء فئة متعددة إلى أجزاء مختلفة من المكونات المعقدة) .

إعداد نموذج التصميم في الفرع next بواسطة المشرفين يستخدم JSS. إنه لمن دواعي سروري استخدامه ويسهل تجاوزه على أساس فردي أو موضوع.

هذا الحصان مات. دعونا نتوقف عن ضربها. oliviertassinari أقترح عليك إغلاق وإغلاق هذه المشكلة ببيان الاتجاه على next .

مرحبًا rosskevin - هل يمكنك أن تدلني على أي أمثلة على الإطلاق لكيفية عمل هذا في المرحلة التالية؟

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

أي تفاصيل أخرى ستكون مفيدة حقًا!

شكر

giuseppepaul next غير منشور على npm لأنه قبل ألفا ولم يكتمل بعد. يمكنك استنساخ https://github.com/callemall/material-ui.git#next وتشغيل docs/site لترى أنه لم يعد هناك أنماط مضمنة. كما أن لديها قدرًا معقولًا من العروض التوضيحية.

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

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

هذا الحصان لم يمت بالكامل. لكن بالتأكيد في مأزق 🔫.
أوافق ، دعنا نغلق هذه المسألة.

شكراً جزيلاً لـ nathanmarks لعمله الجاد على تلك القصة!
لقد جمعت المزيد من المعلومات عن الطريق أمامك مع # 5718.

مرحبا،
IconButton على خاصية CSS3 transition لتأثير مضاعف. في التفاعل المعقد للوثيقة من بطاقة next، قمت بإضافة transition إلى التحول لإضافة انتقال عندما النكسات رمز.
إذا فعلت الشيء نفسه على تطبيقي ، فإن انتقالًا واحدًا (تموج أو ارتداد) يتجاوز الآخر (لا يمكن أن يكون للعنصر خاصيتين ، وإلا فإن إحداهما تتجاوز الأخرى).
ومع ذلك ، فقد تم بنجاح تطبيق رمز رتبة عسكرية على transitions عليه. لأنه في طريقة ما تقوم بدمج الانتقالات المقدمة من IconButton وتلك المحددة في التعليمات البرمجية الخاصة بك. كيف حققت هذا ؟
بعض المواد الأخرى غامضة بالنسبة لي ولا يمكنني العثور على مستند ذي صلة. theme على العديد من الأساليب / الخصائص مثل breakpoints (غير مستخدم هنا) transitions (مستخدم هنا). هل هناك مستند بالفعل حول خاصية theme لما يعرضه MuiThemeProvider.createDefaultContext() لأنه يبدو مفيدًا خاصة أنه يستخدم على نطاق واسع داخل الكود.
this.context.styleManager.render(styleSheet) ؟ ماذا ؟
يمكنك أيضًا استخدام jss-theme-reactor الذي ما زلت لا أفهم النقطة مقارنة بـ react-jss .

NitroBAY هذا الموضوع انتهى. يرجى طرح سؤال على القناة الصحيحة. إذا لاحظت خطأ أو تريد تحسين التوثيق ، فافتح مشكلة. وإلا يمكنك استخدام StackOverflow of gitter.im.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات