כלי לבדיקת בעיות ב-CSS לפני שהן נוצרות

הדפדפן לא תומך ב-CSS שלכם? ככה תדעו על זה מראש
CSS3 icon

לפני כמה חודשים התכבדתי להופיע בפודקאסט "מפתחים חסרי תרבות". בפודקאסט שמחתי לדבר על CI שזה ראשי תיבות של Continuous Integration. אני ממליץ לכולם לשמוע את הפרק פה.

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

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

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

איך עושים את זה? באמצעות כלי קטן שנקרא doiuse והוא עובד מעולה בכל שפה שהיא ועל כל תוצר שהוא. אפשר להריץ אותו גם על SCSS וגם על קבצי CSS מקומפלים. איך הוא עובד? הכי פשוט שיש:

  1. מתקינים באמצעות npx doiuse
  2. מפעילים בנוסח הבא משורת הפקודה:
doiuse --browsers "ie >= 10" ./public/**/*.css 

בהנחה שתיקית ה-CSS שלנו נמצאת ב-Public. מה שחשוב הוא להוסיף את הפרמטר, כאן הוספתי למשל כלל שאני רוצה לתמוך בכל דפדפן שהוא אקספלורר מ-10 וצפונה. אבל יש הרבה מאוד אפשרויות לשילובים שונים. הכלי הזה נסמך על browserlist שכולם בערך משתמשים בו.

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

.some-component {
  position: sticky;
  top: 0;
}

ותריצו את הכלי, או בבילד או אפילו מקומית אצלכם באופן אוטומטי בכל פעם שעושים commit, אז תקבלו הודעת שגיאה:

doiuse --browsers "ie >= 11" ./public/*/.css
CSS position:sticky not supported by: IE (11) (css-sticky)

זה יהיה מבאס מאוד, אבל הרבה יותר מבאס יהיה לגלות את זה כשה-QA יגיע אליכם בפנים מכורכמות למשל.

אם אתם לא מכירים את אלעד שכטר או את קבוצת הפייסבוק שלו CSS Masters, אני ממליץ לכם לבדוק! קבוצות נוספות מומלצות יש פה ואתם מוזמנים לבדוק (או להוסיף שם קבוצות ודברים מענינים).

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

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

פתרונות ומאמרים על פיתוח אינטרנט

המנעו מהעלאת source control לשרת פומבי

לא תאמינו כמה אתרים מעלים את ה-source control שלהם לשרת. ככה תמצאו אותם וגם הסבר למה זה רעיון רע.

תמונה מצוירת של רובוט שמנקה HTML
יסודות בתכנות

סניטציה – למה זה חשוב

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

צילום מסך של סוואגר
יסודות בתכנות

openAPI

שימוש בתשתית הפופולרית למיפוי ותיעוד של API וגם הסבר בסיסי על מה זה API

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