MasterScripter

SASS – לכתוב את זה נכון

כשיותר ויותר אנשים עוברים לכתוב SASS (וטוב שכך!), אפשר להגיד ששימוש ב- SASS כבר כמעט נהיה סטנדרט היום. בין אם זה בשביל הנוחות שלנו כמפתחים, בין אם זה על מנת להבין ולתחזק קוד לאורך זמן ובין אם זה בשביל שמפתחים חדשים יוכלו להבין מה קורה במהרה, מישהו צריך לעשות כאן סדר – ואני הולך לנסות לעזור לכם לעשות סדר:
מדריך כתיבה נכונה (יש שיגידו Style Guide 🙂 ) ל- SASS.

הקדמה, או איך להיות פתית שלג ייחודי

העצות והקווים המנחים שאני הולך לפרוש לפניכם במדריך הזה מורכבים בעיקר מחוקים "נפוצים", ואינטרפרטציה אישית שלי.
החוכמה בדברים האלה היא לנסות ולהבין את ההגיון שעומד מאחורי כל "חוק" כזה או אחר, ולאמץ אותו רק אם הוא עושה הגיון (עוד לא המציאו לזה ביטוי נורמלי בעברית?) בעיניכם.
בנוסף לזה, אין חכם מבעל ניסיון – עם הזמן והשימוש מגלים דפוסים ו"חוקים" שטובים ונכונים לנו.
מאוד יכול להיות שתגלו במדריך הזה דברים שאולי עובדים יפה מאוד עבורי כשאני כותב SASS, אבל אתם פחות מתחברים לסגנון – הפעילו שיקול דעת וקחו רק את מה שיעזור וישפר אתכם.

הבסיס טמון בCSS אליו אתם רגילים

אנחנו כבר יודעים ש- SASS מתקמפל לCSS, אז מן הסתם שחוקי הכתיבה אליהם אתם רגילים מCSS יחולו גם בSASS. העקרונות המנחים אותנו בכתיבת CSS הם גם עקרונות הבסיס של הכתיבה בSASS. אל תמהרו לזנוח את החוקים שעובדים לכם בCSS!

אם לא עבדתם בצורה מסודרת בCSS, אתם מוזמנים להעיף מבט במבחר מדריכי כתיבה שונים לCSS שריכזו CSS-TRICKS. בכל מקרה, נעבור בזריזות על כמה עקרונות ליבה שחוזרים בכל המדריכים השונים:

  1. הזחה – חובבי TAB או חובבי רווח בודד, העיקר שלא תשכחו לבצע הזחה כלשהיא. הזחה שומרת על היררכיה בקוד ומקלה על הקריאה בו.
  2. שמות – חשוב שתהיה לכם תוכנית מסודרת למתן שמות לקלאסים ו-ID שונים. כלל אצבע: השמות צריכים להיות קצרים ככל האפשר, וארוכים ככל הנדרש.
  3. קלאסים וIDים – למעט מקרים מאוד ספציפיים, לא נהוג להשתמש בIDים בCSS (אני יודע שזו נקודה רגישה, לפני שאתם מזדעקים – יש הסבר מורחב ממש עוד מעט 🙂 )
  4. אחד בשורה – השתדלו לשים סלקטורים וכללים שונים בשורות נפרדות.
  5. עקביות ואחידות – בין אם זה בהזחה, ברווחים, בסוגריים מסולסלים ומיקומם, באופן כתיבת ההערות ובעצם בהכל. חשוב מאוד לשמור על עקביות ואחידות לאורך הקוד, ולא לקפץ מסגנון כתיבה אחד לאחר.

CLASSים ולא IDים

כשאומרים, ואני אומר, להשתמש בCLASSים ולא בIDים – הכוונה היא כמובן רק בעיצוב הדף (הCSS). אין מניעה להשתמש בID בHTML, בג'אווהסקריפט וכדומה.
הסיבה שבגינה אני ממליץ בחום להימנע מID בCSS היא פשוטה – הספציפיות וכוח העדיפות של ID בCSS היא גבוהה מאוד. רוצה לומר – בהרבה מקרים אנחנו נדרשים לדריסת הגדרות, אולם ברגע שID מעורב בסיפור, הכל מסתבך ומסתעף.
למה לפתוח תיבות פנדורה כשאפשר פשוט להשתמש בCLASSים?

SASS – סמנטיקה

ההמלצות הבאות הן יותר בגדר "חוקים", ופחות בגדר "הכוונות כלליות". מדובר בדברים יותר סמנטיים שעליהם יש להקפיד הן מפאת סידור ונראות הקוד, והן מפאת תקינות הקוד. אם אתם נתקלים במשהו שאתם לא כל כך מבינים, אל תהססו לחזור ולעיין במדריך המלא ל- SASS!

שמות

מעבר לשמות הרגילים בCSS, ב- SASS ניתן לתת שמות למספר דברים נוספים, ביניהם משתנים, פונקציות, מיקסינים, וכו'.
אנחנו נדבוק לחוקים המוכרים של CSS, כששמות ייכתבו באותיות קטנות, ומקף ישמש אותנו להפרדה בין מילים. כמו כן, הכי חשוב הוא שהשמות יהיו ברורים ויעבירו את המשמעות שהם צריכים להעביר, ככה נחסוך את "זמן הפענוח":

 קבועים

החריגה היחידה מאותיות קטנות תהיה בקבועים – אומנם לא נתקלים בהם בהרבה פרוייקטים, אבל כשכן נתקלים חשוב לתת להם שמות באותיות גדולות בלבד:

הערות ודוקיומנטציה

קודם כל – תתחילו לכתוב הערות! ואם אתם כבר כותבים, תכתבו עוד!
החשיבות של הערות היא מכרעת, במיוחד בטיפול בפרוייקטים לאורך זמן. אל תגרמו למתכנת שיבוא אחריכם למצוא את עצמו אומר:
"אלוהים-ישמור-אותי-לא-אני-כתבתי-את-זה-למה-זה-מגיע-לי".
תכתבו הערות, תסבירו את עצמכם, תסבירו את תהליך החשיבה שלכם, תסבירו איך הגעתם לחישוב של כל מיני מספרי קסם למיניהם, תרחיבו על חשיבות של סדר הגדרות מסויים, תסבירו על מבנה או מטרה וכו'.
אם CSS יכולה להיות טריקית לפעמים, תחשבו כמה נורא זה עלול להיות בSASS – כשהדברים שאתם כותבים בכלל מתקמפלים לדברים אחרים, הכל מחולק לקבצים שונים, ולפעמים הגדרות נשאבות מדברים שלא באמת קיימים (פלייסהולדרים למשל). הרבה כאב ראש יכול להיחסך עם הערות, אז אל תפחדו לכתוב אותן ובטח שאל תתקמצנו עליהן! תזכרו שאין דבר כזה יותר מידי תיעוד.

שימו לב, הערת-שורה אינה מתקמפלת לקובץ הCSS הסופי, לעומת הערת-בלוק שתופיע גם בקובץ הפלט שלנו. נצלו את זה לטובתכם, והפעילו שיקול דעת אילו הערות צריכות להישאר "פנימיות", ואילו צריכות להופיע גם בקובץ הCSS שלנו.

לSASS, בדומה לשפות תכנות שונות, יש אופציה לייצא דוקיומנטציה שאנחנו מכינים בעצמנו לקוד שלנו.
נהוג להכניס לדוקיומנטציה כל משתנה, פונקציה, מיקסין ופלייסהולדר שאנו מתכוונים להשתמש בו לאורך כל הקוד שלנו.
הדוקיומנטציה תיעשה באמצעות הערות עם שלושה לוכנסים(/).

מדיה קוואריס

מדיה קוואריס, מאבני היסוד של בניית אתר רספונסיבי, מקבלות שיפור ב- SASS. מן הסתם, השינויים שנעשים בטכנולוגיה – יציאת טלפונים חדשים בגדלים שונים למשל – תכופים יותר מהשינויים שאנחנו מבצעים בקבצי CSS באתרים שכבר נמצאים באוויר (על פי רוב כמובן). בSASS, אנחנו יכולים לתת למדיה קוואריס שמות, על מנת לראות את הדברים בצורה נהירה יותר.

מנגד, יש גישה הטוענת שאל לנו לכבול את המדיה קוואריס שלנו למכשירים מסויימים, שכן הם עלולים להפוך ללא רלוונטיים (בארה"ב אחוז המשתמשים באייפון 3G ומטה מתוך כלל המשתמשים באייפון עומד על 0.2% בקירוב). אני אומנם חולק קצת על הגישה הזו, שכן היא דוחפת לשימוש במעט מדיה קוואריס ויותר כלליות – בעוד אני דוגל בשיטת הפיקסל פרפקט. ועדיין, מן הראוי להציג אותה:

הרחבות

כאשר אנחנו משתמשים ביכולת ההרחבה שלנו, הלא היא ה@extend המצויין, עלינו להיזהר.
ראשית, מומלץ להימנע מלהרחיב סלקטורים, אלא להשתדל ולהרחיב אך ורק פלייסהולדרים.
כאשר כן מרחיבים סלקטור או קלאס, יש להיזהר מהרחבת סלקטורים מרוכבים (למשל, סלקטורים המייצגים "בן ישיר").
בנוסף, כאשר משתמשים ב@extend, שווה לשקול אם @mixin לא יתאים טוב יותר לסיטואציה – כתב על כך בהרחבה הארי רוברטס, שווה לקרוא.

מיקסינים

כלל האצבע לגבי מיקסינים הוא די פשוט – אם מזהים קבוצת הגדרות CSS שתמיד מופיעה יחד, אפשר לשים אותה בתוך מיקסין במקום.
שימו לב שלגבי מיקסינים ללא ארגומנטים, אין צורך לרשום את הסוגריים הריקים. עצם השימוש ב@include מעיד על כך שמדובר במיקסין:

SASS – סגנון כתיבה

אחרי שעברנו על ה"חוקים" הראשוניים שלנו, הגיע הזמן לדברים שהם יותר מורי דרך מאשר הגדרות ברורות.
מעין אוסף של כללים ועצות שיהפכו את הקוד שלכם לנקי ושמח 🙂

סדר הגדרות – קודם הרחבות, אחר כך מיקסינים, ובסוף הגדרות רגילות

כשאנחנו כותבים ב- SASS, בניגוד לCSS הרגיל, יש לנו יותר מרק "הגדרות רגילות", אלא גם הרחבות ומיקסינים.
מכיוון שלפעמים נרצה לדרוס הגדרה ספציפית מתוך הרחבה או מתוך מיקסין, עלינו להקפיד על סדר כתיבתם – הרחבות, מיקסנים, כללים רגילים.

סדר בקינון – קודם פסאודו-קלאסים, אחר כך פסאודו-אלמנטים, ולבסוף סלקטורים

עצם העובדה שאנחנו משתמשים בקינון ב- SASS ממש כמו בHTML, עלול ליצור קצת בלגן בהבנת הקוד.
זו הסיבה שבגינה חשוב לשמור על סדר הקינון בכתיבה, ממש כמו שאנחנו שומרים על סדר ההגדרות:

הגבלת קינון

על אף שקינון היא יכולת נפלאה (ולא רק עבור ציפורים..), טמונה בה סכנה של "קינון יתר".
לרוב, אם אתם משתמשים בקינון של יותר מ4 רמות, כנראה שמשהו התפספס בדרך – ויכולתם לכתוב את הקוד בצורה יעילה יותר.
הקפידו לבדוק את עצמכם, שכאשר קיננתם יותר מ4 רמות – יש לכך הצדק מבחינת הקוד, ואין דרך יעילה יותר לכתוב אותו מחדש.
בנוסף, הקפידו שכל בלוק המכיל קינון ב- SASS לא יעלה על 50 שורות. הסיבה לכך היא שבדרך כלל כאשר הקינון ארוך יותר מ50 שורות, הוא לא נכנס במסך אחד של עורך קוד, מה שמקשה עלינו להסתכל על הקוד בעצם.

צבעים ומספרים חשובים בתוך משתנים

הכלל פה הוא מאוד פשוט – אם יש מספר בעל משמעות, או לחלופין שנמצא בשימוש תדיר (זה בדרך כלל קורה ביחד), נכניס אותו לתוך משתנה. אותו דבר לגבי צבעים – צבע שנמצא בשימוש חוזר או שהוא בעל משמעות, גם אותו נכניס לתוך משתנה. כך ברגע חסכנו את בזבוזי הזמן על איתור צבע שחמק, או גלילה אינסופית למעלה במטרה למצוא איזה מספר קסם נעלם.

קינון מדיה קוואריס

מעבר לעניין מתן השמות למדיה קוואריס עליו כבר עברנו, קיים דיון עתיק בקהילת משתמשי הSASS לגבי השימוש הנכון ביותר במדיה קוואריס בSASS. מצד אחד – הSASS נותן לנו את היכולת לקנן מדיה קוואריס פר אלמנט, ובכך לשים סוף לריכוז המדיה קוואריס. הלוגיקה שמאחורי השיטה הזו ברורה – מעבר לחיסכון בקבצים, בסופו של יום כשמבצעים תיקונים או מתאימים דברים לרזולוציות מסויימות, ההתאמות נעשות פר רכיב – בדיוק כמו שאם נשנה לו הגדרה מסויימת נלך למקום בו כתבנו את הסלקטור בקובץ, אין סיבה שעל מנת לשנות לו הגדרה שנוגעת ברזולוציה כזו או אחרת נאלץ לתור אחריו בים של סלקטורים המרוכזים בתוך מדיה קווארי.
ומנגד, חסרון השיטה הוא "ריבוי המדיה קוואריס" בקובץ הCSS הסופי.

אני ממליץ על גישה זו על אף ריבוי המדיה קוואריס, מ3 סיבות מאוד פשוטות:

  1. במבחני ביצועים, לא נמצאו הבדלים מספיק משמעותיים בין שימוש ב2000 מדיה קוואריס משוכפלים לבין כשהם מרוכזים.
  2. אם הנראות של הקובץ הסופי מטרידה, אפשר להשתמש במשימת Grunt על מנת לאחד את המדיה קוואריס.
  3. אני אישית מאמין שבעתיד ימצאו פתרון מובנה ב- SASS לבעיית שכפול המדיה קוואריס.

חשוב לציין: מבחני הביצועים מבוססים על מדיה קוואריס זהים(!), אם יש לנו 2000 מדיה קוואריס שונים בקוד, זה כבר יכול להשפיע מאוד על הביצועים.

חשוב לציין 2: מבחני הביצועים מתייחסים לקובץ דחוס. אם אתם לא דוחסים את הCSS לפני העלאה..הגיע הזמן!

ארכיטקטורה

אי אפשר לדבר על כתיבה נכונה ב- SASS בלי להזכיר את עניין הארכיטקטורה.
הבעיה היא, שעל ארכיטקטורה בלבד אפשר לכתוב שני פוסטים שונים..
בקצרה ובנקודות עיקריות – הכי חשוב שיהיה לכם מבנה מסודר לפריסת הקבצים והתיקיות ב- SASS.
ישנן ארכיטקטורות שונות ומשונות לSASS, והעצה שלי היא שתחקרו את הגישות השונות עד שתמצאו את זו שהכי מתאימה לכם.
הגישה אשר אני מצאתי שעובדת הכי טוב בשבילי היא גישת ה7-1:

תיקיית UTILS

תייקית העזרים שלנו מכילה, איך לא, את עזרי הSASS שלנו! בתוכנה נכניס קבצי משתנים (גלובליים), פונקציות, מיקסנים, פלייסהולדרים וכדומה.

תיקיית BASE

תיקיית הבסיס מכילה את קטעי הקוד ה"מוכנים מראש", אשר זהים כמעט לחלוטין בין פרוייקט לפרוייקט – אך צריכים להכלל בכל הפרוייקטים. בדרך כלל, ייכנסו שם קבצים כמו קובץ האיפוס (reset) שלנו, פונטים וטיפוגרפיה, וכו'.

תיקיית LAYOUT

תיקיית הפריסה שלנו תכיל בתוכה את כלל הקבצים אשר מתייחסים לפריסת האתר – header, footer, גרידים, תפריט וכו'.

תיקיית COMPONENTS

תיקיית הרכיבים, שלעיתים גם נקראת מודולים (modules), תכיל קבצים המתייחסים לרכיבים קטנים יותר וכלליים יותר באתר – וידג'טים, סליידרים, טוענים (loaders) וכדומה. זו התיקייה שאנחנו רוצים שתכיל הכי הרבה קבצים – ככל שהאתר מבוסס יותר רכיבים, כך הוא גנרי ומודולרי יותר.

תיקיית PAGES

בטח כבר ניחשתם..תיקיית הדפים מיועדת לקבצים המתייחסים לדפים שונים באתר. הרבה פעמים אנחנו צריכים לתת הגדרות ספציפיות לדפים מסויימים בלבד, וזה בדיוק המקום בשביל הקבצים הללו.

תיקיית THEMES

באתרים גדולים יותר ואפליקציות, יש לנו לעיתים מספר ערכות נושאים שונות. הדרך הבטוחה ביותר לנהל את העניין הזה הוא עם תיקיית ייעודית, המכילה קבצים ספציפיים לכל ערכת נושא.

תיקיית VENDORS

אחרונה חביבה היא תיקיית הvendors – תיקייה המכילה את כל קבצי הCSS והSASS של ספריות חיצוניות ופרימוורקים. חשוב שתהיה הפרדה ברורה בין קבצים כאלה, שמגיעים ממקורות חיצוניים, לבין הקבצים שלנו בפרוייקט, וזה בדיוק מה שהתיקייה הזו באה לעשות.

כמובן שאת כל הקבצים בתיקיות המסודרות יפה-יפה שלנו, נייבא בקובץ הmain.scss.

פיצול הכתיבה לקבצים קטנים

אחד היתרונות הגדולים ביותר בSASS הוא השימוש בקבצים חלקיים (partials), אשר מאפשרים לנו לחלק את קובץ הCSS העצום להמון קבצים קטנים שמתקמפלים לקובץ הסופי. אם אתם נמצאים כאן, כניראה שכבר חוויתם את זה על בשרכם – ואתם יודעים איזה מדהים זה לגשת לקובץ ספציפי של רכיב במקום לתור אחריו בקובץ-בלתי-נגמר של CSS.
אז מה בעצם אני רוצה לומר? אל תחששו להשתמש ביכולת הזאת, ולפצל הקוד לקבצים קטנים ככל שמרגיש לכם טבעי והגיוני.

סדר בייבוא

אחרי שעברנו על הארכיטקטורה, מן הסתם שחשוב לעשות סדר גם בקובץ הראשי שלנו – הקובץ בו אנחנו מייבאים את כל הקבצים הקטנטנים. בכל צורת עבודה ישנו סדר @import שונה, למשל יש פרוייקטים שבהם הייבוא של תיקיית הvendors צריך להיות ראשון מכיוון שהוא הבסיס – למשל כשמשתמשים בbootstrap, ומנגד יש תצורות בהן הvendors מיובאים אחרונים.
הקפדה על סדר נכון ביבוא תיצור לנו גם מעין "תוכן עניינים" בקובץ הmain:

חשוב לציין: בדוגמא למעלה השתמשתי בטכניקה בה יוצרים קובץ נוסף לכל תיקייה הנקרא _all, ובו מייבאים את כלל הקבצים של אותה תיקייה, כך שקובץ הmain.scss שלנו מסודר יותר – עלינו לייבא רק את קובץ ה_all מכל תיקייה.

כיווץ לפני פרודקשן

גם ככה מעטים האנשים שלא מכווצים את הקבצים הרלוונטים לפני העלאה, אבל לאותם מעטים – הגיע הזמן לכווץ.
הכיווץ, במיוחד בSASS, הוא משמעותי. מעבר ליתרונות שבצמצום גודל הקובץ, הכיווץ (minify) גם מבצע אופטימיזציה לקובץ – מוריד הערות, מקצר שמות ארוכים, מוריד תווים מיותרים וכו'.
אל תחשבו, תכווצו!

קובץ SHAME

הגיע הזמן להודות באמת – אין מפתח שלא נתקל במשהו שהיה צריך לתקן בדוחק זמן, נבר בקוד וגילה שיש לו שתי אופציות:
לתקן את זה בכמה דקות בצורה מכוערת או להשקיע שעה ולשנות כמה דברים בקוד בצורה מעמיקה יותר על מנת לפתור את הבעיה באלגנטיות.
אם כבר אנחנו מודים באמת – אז גם אין מפתח שלא בחר בדרך הראשונה, every-once-in-a-while.
הכל בסדר, אני לא שופט..אבל יש לי הצעה לייעול!
תיקונים שנעשים בצורה מכוערת כזו בSASS, בצעו בקובץ בשם SHAME, וייבאו אותו אחרון מבין רשימת הייבוא בmain.scss.
כך תרגישו את הבושה עד שתתקנו את הבעיה בצורה הנקייה והטובה, ותוכלו להיפטר מהSHAME שלכם.
SHAME SHAME SHAME.

סיכומיישן

דווקא בגלל שהכתיבה בSASS שונה במקצת מהCSS, ודווקא בגלל שמה שאנחנו כותבים בSASS מתקמפל בסוף לCSS, אנחנו חייבים להקפיד על סגנון כתיבה מדוייק. זה בדיוק הדבר שאסור להקל בו ראש – עשו את המחקר שלכם, ואל תסתפקו בהמלצות שלי. חפשו מדריכים נוספים (טוב נו, קישורים בהמשך..שלא תצטרכו להתאמץ), נסו בעצמכם, וצרו לעצמכם סגנון כתיבה אידאלי.
השיפור, כמו שאמרו גדולים וטובים ממני – יורגש מיד.
אבל הי, אם אתם כבר תותחים של SASS ויש לכם עצות משלכם – למה שלא תכתבו אותם בתגובות כאן? 🙂

מקורות וקריאה מעמיקה יותר

  1. עצות הכתיבה של CSS-TRICKS
  2. עצות הכתיבה והסמנטיקה של הוגו ג'ירודל
  3. ארכיטקטורה וארגון על פי דיויד קאורשיד

אם הגעת עד לפה, הגיע הזמן להירשם לניוזלטר!

Summary
Article Name
SASS - לכתוב את זה נכון
Description
הסבר מקיף על הדרך והחשיבות בבניית סגנון כתיבה אחיד ומסודר ב- SASS.
Author
Publisher Name
MasterScripter
Publisher Logo
אודות 
יזם בוטסטראפ, מתכנת ומנהל מוצר. שותף מייסד בקבוצת סיזן שמספקת שירותי פיתוח וליווי טכנולוגי לחברות וארגונים, וב-edge אתגרים בחינוך שמפתחת מוצרים דיגיטליים לבתי ספר. המייסד של PBC - מועדון ספרים מקצועי.

4 תגובות

  1. ערן

    5 בדצמבר 2016 - 19:56
    תגובה

    אחלה מאמר, מעולה למי שרוצה להכנס לזה, היה חוסך לי קצת בלאגן זה בטוח, אבל מה בקשר לvendor-prefix ?
    לא פעם ראשונה שאני רואה מאמר על sass שמראה את זה בדוגמאות קוד, אם כבר משתמשים בsass,שנועד להקל על החיים, וגם ככה צריך לקמפל ולכווץ, אז autoprefixer ממש מתבקש פה, בשביל מה צריך אפילו לדעת על השטות הזאת שמתישהו תעלם גם ככה…

    • שלומי זק

      6 בדצמבר 2016 - 11:40
      תגובה

      ערן – קודם כל תודה!
      אתה לגמרי צודק. מעבר לעובדה שהprefixים הם שטות שמתישהו תחלוף, אני לגמרי בדעה שאין שום סיבה שמפתח יתעכב באיזהשהיא רמה על vendor-prefix, וautoprefixer הוא בהחלט הפתרון לכך.
      הסיבה היחידה שבגינה לא ציינתי את הautoprefixer, היא שהוא לא חלק שמוטמע בSASS. ישנם autoprefixerים שונים, שפועלים בדרכים שונות – אבל בעצם מדובר בpostprocessor, שזה "הקצה השני" של SASS, הpreprocessor.
      אולי אכתוב פוסט שיוקדש כולו לנושא הprefix 😉

השאר/י תגובה לטל גרפי

לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *