من الأسطر الأولى من التعليمات البرمجية ، يبدأ الجميع في فهم أهمية تنظيمها بشكل صحيح وتحسين مساحة العمل ككل.
ليس من المهم تحديد الصناعة التي يجب التحدث عنها على وجه التحديد ، ولكن من المهم أن نفهم أنه حيثما توجد شفرة ، يجب أن تكون هناك قواعد لإنشائها وتخزينها.
في الزوجين الأولين ، بالطبع ، قد يبدو أن الالتزام بقواعد وأوامر معينة لا يستغرق سوى وقت ، وهو ما يبدو في الواقع مختلفًا تمامًا. إن جوهر أي مبادئ لرمز الكتابة هو أننا لا نكتبها مرة واحدة وإلى الأبد - نعود إليها باستمرار بغرض التعديل والتعديل.
يمكن أن تتحول هذه العملية إلى مشكلة حقيقية إذا سادت الفوضى وعدم القدرة على التنبؤ بها. يمكن أن تتفاقم هذه المشكلة إذا لم يتم إنشاء هذه الفوضى بواسطتك ، ولكن من قِبل شخص لا يمكن إقامة اتصال معه. من أجل القضاء على مثل هذه الحالات ، هناك منهجيات.
إذا تحدثنا عن المغلق ، فيمكننا القول بثقة - كل واحد منا يستخدم منهجية معينة ، بوعي أم لا. حتى إذا كان الشخص لا يستخدم قواعد ومعايير معينة ، فلا يزال لديه عاداته الخاصة ويكرر الحيل باستمرار.
لا يجب أن تكون طرق كتابة التعليمات البرمجية مقبولة وموحدة بشكل عام ، ويجب أن يكون هناك شيء آخر إلزامي - يجب أن يكون متوقعًا.
قائمة المنهجيات التي يجب الانتباه إليها ليست طويلة:
- بيم ،
-ماكسس ،
-OCSS ،
-MCSS ،
الذري المغلق
ربما يكون CSS الذري هو المنهجية الأكثر غرابة وحتى المخيفة إلى حد ما ، والتي لحسن الحظ لا تمنعها من أن تكون مفهومة للغاية ويمكن التنبؤ بها.
لإثبات خياري ، لا بد لي من التراجع قليلا.
تقريبا الذري المغلق
كانت هناك أوقات عندما بدا الدليل الجذر لعدد كبير من المشاريع في مرحلة إنشاء الواجهة مثل ثلاثة ملفات ومجلدين:
>fonts >img -index.html -style.css -script.js
لكن هذه البساطة قد تبدو مريحة بشكل مخادع ، في الواقع ، على الأقل في اثنين من هذه الملفات الثلاثة حدث شيء فظيع.
شيئان يضايقانني دائمًا - الفوضى ونقص الأناقة. في Css ، تندرج الكثير من الفروق الدقيقة المختلفة ضمن تصنيف الاضطراب ، لكن الأهم من ذلك كله أنني لم أكن راضيًا عن التكرار المستمر لنفس القواعد والخصائص لمختارين مختلفين.
الحل الأول لهذه المشكلة هو ما يلي:
- إنشاء ملف يسمى "re-use.css" ،
- إنشاء تعليمات في هذا الملف ، والتي قد تكون مطلوبة من الناحية النظرية من قبل أكثر من محدد ،
- إضافة محددات مختلفة لنفس التعليمات.
يبدو مثل هذا:
... .class { display: inline-block;} .class { text-transform: uppercase;} ...
وقبلت بالتالي ما يلي:
... .menu-link, .primary-button, .form-button, .footer-link, .social-link { display: inline-block;} ...
بالطبع ، كان هذا الحل غير مريح للغاية ولحسن الحظ مؤقت. لم أتعذّب لفترة طويلة مع التبديل غير المحدود بين الملفات ، والعثور على المكان المناسب فيها ، توصلت إلى استنتاج مفاده أنه سيكون أكثر ملاءمة لإنشاء فصول منفصلة تكون مسؤولة عن إرشادات واحدة لكل منها:
...
.inline-block { display: inline-block;} .block {display: block;} .uppercase {text-transform: uppercase;}
في ملفات html ، بدت العلامات التي تحتوي على عدد كبير من الفئات غريبة ، لكن هذا الحل بدا لي مقبولًا تمامًا:
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>
في لمحة ، يكفي أن نفهم أن هذا عمود جانبي ، ذو وضع ثابت ، على الجانب الأيسر من الشاشة ، يشغل 30٪ من عرضه و 100٪ من طوله ، ممتلئ باللون الرئيسي.
كل ما يتعلق بالقيم العددية ، خاصة تلك كانت المسافات البادئة الخارجية والداخلية ، كتبت بالتنسيق القياسي. للقيام بذلك ، أضفت فصلاً منفصلاً يأتي أولاً إلى كل علامة أو مجموعة من العلامات ، في المثال أعلاه هو فئة "التمرير".
لقد كانت مقاربة ذرية تقريبًا وملائمة تقريبًا. منعت العديد من أوجه القصور من الراحة ، وأهمها الحالات التالية:
- عند إنشاء عدد كبير من العلامات المشابهة ، على سبيل المثال ، عناصر القائمة ، اضطررت إلى نسخ الكثير من الفصول الدراسية وبدا ذلك مرهقًا ،
- عند إجراء أي تغييرات ، اضطررت إلى حذف وإضافة فئات لكل عنصر على حدة ،
- كان هناك العديد من الطبقات غير المستخدمة التي كان من الصعب اللحاق بها.
وبعد ذلك جاء شيئان إلى عملية الإنقاذ التي ساعدت في حل جميع المشكلات - وهي المعالج الأولي ومحرك القالب.
بمساعدتهم ، عدلت منهجي وجعلت التصميم لطيفًا ومريحًا.
ما يقرب من الكمال المغلق
سأبدأ مع المعالج. لقد كان اختياره غير أساسي ، فقد استخدمت Sass أولاً ، ثم SCSS ثم انتقلت في النهاية إلى Stylus ، لأنني أحترم الحد الأدنى ، وكان Stylus بسيطًا قدر الإمكان (سيتم استخدام scss في الأمثلة أدناه ، نظرًا لشعبيته).
لذا ، فإن أول شيء فعلته هو كتابة فصول إضافية تشبه الذرات الحقيقية باستخدام توجيهextend:
.flex { display: flex; flex-wrap: no-wrap; } .flex-jc-center { @extend .flex; justify-content: center; } .flex-ai-center { @extend .flex; align-items: center; }
أعجبتني الفكرة ، وتسبب توجيهextend في تشابه النواة الذرية ، بجانبها كانت هناك تعليمات إضافية.
قررت أنه يجب تطوير الفكرة وإنشاء ملف منفصل للكائنات الحية. الكائنات التي دعوت إليها الفئات التي تتضمن عدة توجيهاتextend:
.header { @extend .fixed; @extend .w-100; @extend .main-fill; @extend .left; @extend .top; @extend .flex-ai-center; @extend .z-top; }
بعد أن أنشأت "حديقة حيوانات" صغيرة من مختلف الكائنات الحية ، قررت أن أفعل شيئًا مع الفئات التي تتطلب قيمًا رقمية للمسافة البادئة والحجم.
لقد ساعدتني قدرات المعالج الأولي على التغلب على هذا الأمر مرة أخرى ، حيث كتبت بمساعدة بعض الوظائف والمتغيرات المضافة.
أولاً ، درست بالتفصيل المشاريع الرسومية التي أحصل عليها من المصممين وكشفت عن عدد من الأنماط:
- عدد الألوان لكل مشروع ،
- عدد الخطوط
- عدد أحجام مختلفة للنص والعناوين ،
- المسافة البادئة المتكررة (للأقسام والأزرار وما إلى ذلك)
كانت الخطوة الأولى لكتابة الوظائف والخلطات لإنشاء الفئات اللازمة:
// px em @function em($pixels, $context: $browser-context) { @return #{$pixels/$context}em };
// $text-size: ( l: 18, m: 16, s: 14, xs: 12 );
@mixin emFonts($list, $n) { // $list – , n – . @each $status, $size in $list { // - &-#{$status} { font-size: em($size - $n); // } } }
الآن يمكننا أن نسمي هذا المزيج من الخلاطات والوظائف في أي مكان مناسب لنا:
.txt { @include emFonts($text-size, 0) }
وفي المخرجات نحصل على 4 فصول للنص ذي الأحجام المختلفة:
.txt-m { font-size: 1.125em; } .txt-s { font-size: 1em; }
وبالمثل ، يتم إنشاء واستدعاء وظائف لأحجام العناوين والنصوص وملء الألوان والخطوط وما إلى ذلك.
أي أن العمل في كل مشروع يبدأ بملء قيم المتغيرات ، وتنتقل الفئات والوظائف ذاتها من مشروع إلى آخر.
محرك القالب.
أعتقد أن العديد منكم يستخدمون templating ، وعلى الأرجح هذا هو Pug (التي كانت تسمى سابقًا Jade).
من أجل التنضيد الذري ، من الضروري بفضل 3 أشياء:
الصلصال ينقذنا تماما من النظارات الدقيقة مرهقة من رمز HTML ، لأنه يمكننا تشغيل التعليمات البرمجية التالية:
… <ul class=”menu__list flex-ai-center w-100 relative “> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>first</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>second</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>third</li> </ul>
مناسب للتحرير:
-let menuItemClasses = 'menu__item m-color m-font txt-s inline-block bold-border' // ul li(class=`${menuItemCLasses}`) frst li(class=`${menuItemCLasses}`) second li(class=`${menuItemCLasses}`) third ... </ul>
أو في نموذج آخر ، باستخدام حلقة:
let menuItems = ['first', 'second', 'third'] ul -for(let item of menuItems) { li(class=”menu__item m-color m-font txt-s inline-block bold-border”) -}
هذا ليس أقل ملاءمة ، لأن الخط مع الفئات الضرورية لا يتكرر أكثر من مرة.
وكانت نقطة الضعف الأخيرة في هذه المنهجية هي بقاء عدد كبير من الفئات غير المستخدمة في الكود. ولكن تم حل هذه المشكلة التي تبدو خطيرة بسهولة عن طريق إضافة مكونات إضافية إلى أداة إنشاء المشروع التي تزيل الفئات غير الضرورية.
الخاتمة
في الختام ، أود أن أقول ما يلي:
قبل البدء في استخدام "المنهجية الذرية تقريبا" ، استخدمت smacss ثم BEM لفترة طويلة. نتيجة لذلك ، من bem تركت فقط أسماء الفئات التي تتطلب أوصاف المسافات البادئة والأحجام ، والتسلسل الهرمي لتخزين الملفات والمجلدات. مجموعة من الفصول والوظائف الجاهزة ، أقوم بالاتصال بالمشروع كمكتبة.
النقطة المهمة التي أود الإشارة إليها هي راحة تصميم الصفحات والأقسام الفردية ككل. بفضل النظارات الدقيقة ، من السهل بما فيه الكفاية إنشاء "هيكل عظمي" لصفحة أو قسم في محرك القالب وبعد ذلك فقط انتقل إلى كتابة أنماط لها.