شما میتوانید بخش اول این مقاله را در این لینک مطالعه کنید
یک اشتباه رایج در میان توسعه دهندگان، این است که به استایل‌بندی در مقایسه با باقی بخش‌های کد، اهمیت کمتری می‌دهند.
از سال‌های اولیه CSS تا به حال، یک روش خیلی رایج برای تجمع همه چیز در یک stylesheet، و ساخت یک کابوس نگهداری بزرگ وجود دارد.
در بخش قبلی این مقاله، پیش پردازنده‌ها را مورد بررسی قرار دادیم. در بخش دوم این مقاله همراه ما باشید...
پس پردازنده‌ها (post-processors) (یا فقط «پردازنده‌ها»؟)
در تئوری، یک پس پردازنده ابزاری است که ورودی‌اش یک فایل CSS می‌باشد، که ورودی آن هم یک فایل CSS تغییر شکل داده شده است. دقت کنید که یک پس پردازنده با پیش پردازنده‌ها تفاوت دارد، و هیچ زبان دیگری را شامل نمی‌شود؛ فقط CSS خالص.
پس ما درباره چه نوع تغییر شکلی صحبت می‌کنیم؟ خب، پاسخ «چند نوع» است. در اینجا چند مثال خوب از پلاگین‌های پس پردازنده را مشاهده می‌کنید:
- Autoprefixer: به طور خودکار پیشوندها را بر حسب مرورگری که می‌خواهید پشتیبانی کنید، شامل می‌کند.
- PostCSS Assets: مسیرهای دارایی، خرد کردن cache، ابعاد تصویر و inline کردن تصویر base64 را مدیریت می‌کند.
- cssnano: CSS شما را کاهش می‌دهد.
- Font Maggician: به طور خودکار @font-faceها را ایجاد می‌کند.
- postcss-color-palette: شما را قادر می‌سازد تا از نام‌های رنگ CSS بومی مانند blue، purple، aqua، yellow و باقی موارد از جعبه رنگ خودتان استفاده کنید، و هر ارجاع را با رنگی که مشخص می‌کنید، جایگزین کنید.
- stylint: کد شما را آنالیز می‌کند، تغییرات و بهبودهایی را پیشنهاد می‌دهد و (اگر بخواهید) آن‌ها را جایگزین می‌کند.
- postcss-spriter: تصاویر را از استایل‌شیت‌های شما استخراج می‌کند، یک sprite شامل تمام آن‌ها را ایجاد می‌کند و ارجاع‌های اصلی را جایگزین می‌کند تا از یکی از آن‌ها استفاده کند.
تمام مثال‌های بالا، پلاگین‌های PostCSS هستند. PostCSS ابزاری است که توسط بسیاری از نام‌های برتر در زمینه پس پردازنده‌ها در نظر گرفته می‌شود.
گرچه، مقداری بحث در جامعه توسعه درباره معنای عبارت «پس پردازنده» وجود دارد. برخی می‌گویند که پیشوند «پس» (post) فقط وقتی معنا دارد که در مرورگر اتفاق بیفتد و نه قبل از آن، و در زمان توسعه.
بقیه هم با فرضیه «ورود CSS معتبر، خروج CSS معتبر» مشکل دارند؛ زیرا بسیاری پلاگین‌های پس پردازش از ویژگی‌های ناموجود یا سینتکس CSS نامعتبر استفاده می‌کنند تا کار خود را عملی کنند. برخی پلاگین‌ها حتی رفتار پیش پردازنده را با پشتیبانی مخلوط‌ها، وراثت‌ها، حلقه‌ها، شروط و دیگر امکانات که به طور بومی توسط CSS پشتیبانی نمی‌شوند، تقلید می‌کنند.
در اینجا برخی مثال‌های پس پردازنده را مشاهده می‌کنید که از سینتکس‌ها و ویژگی‌های غیر استاندارد استفاده می‌کنند:
- PreCSS: امکان استفاده از نشانه‌گذاری شبیه به Sass به همراه شروط، حلقه‌ها، importها، گسترش‌ها، مخلوط‌ها، تو در تویی انتخاب کننده و امکانات دیگر را فراهم می‌کند.
- Short: مختصر نویسی‌های بومی CSS را گسترش می‌دهد و مختصر نویسی‌های مخصوص خودش را فراهم می‌کنند تا قوانین مختصر بیشتری را ممکن کند.
- Write SVG: شما را قادر می‌سازد تا SVGهای خود را به طور مستقیم در CSS بنویسید.
- LostGrid: یک سیستم توری که بر پایه تابع CSS به نام calc ساخته شده است. این سیستم به استفاده از ویژگی‌های غیر استاندارد (مانند: lost-column، lost-row، lost-utility و lost-center) بستگی دارد.
پس از پذیرش عظیم PostCSS توسط توسعه دهندگان و صدها پلاگین ساخته شده برای یک تنوع عظیم از اهداف، خود نگهداران پروژه درک کردند که عبارت «پس پردازنده» دیگر معنا ندارد و رسما استفاده از آن را متوقف کردند.
به طور مستقل از بحث‌های معنایی درباره نام مفهوم، ظرفیت ابزاری مانند PostCSS غیر قابل سوال است و با توجه به انعطافش، می‌تواند هم با یک پیش پردازنده (مانند Sass، Stylus یا LESS) و هم به عنوان جایگزینی برای آن (مثلا از طریق پلاگین‌هایی مانند PreCSS) استفاده شود.
CSS-in-JS (CSS در JavaScript)
انفجار React، تعدادی از مفاهیم را میان توسعه دهندگان frontend معروف کرده است؛ مانند برنامه‌نویسی تابعی، برنامه‌نویسی واکنش‌پذیر، معماری Flux و برخی موارد دیگر.
یکی از جدیدترین گرایش‌های زاده شده در دنیای React، CSS-in-JS نام دارد. این گرایش برابر است با نوشتن کد استایل در JavaScript، و رندر کردن نتایج در CSS حین اجرا شدن. معروف‌ترین کتابخانه در این دسته، قطعا styled-components می‌باشد، اما گزینه‌های مرتبط دیگری مانند JSS، Radium، Emotion و Aphrodite هم وجود دارند.
Christopher Chedeau، یک مهندس frontend در Facebook، معمولا به عنوان پیشگام در CSS-in-JS یاد می‌شود. او این ایده را در هنگام کار در گروه React در سال ۲۰۱۵ به دست آورد.
وقتی که این شخص CSS-in-JS را به وجود آورد، هدف اصلی‌اش این بود که ۷ مشکل CSS را برطرف کند:
- فضای نام global: هر کلاس CSSای یک مشخص کننده global است و به مانند JavaScript، این مسئله مستعد به برخی تداخل‌های ناخواسته است.
- Dependencyها: اگر کامپوننت A به استایل‌شیت B وابسته است که نتوانسته است بارگذاری شود، شما احتمالا کامپوننتی با یک ظاهر مشکل‌دار را خواهید دید. این معمولا برای هشدار دادن به نگهدارنده درباره این که چیزی مشکل دارد، کافی است. گرچه، اگر همین استایل‌شیت مشابه از پیش در جایی دیگر از برنامه بارگذاری شده بود، کامپوننت A هیچ مشکلی در استایل‌بندی نخواهد داشت و توسعه دهنده‌اش هیچ وقت شک نخواهد کرد که باگی در آن وجود دارد.
- حذف کردن کد بدون کاربرد: ردیابی و حذف کلاس‌هایی که دیگر استفاده نمی‌شوند، سخت است.
- کاهش: روند کاهش CSS استاندارد، محدود است؛ زیرا شما نمی‌توانید کلاس‌ها را بدون بروزرسانی ارجاع‌های موجود در HTML مجددا نامگذاری کنید.
- به اشتراک گذاری constantها: اغلب ضروری است که مقادیر را بین JavaScript و CSS به اشتراک بگذارید. ما ممکن است که امروزه ویژگی‌های سفارشی CSS داشته باشیم، اما در سال ۲۰۱۴ راه‌های خوبی برای رفع این مشکل وجود نداشت.
- تفکیک غیر قطعی: یک عنصر HTML می‌توانند یک ویژگی CSS داده شده برای تنظیم مقادیر مختلف در چندین قانون را داشته باشد. اگر انتخاب کننده آن مقادیر، مشخصه مشابهی را داشته باشند، طبق «رفتار آبشاری» آخرین موردی که تفسیر شده است مبارزه را پیروز می‌شود. اگر یکی از این قوانین در یک استایل‌شیت که به صورت ناهمگام بارگذاری شده است، تعریف شده باشد، پیش بینی این که کدام مورد در آخر خوانده می‌شود سخت است.
- جداسازی: فرض کنید که شما در حال استفاده از یک کامپوننت ساخته شده و نگهداری شده توسط یک گروه دیگر هستید، اما می‌خواهید که نوع دیگری از این کامپوننت را با چند تغییر بصری مانند رنگ پس‌زمینه یک دکمه بسازید. به طور ایده‌آل، شما باید ساخت این تنوع را با تیم مسئول مذاکره کنید. گرچه احتمالا مهندسی که به این تغییر نیاز دارد، با تجزیه و تحلیل ساختار داخلی کامپوننت و استایل‌بندی آن از طریق انتخاب کننده‌ها، خودش آن را اعمال خواهد کرد. این یک مشکل است؛ زیرا هر تغییری در HTML ممکن است سفارشی‌سازی‌هایی که توسط گروه‌های دیگر اعمال شده‌اند را از بین ببرد. (که احتمالا برای کار کردن به صورت تصحیح، به یک ساختار مشخص بستگی دارد)
یک مثال عملی
من از styled-components برای نمونه‌سازی این مفهوم استفاده خواهم کرد:
import React, { Component } from 'react';
import styled from 'styled-components';
const Title = styled.h1`
color: white;
font-size: 2rem;
`;
const Content = styled.div`
background: blue;
padding: 2rem;
`;
class Example extends Component {
render() {
return (
<Content>
<Title>Hi everyone!</Title>
</Content>
);
}
}
export default Example;
برای کسانی که مقداری دانش درباره React دارند، مثال بالا خودش خودش را توضیح می‌دهد. متغیر constant با نام Title و Content، کامپوننت‌های React معمولی هستند، اما استایل سفارشی‌ای دارند.
نشانه‌گذاری styled.div’’ یک ویژگی بومی ES2015 است و به عنوان «Tagged Template Literal» شناخته می‌شوند. در این زمینه، این نشانه‌گذاری ما را قادر می‌سازد تا به صورت دینامیک استایل کامپوننت را بر پایه ویژگی‌هایش مدیریت کنیم؛ مانند این مثال:
const SignInButton = styled.button`
font-size: ${
props => props.standout ? '2rem' : '1.4rem'
};
`;
CSS-in-JS: یک ایده خلاقانه و بحث برانگیز
در حالیکه این مسئله حقیقت دارد و کتابخانه‌هایی مانند styled-components به طور وسیع توسط جامعه شناخته شده و استفاده می‌شوند، یک عدم اعتماد یا حتی طرد کردن قابل توجه نسبت به مفهوم CSS-in-JS در میان تعداد زیادی توسعه دهندگان وجود دارد، و بسیاری از افراد، اهداف اصلی آن را زیر سوال می‌برند. علت‌های مختلفی برای این مسئله وجود دارد، اما واضح‌ترین آن‌ها عدم راحتی در تعریف استایل‌ها در یک فایل JavaScript است.
حقیقت این است که برخی از مشکلاتی که CSS-in-JS می‌خواهد برطرف کند، امروزه راه حل‌های دیگری هم دارند. ماژول‌های CSS یک مثال خوب هستند، که شما را قادر می‌سازند تا استایل‌شیت‌ها را به روشی خوب ماژولار کنید، و از تداخل‌های میان شناسه‌های global جلوگیری کنید.
به علاوه، آن‌ها همچنین می‌توانند با یک پیش پردازنده ترکیب شوند. استفاده استوار از یک قراداد نامگذاری مانند BEM، همچنین از این مشکلات جلوگیری می‌کند. ویژگی‌های سفارشی CSS که از پیش یک پشتیبانی مرورگر خوب دارند، شما را قادر می‌سازند تا مقادیر را بین CSS و JavaScript به اشتراک بگذارید.
نتیجه گیری
جایگزین‌های مدرنی برای CSS خالص وجود دارند. هیچ راه حل بی نقص یا جهانی‌ای میان آن‌ها وجود ندارد، و هر کدام خوبی‌ها و بدی‌هایشان را دارند. همه چیز بستگی به توسعه دهنده دارد که بهترین مورد را برای هر پروژه انتخاب کند.
چیزی که مهم است، این است که توسط محدودیت‌های Vanilla CSS در پروژه‌هایی با اندازه نسبی یا با یک چشم‌انداز رشد منطقی احاطه نشوید، و از این که به علت ندانستن گزینه‌های موجود، در نگهداری استایل‌شیت‌های خود به مشکل بر بخورید، جلوگیری کنید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید