סאס Best Practices טיפים וכלים עבור מפתחים

הרבה כמו איך jQuery מהפכה וניל JavaScript, Sass חוללה מהפכה וניל CSS. רוב המפתחים שמלמדים את סאס מסכימים שהם לעולם לא ירצו לחזור. רבים גם מסכימים כי הבעיה הגדולה ביותר עם מפתחים חדשים היא דרך הם משתמשים בסאס, לא בס עצמה.

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

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

ארגון קבצים

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

אבל לעת עתה רק תסתכל על מבנה קובץ זה דוגמה מ DoCSSa. אני כבר מחדש את מבנה הקובץ הזה שאתה יכול לראות להלן:

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

בואו נלך דרך סגנון הארגון המוצע הזה כדי לבדוק את המטרה של כל תיקיה:

• / globals - מכיל קבצי Sass שמקבלים יישומי אתר כמו טיפוגרפיה, צבעים ורשתות
• / רכיבים - מכיל קובצי Sass עם סגנונות רכיבים כגון לחצנים, טבלאות או שדות קלט
• / סעיפים - מכיל קובצי Sass המוקדשים לדפים או אזורים ספציפיים בדף (עשויים לפעול בשילוב טוב יותר לתוך הרכיבים / רכיבים / תיקיות)
• / utils - מכיל כלי עזר של צד שלישי כגון Normalize שניתן לעדכן באופן דינמי באמצעות כלים כגון Bower.
• main.scss - קובץ Sass הראשי בתיקיית השורש שמייבא את כל האחרים.

זוהי רק נקודת התחלה בסיסית ויש הרבה מקום להתרחב עם הרעיונות שלך.

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

חלקיקי סאס חיוניים לשיטות העבודה המומלצות המודרניות. אלה מומלץ מאוד על ידי צוות העיצוב של Zurb ועל ידי רבים אחרים מפתחים מקצועיים.

הנה ציטוט מאתר האינטרנט של Sass המסביר חלקים:

“ניתן ליצור קבצי Sass חלקיים המכילים קטעי טקסט קטנים של CSS שניתן לכלול בקובצי Sass אחרים. זוהי דרך מצוינת modularize CSS שלך ולעזור לשמור על דברים יותר קל לשמור. חלק הוא פשוט קובץ Sass בשם עם קו תחתון מוביל. אתה יכול שם לזה משהו _partial.scss. קו תחתון מאפשר Sass לדעת כי הקובץ הוא רק קובץ חלקי, כי זה לא צריך להיות שנוצר לתוך קובץ CSS. חלקים Sass משמשים עם @import הוראה.”

כמו כן תסתכל על הודעות אחרות לגבי מבנה קובץ Sass:

• איך אני מבנית
• אסתטיקה סאס: אדריכלות וארגון סגנון
• מבנים מדריך שיסייעו לך לשמור על הקוד שלך

ייבוא ​​אסטרטגיות

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

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

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

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

@mixin linearGradient ($ top, $ bottom) background: $ top; / * דפדפנים ישנים * / background: -Moz-linear-gradient (למעלה, $ Top 0%, $ 100% למטה); / * FF3.6 + * / רקע: -webkit-gradient (ליניארי, שמאל למעלה, שמאל למטה, צבע להפסיק (0%, $ העליון), צבע להפסיק (100%, $ התחתון)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (למעלה, $ top 0%, $ 100% למטה); / * Chrome10 +, Safari5.1 + * / background: -o-linear-gradient (למעלה, $ top 0%, $ 100% למטה); / * Opera 11.10+ * / background: -ms-linear-gradient (למעלה, $ Top 0%, $ 100% למטה); / * IE10 + * / רקע: ליניארי- gradient (לתחתית, $ העליון 0%, $ תחתון 100%); / * W3C * / מסנן: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin לוקח שני ערכים: צבע עליון וצבע תחתון. אתה יכול לכתוב mixins שונים עבור סוגים שונים של gradients הכוללים 3 או 4 + צבעים שונים. זה מאפשר לך לייבא לשבט את קוד mixin תוך שינוי הפרמטרים עבור אפשרויות מותאמות אישית.

הדוגמה מ- Code Responsible נראית כך:

.@include linearGradient (#cccccc, # 666666); 

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

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

בעת בניית מבנה הייבוא ​​רק לזכור לעקוב אחר המושגים של קידוד DRY (אל תחזור על עצמך).

מוסכמות למתן שמות

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

תחביר קוד ה- Sass מבוסס למעשה על כללי ההנחיות של CSS. הנה כמה שיטות מומלצות מומלצות שיש לזכור:

• שני (2) פתחי רווחים, ללא כרטיסיות
• באופן אידיאלי, 80 תווים תווים רחב או פחות
• שימוש משמעותי של רווח לבן
• השתמש בהערות כדי להסביר פעולות CSS

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

אבל לגבי מוסכמות למתן שמות אתה יכול בסופו של דבר עם שני מבנים שונים: אחד עבור שמות סאס ועוד עבור שמות בכיתה CSS. כמה מפתחים מעדיפים BEM על הצעות Sass. אף אחד מהם אינו נכון יותר, או פחות. פשוט שונה עם נהלי הפעלה שונים.

הבעיה היא כי BEM אינה נושאת היטב גם משתנים סאס או mixins כי אין להם את הבלוק / אלמנט / מתקן (BEM) המבנה. אני אישית מעדיף להשתמש מוסכמות Sass שמות אבל אתה יכול לנסות כל דבר מן CamelCase לתחביר הפנימי שלך.

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

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

כדי לקבל מושג כיצד תוכל לבנות תוכן עניינים עבור קבצי Sass שלך, בדוק את קובץ ההגדרות של הקרן.

 // קרן עבור הגדרות אתרים // ----------------------------- // // תוכן העניינים: // 1 גלובל // 2. Breakpoints // 3. הרשת / // בסיס טיפוגרפיה // 5. טיפוגרפיה Helpers ... // 1. גלובל // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1.5; // וכו

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

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

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

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

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

קינון לולאה

אלה שתי טכניקות סאס הם שונים מאוד בפעולה, אך שניהם יש היכולת להתעלל אם לא נעשה שימוש נאות.

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

body div.content div.container ... body div.content div.container div.articles ... גוף div.content div.container div.articles> div.post ... 

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

סקימינג זה מדריך SitePoint תמצא שלושה כללים הזהב עבור קינון:

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

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

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

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

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

/ * קוד סאס * / @ for $ i מ 1 עד 8 $ width: אחוז (1 / $ i) .קול - # $ i width: $ width;  / * output * / .col-1 width: 100%; .col-2 width: 50%; .col-3 width: 33.333%; .col-4 width: 25%;  .col-5 width: 20%; .col-6 width: 16.666%; .col-7 width: 14.285%; .col-8 רוחב: 12.5%;

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

לולאות צריך לא לשמש לשכפל בוררים או מאפיינים עבור בורר; זה מה mixins הם.

גם כאשר looping יש משהו שנקרא מפות Sass כי חנות המפתח: זוגות נתונים של נתונים. משתמשים מתקדמים צריכים לנצל את היתרונות האפשריים.

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

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

אם אתה מבולבל או רוצה משוב על קינון או לולאות Sass אתה צריך לכתוב שאלה או / r / sass / או / r / css /, פעיל Reddit קהילות עם מפתחי ידע מאוד Sass.

מודולריזציה

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

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

הגדרת מודול סאס היא די ברורה ועושה הצעה ספציפית מאוד: ייבוא ​​מודול אף פעם לא צריך קוד פלט.

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

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

ציטט את ג'ון לונג מתפקידו על דרך הסאס:

“בשבילי, מודולים הפכו את יחידות בסיסיות או אבני הבניין של פרויקטים סאס שלי.”

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

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

כדי ללמוד עוד על מודולי Sass וטכניקות מודולריזציה, בדוק את ההודעות הבאות:

• מודולי CSS: ברוכים הבאים אל העתיד
• היתרונות והחסרונות של Sass מודולרי
• ארגון CSS מודולרי עם SMACSS & SASS

מצא עבודה מושלמת שלך

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

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

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

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

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

Sass נועד לשפר את חוויית הפיתוח של CSS, כך לעבוד עם בהירות ושיטות מומלצות כדי לקבל את החוויה הטובה ביותר האפשרית.

לעטוף

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

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

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

• הנחיות סאס
• חזון עבור Sass שלנו
• 8 עצות שיעזרו לך להפיק את המיטב מתוך Sass
• הרחבת סאס בלי ליצור בלגן
• Sass Best Practices - קינון יותר מ 3 רמות עמוק