הבלוג של ינון פרק

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

מה ש scope עושה זה נותן לנו להגדיר כללי CSS שמשפיעים רק על אזור מסוים. כלומר אם יש לנו את ה HTML הזה (מתוך הדוגמה ב MDN):

<div class="light-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

<div class="dark-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

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

.light-scheme {
  background-color: plum;
}

.light-scheme a {
  color: darkmagenta;
}

.dark-scheme {
    background-color: darkmagenta;
    color: antiquewhite;
}

.dark-scheme a {
  color: plum;
}

די הרבה זמן אני כבר יכול להשתמש ב CSS כזה:

.light-scheme {
  background-color: plum;
  a {
    color: darkmagenta;
  }
}


.dark-scheme {
  background-color: darkmagenta;
  color: antiquewhite;

  a {
    color: plum;
  }
}

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

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

@scope (.dark-scheme) {
  :scope {
    background-color: darkmagenta;
    color: antiquewhite;
  }

  a {
    color: plum;
  }
}

ההבדל בין שני האחרונים קשור למשמעות הסמנטית שלהם. האמצעי בעל אותה משמעות כמו הראשון וה Specificity של ההורה נלקח בחשבון כשמחשבים את הערך (צבע במקרה שלנו). ב scope ההורה הוא לא חלק משורת ה Selector ולכן לא נלקח בחשבון בפיתרון קונפליקטים. דוגמה? בטח. ה CSS הזה:

.light-scheme a {
  color: yellow;
}

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

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

div {
  padding: 10px;
}

.light-scheme a {
  color: yellow;
}

.light-scheme {
  background-color: plum;

  a {
    color: darkmagenta;
  }
}

ייתן ללינקים שבתוך ה light-scheme את הצבע darkmagenta בגלל שהסלקטור שלו יותר ספציפי.

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

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

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

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

הי חברים,

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

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

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

לכן אם אתם-

1. דוברי עברית שרוצים לשפר את האנגלית שלכם, או דוברי אנגלית שרוצים לשפר את הספרדית או הצרפתית שלכם.

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

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

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

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

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

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

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

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

import scala.jdk.CollectionConverters._

val m = Map("a" -> 10)
m.asJava.get("a", 2, 3)

התוצאה היא 0, למרות ש a נמצא במפה. אפשר לטעון ששני הפרמטרים האחרים בלבלו אותו אבל האמת שגם אם נעביר את המחרוזת a לכל הפרמטרים נקבל את אותו 0. הבעיה האמיתית כאן היא ש get של java.util.Map מצפה לקבל פרמטר אחד. העברת יותר פרמטרים לפונקציה היא טעות שהיתה צריכה להתגלות בזמן קומפילציה.

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

val m = Map("a" -> 10)
m.asJava.getOrDefault("a", 1, 2)

-- Error: ----------------------------------------------------------------------
2 |m.asJava.getOrDefault("a", 1, 2)
  |                              ^
  |too many arguments for method getOrDefault in trait Map: (x$0: Object, x$1: V): V
1 error found

אבל כשקומפיילר תופס בעיות רק ב 99% מהמקרים זה לפעמים יותר מתסכל מאשר שלא יתפוס בעיות בכלל.

עוד שבוע מתחיל וסופי שבוע הם זמן מצוין לפתור עוד תרגיל של Advent Of Code. הפעם אנחנו ביום 14 ועדיין עם מטריצות.

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

אבל כל זה היה הגיוני ב 2015. אולי ב 2018.

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

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

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

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

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

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

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

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

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

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

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

מאיפה יש להם את החוצפה?

וזה לא רק האייפון...

איך הם לוחצים על כפתור פעמיים לפני שסיימתי לטפל בלחיצה הראשונה?

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

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

מה פתאום הם בונים שאילתת SQL מקלט שמגיע בטופס? הרי אמרתי להם שצריך לנקות את הקלט לפני שמשתמשים בו.

"לא ככה משתמשים בזה" לא עובד. אנשים ימשיכו להשתמש לא נכון במוצרים שלנו, וימשיכו לבוא בטענות. כדאי לזכור:

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

2. בתור יוצרים עלינו להיות מוכנים לביקורת על המוצרים שלנו ויש לנו את הבחירה - לתקן או להתעקש. ריאקט אומנם מתעקשים על מנגנון ניהול הסטייט שלהם אבל מנגנוני ORM פתרו כמעט לגמרי את הבעיה שאנשים בונים שאילתות SQL בצורה ידנית ולא מאובטחת. גם כשמחליטים "להתעקש" אפשר לוודא שהמשתמשים שלנו מבינים מה הם עושים לא בסדר ואיך מתקנים. בריאקט בגלל זה דואגים להדפיס אזהרה כל פעם שאנחנו מרנדרים קומפוננטות בלולאה בלי key. בסיס הנתונים JanusGraph מדפיס לי אזהרה ללוג כל פעם שאני שולח שאילתה ואין לו אינדקס מתאים בשבילה.

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

אם עדיין לא שמעתם ככל הנראה ריאקט 19 תשוחרר עם תמיכה ב React Forget הקומפיילר החדש מבית ריאקט שאמור להוסיף useMemo אוטומטית לתוכניות שלנו. הנימוקים שלהם לפיתוח הפיצ׳ר (מתוך הפוסט) היו-

1. כתיבת useMemo ידנית מלכלכת את הקוד.

2. קל לטעות כשצריך להחליט ידנית למה לעשות Memoization.

3. תוספת הקוד מעמיסה על התחזוקה.

הנה משפט המפתח מתוך הפוסט-

Our vision is for React to automatically re-render just the right parts of the UI when state changes, without compromising on React’s core mental model.

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

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

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

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

3. הוספת מנגנונים כמו React Forget רק מרחיקה אותנו מפיתרון הבעיות האמיתיות של ריאקט. במובן הזה סיגנלים היו יכולים להיות תוספת הרבה יותר מועילה ומעניינת.

האם React Forget יגרום לאפליקציות שלנו לעבוד מהר יותר? כנראה שכן. האם הוא יביא איתו בעיות חדשות שאף אחד לא היה צריך בשביל שיפור מינורי בביצועים? כנראה שגם כן.