פתרון תקלות ב-SASS

איך מבצעים דיבוג של תקלות ב-SASS ואיך מוצאים את השורה הרלוונטית ב-SCSS מתוך קובץ ה-CSS המקומפל.

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

מציאת התקלה ב-CSS המקומפל

עם פיירבאג או כלי המפתחים של כרום או אפילו אקספלורר, קל לבצע תחקור ובדיקה מעמיקים של ה-CSS, לראות מה מספר השורה שאנו רוצים לשנות או לתקן, לגשת אל קובץ ה-CSS ולתקן. אבל מה עושים עם קובץ ה-CSS המקומפל? הרי אנו צריכים לדעת בדיוק את מספר השורה של קובץ ה-SCSS שאחראי לבלגן. מה עושים?

הדפסת מספרי שורות של קבצי SCSS בקובץ ה-CSS המקומפל

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

שורת מקור של SCSS בקובץ CSS מקומפל
שורת מקור של SCSS בקובץ CSS מקומפל

איך עושים את זה?

אם אנו עובדים בסביבת חלונות עם SCOUT, אפשר לראות ב-Configure שאפשר לבחור output mode של Development. בחירה ב-output mode הזה תציג לנו את מספרי השורות של המקור ב-SCSS בקובץ ה-CSS המקומפל. גם אם עשינו import לקובץ SCSS אחר.

שינוי input mode ב Scout
שינוי input mode ב Scout

אם אנו עובדים על לינוקס, צריך להוסיף את הפרמטר l –line-numbers- למשל:


sass --watch input:output  -l --line-numbers

דיבוג סקריפטים מורכב יותר

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


@debug here can be anything including variables and numbers here is an example 12px + 34px

מיד כשהקובץ יקומפל אני אראה על הקונסולה (ובקונסולה בלבד) את הטקסט הבא:


input/test.scss:8 DEBUG: here can be anything including numbers here is an example 46px

שימושי מאד, במיוחד במקרים של לולאות. שימו לב שאין שום הדפסה בקובץ ה-CSS המקומפל.

הדפסת אזהרה

מדובר במשהו די איזוטרי, אבל טוב לדעת אותו. הוא שימושי במיוחד אם אנו יוצרים mixin מורכב ורוצים להדפיס אזהרה אם מישהו מששתמש ב-mixin לא כמו שצריך. זה שימושי אם אתם מעדכנים mixin מסוים במערכת שלכם ורוצים לוודא שאם יש מישהו שמשתמש בו, הוא יקבל אזהרה. הסינטקס הוא דומה לחלוטין לדיבוג והוא נראה כך: warn@
ההבדל בינו לבין debug הוא שכאן יודפס לי trace. למשל, אם אני אשתמש בדוגמה הזו:


@mixin adjust-location($x, $y) {
  @if unitless($x) {
    @warn "Assuming #{$x} to be in pixels";
    $x: 1px * $x;
  }
  @if unitless($y) {
    @warn "Assuming #{$y} to be in pixels";
    $y: 1px * $y;
  }
  position: relative; left: $x; top: $y;
}

a {
	@include adjust-location(10, 10)
}

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


WARNING: Assuming 10 to be in pixels
         on line 3 of input/test.scss, in `adjust-location'
         from line 16 of input/test.scss

WARNING: Assuming 10 to be in pixels
         on line 7 of input/test.scss, in `adjust-location'
         from line 16 of input/test.scss

כפי שציינתי, מקרה איזוטרי, אבל טוב לדעת. חדי העין מביניכם שמו לב לכך שב-mixin אני משתמש במשהו מאד מוזר! פונקציה שנקראת unitless והיא מחזירה לי true או false. מאיפה הפונקציה הזו מגיעה? על זה נדבר במאמר הבא – פונקציות מובנות ב-SASS.

פוסטים נוספים שכדאי לקרוא

ספריות ומודולים

מציאת PII באמצעות למידת מכונה

כך תגנו על משתמשים שלכם שמעלים מידע אישי רגיש כמו תעודות זהות באמצעות שירות אמאזוני.

תמונת תצוגה של מנעול על מחשב
פתרונות ומאמרים על פיתוח אינטרנט

הגנה מפני XSS עם Trusted Types

תכונה ב-CSP שמאפשרת מניעה כמעט הרמטית להתקפות XSS שכל מפתח ווב צריך להכיר וכדאי שיכיר.

עבודה בהיי טק

איך מראיינים סניורים?

השיטה שלי לבדיקת התאמה טכנית למתכנתות ולמתכנתים בכירים עם כמה שנות ניסיון.

גלילה לראש העמוד