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

ריאקט עברה ועוברת עדיין הרבה טלטלות מבחינת ה API, כאשר אולי הגדולה ביותר היתה ההמלצה להפסיק להשתמש ב React.createClass ולעבור להשתמש במחלקות וב Function Components כדי ליצור את הקומפוננטות.

נודה על האמת הפונקציה React.createClass היתה סוג של פשרה מהיום הראשון. הרי אם היו class-ים ב JavaScript כשריאקט התחילה כנראה לא היו צריכים לכתוב אותה. לפונקציה זו מקבילה בהרבה ספריות UI אחרות ישנות יותר כמו למשל Class.create של פרוטוטייפ או declare של dojo.

אבל משהו מאוד גדול הלך לאיבוד במעבר מ React.createClass ל class המודרני, ולמשהו הזה קוראים Mixins. מיקסינס הפכו במעבר למחלקות למבנה שנקרא Higer Order Components שהיה הרבה פחות אינטואיטיבי לרוב המפתחים. בפוסט היום ניזכר יחד מה היו מיקסינס, איך HoC אמורים היו להחליף אותם ומה Hooks מצליחים לעשות טוב יותר. מוכנים?

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

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

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

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

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

אבל האמת שעדיף ללכת הפוך: אני רוצה להרוויח X ש"ח בחודש; מה מעצבים גרפיים שמרוויחים את הסכום הזה עושים? איך הם הגיעו לאן שהם הגיעו? נשמע שכדאי ללכת באותו כיוון.

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

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

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

אחת השאלות הראשונות של אנשים שעבדו עם React Hooks היתה קשורה לשילוב, או יותר נכון להתנגשות, בין React Hooks ל setInterval. בקצרה מסתבר שהקוד הבא לא עובד:

function Counter() {
  let [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <h1>{count}</h1>;
}

ה Counter בפקד נעצר ב-1.

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

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

import React, { useState, useEffect, useRef } from 'react';

function Counter() {
  let [count, setCount] = useState(0);

  useInterval(() => {
    // Your custom logic here
    setCount(count + 1);
  }, 1000);

  return <h1>{count}</h1>;
}

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

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

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

וזה יכול להימשך שעות. אפילו ימים.

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

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

https://www.youtube.com/watch?v=qs0b2t8SM88&t=647s

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

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

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

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

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

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

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

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

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

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

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

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

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

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