scss ואני – כתיבה וארכיטקטורה

משך זמן קריאה: 5 דקות

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

זה לא חדש שאני עובדת ב investing.com ואני חלק מהצוות שעובד על ה-redesign של האתר. ה-redesign הוא תהליך מורכב ומאתגר מאספקטים רבים ובוודאי יש הרבה מה לכתוב עליו, אבל אני יכולה לספר רק על החלק שאני לוקחת בו חלק והוא כמובן ה-css+html. מתוך כל התהליך ניסיתי להוציא כמה תובנות בתקווה שיוכלו לסייע גם לאחרים, והנה הם לפניכם.

שני החלקים הראשונים של הפוסט שלי מבוססים על הפוסט של אלעד – CSS Architecture — Folders & Files Structure. מי מכם שרוצה לקרוא לעומק ובאנגלית מוזמן לקרוא שם 🙂

 

ארכיטקטורה

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

וכמובן הפוסטים של אלעד על ארכיטקטורה:

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

מבנה תיקיות scss

 

תכלס רוב היום יום שלי מתרכז בתיקיית parts, המחולקת ל 4 חלקים:

  1. elements
  2. components
  3. sequences
  4. entity

אז מה זאת החלוקה הזאת בכלל? החלוקה נועדה למיין את הקלאסים שלנו לפי השימוש בהם, ויש גם משמעות לסדר הקומפילציה שלהם, ומתוך כך, גם סדר ה"ייבוא" (@import) שלהם משמעותי:

// from most generic to specific
@import "partials/1-elements";
@import "partials/2-components";
@import "partials/3-sequences";
@import "partials/4-entities";
@import "partials/5-pages";

קצת פירוט:

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

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

sequences הם רצפים או סדרות, והכוונה לסדרות של כתבות, פוסטים וכדומה. כשם שהמבנה ה-HTML-י של components מכיל גם חלקים מתוך elements וכהמשך לאותם עקרונות היררכיים, גם קבצי sequences יכולים להכיל גם components וגם elements.

ואחרון חביב, entity: אלה קבצי סטייל של עיצוב ייחודי לאלמנט או קומפוננטה שכבר קיימים. למשל יש לנו את popup שהוא סטייל גנרי שמופיע תחת elements ומיועד לרכיב ה-popup באתר. אבל יש מצבים ש-popup מסוים ידרוש התאמות ייחודיות, וכאן נכנס ה-entity שמרחיב את האלמנט הגנרי. כמו למשל .e-datepicker.scss שנותן התאמות ייחודיות שיחולו רק על ה-popup של ה-datepicker.

 

הכל בשורה אחת

בעיקרון, כל קובץ מכיל סטייל שמיועד לחלק אחד בודד ולא יותר מזה, ולכן קל להבין ששֵם הקובץ יכיל את שם הקלאס. לדוגמא קובץ בשם _pie-chart.scss יכיל קוד שמיועד לתרשים פאי 🙂 והקובץ עצמו יהיה קטן ככל האפשר.

.pie-chart{
   &-wrapper{
      .graph-legend-item-color{background-color:var(--legend-color , $main-color);}
   }
   &-item-color{width:12px; height:12px; display:block; background-color:var(--legend-color , $main-color);}

   @media #{$break1}{
      &-wrapper{
         max-width:294px; margin-#{$start-direction}:auto; margin-#{$end-direction}:auto;
         .graph-legend{column-count:2; column-gap:24px; margin-top:24px;}
      }
   }
   @media #{$break2open}{
      &-wrapper{
         display:flex; align-items:center;
         .graph-legend{margin-#{$start-direction}:16px;}
      }

   }
}

מה שהופך את הקובץ לקצר הוא ללא ספק המינימליזם של קוד שהוא מצריך אבל גם אופן הכתיבה שלו. אם לפני שנתיים הייתם אומרים לי שיום אחד אני אכתוב css בשורה אחת הייתי או מתעלפת או נחנקת מצחוק. אני זוכרת שהעליתי את הפוסט הזה לקבוצה של css israel masters והתעלפתי כשאלעד כתב שהוא כותב בשורה אחת. אבל החיים מוכיחים לי שוב ושוב – never say never!

אז למה שורה אחת?

  • רואים את כל הסטייל כמעט בבת אחת
  • אופן הקריאה שלנו בריפרוף היא בצורה של האות F מה שמגביר את הקריאות של הקוד שלי כשאני מחפשת מידע:
    • קריאה של שם הקלאס (קו עליון של F)
    • ריפרוף על המאפיינים חשובים שלו שמופיעים ראשונים בשורה, על הקלאסים המשורשרים שלו (על שרשור קלאסים אפשר לקרוא בפוסט שלי: scss ואני – מעמיקים יחסים – תחת "קינון"), ועל הקלאסים שמופיעים בתוכו (הקו האנכי של ה-F)
    • אם יש צורך בקריאה מעמיקה – מעבר על כל המאפיינים לקריאה מעמיקה.

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

via GIPHY

שינוי בריווחים הוא עוד משהו משיטת הכתיבה של אלעד שאימצתי. רווח בודד בין מאפיין למאפיין ובלי שום רווח בין מאפיין לערך שלו:

/*Yes!*/
position:relative; display:flex; align-items:center;

/*Not any more*/
position: relative; 
display: flex; 
align-items: center;

 

code refactoring

לעבור על הקוד ולכתוב מחדש, לשנות שם של קלאס או לגמרי קונספט של חשיבה, להחליף את A ל-B, להחליף משהו שמוגדר ב-display:flex לגריד – כל אלה היו פעם מעבירים בי צמרמורת של פחד, ונמנעתי ככל יכולתי מלעשות את זה. אבל זה היה פעם! אני לא אכחיש, עדיין אני חרדה לפני שינוי שכזה, אבל אני לומדת להעריך את הצורך ב-refactoring. לומדת לאהוב את העובדה שאחריו, הקוד שלי יהיה יפה יותר, מדויק יותר, קצר יותר, מתוחזק יותר. למדתי לא להתאהב בקוד שלי, ולהבין שלא כל מה שנכתב ועובד צריך להישאר כמו שהוא. שינוי ושדרוג תמיד עושים טוב לקוד!

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

  2 תגובות ל “scss ואני – כתיבה וארכיטקטורה

כתיבת תגובה

האימייל לא יוצג באתר.