لدينا ، الواجهة الأمامية ، فئة من الأدوات التي لا تحل المشكلات التي نواجهها ، ولكنها تؤثر في عملية حلها. تغييره. يختلف الموقف من هذه الأدوات اختلافًا كبيرًا - بدءًا من الهوس بروح "دعنا نشير إلى هذا الشيء في كل مكان ، إنه رائع جدًا" وينتهي بأعذار مثل "إذا لم يحل مشكلة العمل ، فلن نحتاج إليها". ولكن ، على أي حال ، اليوم سنتحدث عن PostCSS - واحدة من هذه الأدوات.
لقد مرت فترة طويلة من الضجيج ؛ في السنوات الأخيرة ، قيل القليل جدا عن PostCSS. العديد من المبتدئين لا يعرفون حتى ما هو عليه. أعتقد أن الوقت قد حان للنظر في هذه الأداة من وجهة نظر الاستخدام العملي في معظم المشاريع العادية ، حيث يحل الناس المشاكل ، ولا يلعبون مع التقنيات العصرية.
PostCSS مقابل ساس
أوه ... يبدو بضع كلمات حول هذا الموضوع. أعتقد الآن أن هناك أداة طباعة نادرة لم تلتق بمعالجات مسبقة. تُستخدم SASS أو LESS المفضلة ، أقل استخدامًا للقلم ، في المشروعات الكبيرة وفي المشروعات الصغيرة. شخص ما يحاول الضغط على معظمهم ، يستخدم شخص ما مجموعة متغيرة الحد الأدنى - المتغيرات ، المتغيرات ، الواردات. ولكن ، بطريقة أو بأخرى ، تساعد هذه الأدوات في مشكلات بناء الجملة. أنها تجعل الأمر أسهل بالنسبة لنا لكتابة التعليمات البرمجية.
منذ حوالي عامين أو ثلاثة أعوام ، تمت مقارنة PostCSS باستمرار مع المعالجات الأولية. وهذا أمر مفهوم. بشكل رسمي ، باستخدامه يمكنك أن تفعل الشيء نفسه ، وصنع نوعًا من بناء الجملة سيكون أكثر ملاءمة من CSS الخالص. لكن كل هذا تسبب في حدوث هياج جماعي ، وذلك أساسًا لأن كل شخص بمساعدة PostCSS فعل شيئًا مختلفًا. عدد لا يحصى من الإضافات غير المعروفة ، وملايين المجموعات ، وبصرف النظر عن مؤلف هذا أو ذاك التكوين ، لا أحد يفهم كيف يعمل وماذا يعمل. يشبه Vim أو Emacs - يمكنك إنشاء سفينة فضائية منها ، ولكن سيكون من الصعب جدًا تعليم مطور آخر كيفية استخدامه.
ولكن إذا تجاهلنا هذه المقارنات ، فإن PostCSS هي أداة تتيح لنا أخذ CSS الخاص بنا والقيام بشيء ما. لا أحد يزعج استخدام SASS من أجل بناء الجملة ، وبعد التجميع ، يتمسك PostCSS والقيام بشيء ما بالنتيجة. انهم لا يتناقضون مع بعضهم البعض.
قديم لا يعني الخمول
في الآونة الأخيرة ، كان من المألوف بالنسبة لنا إنشاء مجموعات يمكن أن تفعل كل ما يتبادر إلى الذهن فقط ، وتطورها لا يتوقف أبدًا. وإذا لم يكن هناك أي تعهدات جديدة في المستودع لمدة شهرين ، فكل شيء - يمكننا افتراض أنه عفا عليه الزمن واستخدامه الآن - وليس comme il faut. سأبالغ ، بالطبع ، لكنني أعتقد أنك نفسك لاحظت مدى سخافة هذا الأمر في بعض الأحيان.
في عالم PostCSS ، عادةً يحل مكون إضافي مشكلة واحدة. يمكنك أن ترى عناصر من فلسفة يونكس هنا. يتبع الاستنتاج المنطقي هذا - إذا كان المكوّن الإضافي يعمل بالفعل على حل مهمته ، فلن يلزم القيام به بعد الآن. يمكنك العثور على مكونات إضافية لم يتم تحديثها لسنوات ، لكن هذا لا يعني أنها توقفت فجأة عن حل المهام التي أنشئت من أجلها.
لكن لنبدأ ... لقد جمعت عشرات المكونات الإضافية ، والتي أظهرت في الواقع قدرتها على تبسيط الحياة لمصممي التخطيط وتوفير الوقت أثناء التطوير. ولكن يمكنك دائمًا إضافة شيء ما في التعليقات.
رقم 1. Doiuse
https://github.com/anandthakker/doiuse
أعتقد أننا جميعًا واجهنا هذه المشكلة: تكتب الرمز ، تحقق من chrome - كل شيء على ما يرام. يمكنك التحقق في FF - تقريبا. ثم في Safari المحمول كل شيء ينهار. أو في الحافة. وأنت تجلس ولا تفهم ما هو الخطأ. ثم تحدق في الكود لفترة طويلة ، تشرب الشاي ، وفجأة تظهر فكرة أن بعض الخصائص غير مدعومة في بعض المتصفح. تذهب على caniuse وسترى تأكيدا واضحا.
بالطبع ، مع الخبرة ، تتذكر الأيدي نفسها الخصائص التي يجب تجنبها ، لكن أي شيء يحدث. لا يمكنك الحصول على قسط كافٍ من النوم ، يمكن أن تكون هناك مواعيد نهائية ضيقة وأعصاب ، ويمكن تغيير قائمة المتصفحات التي تحتاج إلى تغيير. ومن ثم ستبدأ التجربة بالفشل. Doiuse هي أداة تساعد كثيرا في مثل هذه الحالات.
مبدأ التشغيل بسيط - نحن نطعمه قائمة من المتصفحات و CSS لدينا. يذهب المكوّن الإضافي إلى قاعدة بيانات caniuse وفي الوقت الفعلي يعطينا الإجابة التي استخدمناها من ما هو غير مدعوم.
يمكننا ضبط قائمة المتصفحات مباشرة في package.json. بسيطة ومريحة. يستخدم PostCSS قائمة المتصفحات ، وإذا لم تكن قد شاهدته من قبل ، فسيبدو مثل هذا:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
هناك أيضًا تكوين doiuse نفسه ، حيث يمكنك إجباره على تجاهل بعض مجموعات الممتلكات إذا كنت متأكدًا من أنه لا يؤثر على أي شيء. على سبيل المثال ، إذا كنت تستخدم polyfiles أو من فقدان دعم بعض الخصائص ، فلن يتغير شيء:
ignore: [ 'will-change', 'object-fit' ]
السجل القياسي المقدم من البرنامج المساعد غير قابل للقراءة للغاية. أنه يحتوي على الكثير من المعلومات وليس من المناسب للغاية إدراكها. ولكن هذا قابل للتثبيت. في نفس التهيئة ، يمكننا القيام بوظيفتنا لإنشاء سجل.
استخدم console.log لمعرفة كيفية عمل الكائن الذي يمرر PostCSS إلى هذه الوظيفة. هناك العديد من الأشياء المثيرة للاهتمام.
أظهرت ممارستي أن الخيار الأكثر ملاءمة هو عرض محددات وخصائص محددة غير مدعومة ، دون تحديد المتصفحات وخطوط التعليمات البرمجية. إذا كان المشروع يستخدم BEM أو بعض التناظرية ، ويتم توزيع رمز المكون في ملفات منفصلة ، فإن هذا النهج يتيح لك العثور بسرعة على مكان للمشكلة دون تحميل الدماغ.
onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); }
لكي لا تكتب تسلسلات خاصة من الأحرف للألوان في وحدة التحكم ، يمكنك توصيل حزمة الألوان ، وسوف تكون أكثر ملاءمة معها.
عند البناء ، سيكون هناك شيء مثل هذا في وحدة التحكم:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
رقم 2. Autoprefixer
https://github.com/postcss/autoprefixer
من المحرج أن أتحدث عنه ، لكن غالبًا ما أرى أشخاصًا يكتبون في عام 2019 البادئات بأيديهم ولا يزالون يؤكدون للآخرين أنهم يعرفون تمامًا أي منها مطلوب وأيهم ليس كذلك. تؤدي مثل هذه الإجراءات إلى حقيقة أن الشفرة غارقة في مجموعة من البادئات غير الضرورية وتصبح غير قابلة للقراءة تمامًا. هذا يؤثر على إنتاجية العمل. من ناحية أخرى ، إذا كنت بحاجة إلى دعم الديناصورات ، يمكنك دائمًا نسيان شيء ما. لذلك يستحق التخلص من العمل اليدوي عند حل هذه المشكلة.
يعمل autoprefixer مع نفس قاعدة بيانات caniuse ، ويستخدم نفس قائمة المتصفحات ويمكن أن يضيف إلى CSS البادئات المطلوبة بالفعل في المتصفحات التي حددناها. في نفس الوقت ، يصبح الكود نفسه أكثر نظافة ، وسير العمل بشكل أسرع.
رقم 3. Stylelint
https://github.com/stylelint/stylelint
عندما تطبع الكثير وبسرعة ، تبدأ عاجلاً أم آجلاً في ارتكاب العديد من الأخطاء دون أن تلاحظها تمامًا. العين غير واضحة. في حالة CSS ، يمكن أن يعطي هذا تأثيرًا مضحكًا (في الواقع ليس) عندما تنظر إلى المتصفح - ترى مشكلة في التصميم. نظرتم إلى الكود - ليس هناك. أنت تنظر في المتصفح - هو عليه. لكن في الكود - لا. نتيجةً لذلك ، يمكنك البحث عن مشكلة صعبة لفترة طويلة ، دون أن تلاحظ تمامًا أنك تعرفت على رأسك. لمنع هذا ، اخترع linter.
Stylelint هو خيار شائع. إنه يعرف كيفية العمل مع بناء جملة المعالجات الأولية الرئيسية ، كما أنه يعرف أحدث الاتجاهات في CSS ، ويمكنه تخصيصها حسب ذوقه - التكوينات مماثلة لتلك الموجودة في eslint. من الناحية الرسمية ، يمكن استخدام هذه الأداة من تلقاء نفسها ، دون PostCSS ، ولكن ناهيك عن أنها ستكون خاطئة.
رقم 4. Postcss-flexbugs-إصلاحات
https://github.com/luisrudge/postcss-flexbugs-fixes
أو بمعنى أوسع ، إصلاحات postcss ، والتي تتضمن هذا البرنامج المساعد. ببطء ولكن بثبات يحل محل الطريقة القديمة للتخطيط على العوامات. هذا جيد ، لكننا نعلم جميعًا أن مجموعة من الأخطاء مرتبطة بها. يتم وصفها في مستودع flexbugs . يحتاج البعض منهم إلى عناية خاصة ، لكن هناك أيضًا عددًا بسيطًا جدًا لدرجة أنهم يبتعدون عن رأسك باستمرار. على سبيل المثال ، يتجاهل IE وظيفة calc في الاختصار للخاصية المرنة. هذا ليس ضروريًا في كثير من الأحيان ، ولكن إذا لزم الأمر ، يمكن أن تكتب يديك نسخة مختصرة ثم عليك أن تفكر لفترة طويلة في ماهية المشكلة. لحسن الحظ ، يمكن إصلاح هذا تلقائيًا. يأتي البرنامج المساعد postcss-flexbugs-fixes في عملية الإنقاذ.
في مثال calc ، سيجد أجزاء مثل هذه في الكود:
.foo { flex: 1 0 calc(1vw – 1px); }
ونشرها:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
بسيطة ومريحة.
رقم 5. Postcss-مسبقا-الحياة الفطرية
https://github.com/csstools/postcss-preset-env
نظرًا لأننا نتحدث عن دعم المستعرض ، فلن يكون من المنطقي القول عن postcss-preset-env. سابقا ، لعبت cssnext نفس الدور. سيكون هذا البرنامج المساعد مفيدًا إذا كنت مهتمًا باتجاهات جديدة في CSS.
يمكن تنفيذ العديد من الابتكارات تقنيًا باستخدام الأساليب القديمة ، فستكون طويلة جدًا ، مطوّلة وقبيحة. يساعدك الإعداد المسبق - env على كتابة التعليمات البرمجية بطريقة جديدة ، وتوفير الوقت في هذا ، ثم تحويله إلى إصدار موثوق به قديم. بالطبع ، لا يتم تطبيق بعض الأشياء مثل الخصائص المخصصة على الإطلاق في المتصفحات القديمة ، لذلك سيتم استخدام النسخ الاحتياطية هناك.
كما يمكنك أن تخمن من اسم الصك ، فهو يشبه نفس الاسم المحدد مسبقًا في بابل. هنا ، كل شيء هو نفسه - هناك العديد من المحولات تجميعها في مجموعة واحدة مستقرة. تتطلب بعض التحولات اتصالًا لاحقًا بنصوص polyphile على العميل ، ولكن يتم تنفيذ معظمها بحتة بواسطة CSS. بقدر ما أفهم ، ليست هناك حاجة لالمخططات Stage2 +. في أي حال ، لم أجد حاجتهم. صححني إذا فاتني شيء هناك.
رقم 6. Postcss الرسوم المتحركة
https://github.com/zhouwenbin/postcss-animation
غالبًا ما أسمع من أشخاص مختلفين (معظمهم من الذين ليسوا أقوياء في CSS) أنهم يرغبون في استخدام الرسوم المتحركة المنفصلة من animate.css ، لكنني اعتبرها مكتبة سيئة فكرة سيئة. إنه منطقي تمامًا. ولكن نتيجة لذلك ، يقضون الكثير من الوقت في محاولة لتكرار هذه الرسوم المتحركة من تلقاء نفسها.
البرنامج المساعد postcss - الرسوم المتحركة يسرع كثيرا هذه العملية. نكتب فقط اسم الرسوم المتحركة ، على سبيل المثال:
.foo { animation-name: bounce; }
وسحب ما يصل التنفيذ من animate.css وإدراجه في التعليمات البرمجية.
.foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } }
رقم 7. قائمة المنتخبات
https://github.com/davidtheclark/list-selectors
عندما يكون لديك العديد من أنواع الحروف والعديد من الأنماط ، فإن السؤال الذي يطرح نفسه في مراجعة الكود ، سيكون من الجميل أن ترى في بعض الأحيان بعينيك الصورة الكبيرة مع كل المحددات التي لدينا. معرفة معرفات المستخدمة ، ما إذا كان هناك محددات العلامة ، أو مدى اتباع المنهجية المقبولة. هذا مهم بشكل خاص عند التحقق من كود المبتدئين ، والذي يمكنه كتابة أشياء غريبة ستعمل رسميًا ، ولكن يتعارض فعليًا مع الاتفاقيات المقبولة (بعيدًا عن أي مكان يتم فيه إصلاح هذه الاتفاقات جيدًا وهناك فرصة لأتمتة مثل هذه الأشياء). قم بالتمرير خلال العديد من أوراق الأنماط بنفسك للتحقق من كفاية المحددات لفترة طويلة. نحن بحاجة إلى وسيلة لعزلهم وإظهارهم بشكل منفصل. محددات القائمة فقط يحل هذه المشكلة.
تمامًا مثل doiuse ، يتيح لك هذا الملحق استخدام وظيفته لإعداد المعلومات للعرض. يمكنك فقط عرض ما يثير اهتماماتك أو ترسم كل شيء بألوان مختلفة. كمثال:
require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); })
ينتج هذا المثال قائمة طويلة طويلة من المحددات:
SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . . ، SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .
رقم 8. غير قابل للتغيير-CSS
https://github.com/johno/immutable-css
شيء آخر يجب الانتباه إليه هو مقاطعة الأنماط من مكتبات الجهة الخارجية. إذا قمنا بتوصيل مكتبة من نوع ما ، ثم بدأنا في كتابة الأنماط الخاصة بنا للمُحددات منها ، في النهاية ، سنحصل على كود مربك لا يمكننا من خلاله معرفة ما الذي جاء منه. هذا يمكن أن يؤدي إلى أخطاء عشوائية ، والتي تأخذ بعد ذلك الكثير من الوقت للخروج من اللون الأزرق. كلما زاد عدد مرات إعادة تعريف شيء ما ، زاد صعوبة فهم ما يحدث في النهاية ، على الرغم من أن المشكلة نفسها التي تحتاج إلى حل يمكن أن تكون بسيطة للغاية. في هذه الحالة ، قد تكون أداة تسمى immutable-css مفيدة.
بشكل عام ، يكون مبدأ عملها بسيطًا: فهو يأخذ الملفات ذات الأنماط ، إذا وجد تطابقات على محددات ، فسيبدأ بسخطه:
! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css]
المشكلة الوحيدة في هذه الأداة هي أنها لا تدعم بناء جملة غير CSS. لذلك إذا تم استخدام المعالجات الأولية في المشروع ، فيجب مقارنة الملفات المجمعة بالفعل. ولكن بشكل عام ، إذا كانت المهمة هي ببساطة التأكد من عدم قيام أي شخص بإعادة كتابة الأنماط من مكتبة تابعة لجهات أخرى ، فهذا ليس بالأمر المهم.
رقم 9. وداعا وداعا!
https://github.com/AoDev/css-byebye
أعتقد أن الجميع على دراية بالموقف عندما نضيف تدريجياً بعض المكونات إلى موقع العمل. البعض منهم يذهب على الفور إلى الإنتاج ، والبعض منهم يجلسون لفترة طويلة وينتظر دورهم (على سبيل المثال ، لقد عانينا ، لم ننتهي من الواجهة الخلفية بعد). قد يكون هناك تجربة أو حل مؤقت لقضاء العطلات. قد يكون هناك العديد من المواقف ، لكنهم متحدون من حقيقة أن لدينا مجموعة من المكونات ، ويتم استخدام جزء صغير منها فقط في موقع القتال. سيكون من الجيد إزالة كل شيء غير مستخدم من التجميع الحالي. هذا يمكن أن يقلل بشكل كبير من حجمه ، وكذلك يقلل من الصداع في المستقبل ، عندما يكون من الضروري القيام بإعادة تصميم على سبيل المثال ، وسيكون السؤال هو ، ما الذي يجب إعادة كتابته الآن ، وما هو غير ذلك.
هناك طرق مختلفة لهذه المشكلة. Uncss يأتي على الفور إلى الذهن . تكتشف هذه الأداة تلقائيًا الأنماط المستخدمة على الصفحات وتزيل الأنماط غير الضرورية. ولكن في الممارسة العملية ، يؤدي هذا دائمًا إلى حقيقة أنه لا أحد يعرف ما الذي يتم استخدامه بالفعل وما هو غير المستخدم. أشك أيضًا في كل وقت فيما إذا كانت هذه الأداة قد حذفت أي شيء غير ضروري. ولكن ربما هذا هو جنون العظمة لدي. على الرغم من ...
Bye-bye هي أداة أبسط نقوم بتزويدنا بها بقائمة من المحددات لإزالتها من CSS. ويمكنك استخدام التعبيرات العادية. إذا كنت تستخدم BEM أو أي شيء آخر كهذا ، فيمكنك حذف كتلة تحتوي على كل ما يتعلق بها باستخدام طريقة واحدة عادية بسيطة. وداعا!
تحول هذا النهج إلى أن تكون مريحة للغاية. من الواضح على الفور الأنماط التي لم يتم استخدامها بعد أو التي تمت إزالتها على أنها غير ضرورية ، في حين أن جميع المصادر موجودة ، وجميع الإعدادات في ملف واحد ، ولا يتم فقد أي شيء ، ولا يسبب صعوبات في إنشاء عدة مجموعات مختلفة ، والأهم من ذلك ، أن الحل بسيط ويمكن التنبؤ به.
رقم 10. PostCSS-التصيد
https://github.com/juanfran/postcss-trolling
يمكن لجميع الأدوات السابقة زيادة إنتاجية مصممي التخطيط الخاصة بك بشكل طفيف ، ولكن هذه الأداة تعطي ببساطة نتائج رائعة. أنا أوصي به بشدة.
استنتاج
PostCSS هي مساعدة جيدة لمصمم التخطيط. إذا لم يتم الاعتداء عليهم ، بالطبع. بالنسبة للعديد من المشكلات التي تستغرق وقتًا طويلاً ، توجد حلول جاهزة في شكل مكونات إضافية ، وعلى الرغم من أنها لا تتطور في الغالب ويبدو أنها مهجورة ، فإن هذا لا يتعارض مع استخدامها.