هذا المنشور هو إجابة مفصلة للأسئلة من هذه المحادثة على Twitter . مؤلف الأصل ، Sunil Pye ، هو مؤلف مكتبة السحر شعبية نسبيا ويعمل كمطور على Facebook.
كيف يكون Javascript أكثر ملاءمة من CSS؟ كيف تجعل كتابة CSS داخل JS أكثر دعمًا؟
سأكون سعيداً للحديث عن هذا الموضوع. يجب أن أقول على الفور أن حلول CSS-in-JS لها تكاليف عامة ، ولكن عادة ما يتم تبرير هذا السعر بالمزايا التي يجلبونها. قد تكون مفيدة في بعض الأحيان ، ولكن هذا لا يعني أيضًا أنه يجب استخدام CSS-in-JS دائمًا وفي كل مكان.
لذلك ، فإن أهم شيء في CSS-in-JS (cij) هو محددات CSS. أكبر ميزة لـ cij هي أنه يمكن لأجهزة الكمبيوتر توليد هذه المحددات تلقائيًا. اتفاقيات مثل OOCSS ، إلخ. من حيث المبدأ ، فهي جيدة ، لكنها تستند إلى محددات مكتوبة بخط اليد ، والتي يصعب ضمان التفرد في مساحة الاسم الشائعة ، لأن هناك دائمًا فرصة للتقاطع. إذا لم يحدث هذا الآن ، فقد يحدث بعد ثلاث سنوات ، عندما ينمو فريقك ، وتتغير الظروف. يتم تفاقم هذا الموقف باستخدام مكتبات الجهة الخارجية. يمكن أيضًا الحد من نطاق محددات CSS باستخدام وحدات CSS ، والتي تحظى بشعبية كبيرة على وجه التحديد لهذه الفرصة.
ومع ذلك ، في ظل كل هذه الأساليب ، يصعب على المُحددين إجراء تحليل ثابت والعثور على أي منها مُعطّل (أو يحتوي على أخطاء مطبعية) ، مما يعني أنه سيتعين فحصهم يدويًا في عملية مراجعة الكود ، مما يقلل من فعالية الأمر. يجب أن نستخدم مساعدة أجهزة الكمبيوتر وألا نعتمد على سلامة الأشخاص وعدم صوابهم (لأن هذا ليس كذلك). يجعل CSS-in-JS من الممكن أتمتة إنشاء محددات ومعرفات فريدة.
بالإضافة إلى ذلك ، يفتح التحكم المحسن في محددات CSS إمكانيات جديدة لم يكن الوصول إليها سهلاً من قبل. على سبيل المثال ، يمكننا ببساطة تنفيذ استخراج CSS الحرج من خلال مطابقة كتل HTML مع الأنماط التي يحتاجون إليها ، حتى نتمكن من تحميل 1-2 كيلوبايت فقط من CSS على الصفحة ، وهو أمر ضروري للعرض الأولي للصفحة. بدون أي وقت تشغيل! تستخدم أطر مثل Gatsby و Next هذا لتحسين مؤشرات الأداء في المشروعات القائمة عليها. إنهم يقومون بدمج CSS الحرج مباشرة في HTML القابل للتنزيل لأنه ببساطة يزن أقل مما سيكون أفضل من تحميل صفحة إضافية لحظر الطلب. هذا يقلل بشكل كبير من وقت تقديم الصفحة الأولية. علاوة على ذلك ، فإنه يساهم أيضًا في حل مشاكل حجم Javascript القابل للتنزيل! تأتي الفوائد من تطبيق CSS الحرج ، وكذلك استخدام عمليات import() الديناميكية import() وتقسيم الشفرة وإزالة الشفرة غير المستخدمة. (على عكس ملفات أسلوب Legacy المتنامية باستمرار ، والتي يضيف إليها المطورون فقط رمزًا جديدًا ، ويخافون من لمس الكود الحالي. يوجد القليل من التحليلات حول هذا الموضوع .)
وضع مماثل مع تنفيذ المواضيع. هل تعلم أن متغيرات CSS ، حتى لو كانت شيئًا مثيرًا للاهتمام ، لم تنطلق إلى حالات الاستخدام التي كانت مخصصة لها في الأصل ، وكل ذلك لأن أساليب الرجوع إلى المستعرضات القديمة كانت معقدة للغاية أو رديئة؟ هذا يعني أنه يتم استخدامها عادةً كثوابت عمومية ، ولكن نادرًا ما تكون متغيرات يتم تحديد قيمتها ديناميكيًا في المستعرض. وجود وقت تشغيل CSS CSS يعني أنه يمكنك تمرير القيم من JS إلى الأنماط ، مما يجعل هذا ممكنًا.
في الحقيقة ، سوف ترغب في ذلك: يمكنك أخيرًا استخدام متغيرات CSS بصدق في جميع المتصفحات ، أي القدرات المحلية بدون وقت تشغيل في المتصفحات التي تدعمها ، ووقت تشغيل خاص للمتصفحات القديمة. (لقد كتبت المزيد عن هذا هنا ، و- إذا فهمت بشكل صحيح - فهذه هي المكتبة الوحيدة التي حققت ذلك).
في وضع SPA معقد مع مجموعة من المكونات والتحميل غير المتزامن للموارد ، مثل البرامج النصية والأنماط ، لا يمكنك ضمان الترتيب الدقيق لأنماط التحميل ، لذلك إما عليك إنشاء نوع من حلول وقت التشغيل لضمان ترتيب الأنماط ، أو مجرد استخدام !important ، حتى إذا كنت تتمسك بنوع من منهجية CSS . على سبيل المثال ، لديك عنصر مع class=“ab” ، لكن b تعريف الفئات a و b في ملفات أنماط مختلفة ، ثم لا يمكنك التأكد من الشكل النهائي للكتلة إذا لم يكن لديك ترتيب تسلسلي واضح لملفات النمط. تحتوي قاعدة رموز Facebook على آلاف من الاستخدامات !important ، على الرغم من أن الكود تم كتابته بواسطة مبرمجين مؤهلين باستخدام مبادئ SOLID وتفاعل جيد مع فريق التصميم.
يشير هذا غالبًا إلى التعامل مع CSS كما لو كان Javascript - بالنظر إلى أننا كنا نحل بالفعل مشكلات مماثلة لـ JS قبل 10 أعوام - سجلت المكتبات والوحدات النمطية نفسها في مساحة الاسم العالمية ( $ وما شابهها) وكان علينا توخي الحذر الشديد مع ترتيب الاتصال البرامج النصية في HTML. لكننا لم نكن عالقين هناك إلى الأبد - الآن نستخدم وحدات ، وأنظمة التجميع خياطة لهم معا في ترتيب صحيح مضمون. هذا بسيط وشفاف بالنسبة لنا.
عند مشاهدة مشاريع حقيقية ، لاحظت أيضًا أنه لا يزال بإمكانك استخدام الأساليب المعمارية التقليدية (مثل OOCSS أو SMACSS ، وما إلى ذلك) في عالم CSS-in-JS - يتم تمثيل عناصر تلك الهياكل هنا بواسطة كائنات JS ، بدلاً من كتل محدد + الأنماط. أنا أتبع هذا النهج وهو يعمل بشكل جيد بالنسبة لي. هنا يمكنك قراءة المزيد حول هذا الموضوع.
كما أنني أدرك جيدًا مساوئ CSS-in-JS. في الواقع ، هذا هو بالتحديد السبب في عدم وجود مكتبة "قانونية" واحدة تمثل CSS-in-JS - إنها طيف من الحلول المختلفة ، من الفانيليا الساكنة CSS من ناحية إلى المكتبات الديناميكية تمامًا مثل المكونات المصممة على الجانب الآخر. قد تبدو المعالجات المسبقة مثل SASS أو LESS متعامدة مع هذا الطيف ، لأنه يمكن نظريًا استخدامها من قبل أي من هذه المكتبات وفقًا لتقدير مؤلفيها. كل من هذه المكتبات لها عيوبها - بعضها منشغل في استخراج الأنماط في مرحلة التجميع بحيث لا توجد نفقات في وقت التشغيل ، وبعضها يركز على صحة أو راحة المطورين ، بينما يركز البعض الآخر على التنفيذ الفعال للرسوم المتحركة المعقدة ، وما إلى ذلك. هذا التنوع هو رد فعل طبيعي على الحاجة إلى حلول مختلفة لمهام العمل المختلفة ، في صناعة سريعة النمو. وهذا يحدث ليس فقط مع المكتبات - يحاول مطورو معايير الويب (ShadowDOM وغيرهم) ببسالة حل هذه المشكلات أيضًا ، ولكن حلهم أيضًا به عيوب ، وأقلها أنها غير متوفرة في كل مكان ، مما يجعله غير مقبول للاستخدام في العديد من الفرق.
اعتدت أن يكون لدي شعور قوي حيال ذلك ، لكنني خففت من آرائي خلال الأشهر القليلة الماضية. اتضح أن الحقيقة تكمن في الواقع في مكان ما في الوسط - ذلك يعتمد على الفرق والمتطلبات والوقت والتوثيق والعديد من العوامل الأخرى. علاوة على ذلك ، لا أعتقد أن هذا النص يمثل "الشكل النهائي" لهذه الفكرة. يجب أن نشجع التجريب في هذا المجال حتى نتمكن من معرفة ما يمكننا القيام به بشكل أفضل ، وحتى تضمين بعض هذه الأشياء في المتصفحات.
ملاحظة: بعد فوات الأوان أدركت أنني نسيت تحديد مربع "الترجمة" ، لذلك تم نشره على هذا النحو. رابط إلى الأصل .
Habr ، إصلاح الواجهة ، لماذا لا يمكنك إضافة إشارة الترجمة بعد النشر؟