ToCode

# קוד סטארטר לפיתוח Dashboard ב React השילוב של React ו Redux עושה עבודה מצוינת בפיתוח יישומים אינטרקטיביים ובמיוחד כאלה שצריכים להציג או לערוך מידע משותף. במקרה של Dashboard המידע יכול להיות עומס על השרת, מספר משימות שבוצעו, שורות קוד שנכתבו היום או אפילו איזה תאי שירותים פנויים בכל רגע נתון. בעקבות שאלה של חבר כתבתי קוד סטארטר ליישומים מסוג זה ואני משתף אותו כאן גם אתכם. ## אמלק הקוד נמצא בקודסנדבוקס בקישור כאן: https://codesandbox.io/s/ecstatic-chandrasekhar-1cl0d ואפשר לראות אותו לייב בהטמעה כאן: <iframe src="https://codesandbox.io/embed/ecstatic-chandrasekhar-1cl0d?fontsize=14&hidenavigation=1&theme=dark" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" title="ecstatic-chandrasekhar-1cl0d" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin" ></iframe> ## איך זה עובד הדשבורד כולל Redux Store ששומר את המידע ושני Widgets שיודעים להציג את המידע: אחד בצורת טבלא ואחד בצורת גרף. המידע נשמר בתור מערך דו-מימדי כדי שיהיה קל להציג אותו. השורה הראשונה היא הכותרות ואחרי זה המידע עצמו. בשביל הדוגמא הלכתי על מדידת rpm (בקשות לדקה) לאורך זמן, כלומר אוביקט מידע שנראה כך:

  data: [
    ['time', 'rpm'],
    ['10:00', 50],
    ['10:15', 60],
    ['10:30', 50],
    ['10:45', 80],
    ['11:00', 30],
  ],

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

  widgets: new Set(['table', 'graph']),

בזכות החיבור ל Redux שני ה Widgets מקבלים את המידע בזמן אמת וכל עדכון של המידע יופיע מיידית בשניהם. כרגע בקוד הסטארטר אין אפשרות עריכה אז הדרך היחידה לראות את זה היא לשלוח הודעת שינוי ערך מתוך ה Developer Tools. את הגרף ציירתי עם recharts שהיא ספריית גרפים מאוד נוחה לריאקט. יש גם תיעוד טוב והמון דוגמאות באתר שלהם, ובנוסף ל Line Graph שבדוגמא הם יודעים לצייר גם גרפים של עמודים, שטחים, עוגות, רדאר, נקודות, משפך ואפילו מפה. ## הרחבות יש המון דרכים להפוך את הסטארטר הזה לאפליקציה מעניינת. הנה כמה רעיונות: 1. אפשר להוסיף קוד צד שרת ו Middleware ששולף כל שניה את המידע המעודכן מהשרת. המידע החדש ייכנס ל Redux Store ובאופן מיידי יוצג בכל ה Widgets שעל המסך מה שיתן תחושה של עדכון חי. 2. אפשר (ורצוי) להוסיף קוד CSS כדי שה Widgets יהיו מסודרים יפה יותר על המסך. ההרפתקנים שביניכם יכולים לזרוק פנימה את react-dnd וכך לאפשר למשתמשים לסדר לעצמם את ה Widgets באמצעות גרירה על המסך. ולשמור את הסידור ב local storage כדי שיישאר לנו גם לפעם הבאה. 3. אפשר להוסיף מסך פתיחה שיציג רשימה של Dashboards שמורים במערכת. כל Dashboard יכול להקשיב לאוביקט מידע שונה ולהציג אותו באמצעות Widgets שונים. משתמשים יוכלו ליצור Dashboards חדשים או למחוק כאלה שהם כבר לא אוהבים. רעיונות נוספים? דרישות שאתם לא בטוחים איך לממש? מוזמנים לספר ולשתף בתגובות.

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

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

# ביי ביי Redux Thunk בעבודה עם Redux אולי המידלוור הכי פופולרי היה תקופה ארוכה Redux Thunk. וכמו שהוא היה פופולרי כך הוא גם הזיק לאקו-סיסטם. בימים הקרובים אני הולך להשיק כאן קורס ריאקט חדש לגמרי ואחרי התלבטות החלטתי לוותר על Redux Thunk בסידרת השיעורים על Redux. הנה הסיבות המרכזיות: ## מעבר לפעולות Ajax בתוך הקומפוננטות עם הכניסה של React Hooks ובעיקר useEffect, הכתיב של יצירת בקשות Ajax מתוך קומפוננטה הפך הרבה יותר קל ועם הרבה פחות מקום לטעויות. יצירה של Custom Hooks כמו use-http רק הפכה את המשחק הזה לעוד יותר אטרקטיבי. וכשאנחנו מסתכלים קדימה כלים כמו Suspense הולכים לפתור את מעט בעיות הביצועים שעוד נשארו בגישה זו. מסיבה זו בראיה קדימה ארכיטקטורה שבה כל קומפוננטה מביאה את המידע שהיא צריכה מאפשרת הרבה יותר גמישות ביישום בהשוואה לארכיטקטורה בה פעולות ה Ajax נשלחות מ Actions של Redux ובצורה מערכתית. ## כפל קוד וקושי לשתף התנהגות בין Actions הבעיה האמיתית עם Redux Thunk היא שהוא מעודד כפל קוד: כמעט בכל Thunk אנחנו צריכים לכתוב את הקוד שמוציא בקשת תקשורת, מתרגם אותה לאירועי Redux ויודע לטפל נכון בכשלונות. זה אומר שכמעט כל Thunk הולך לכלול קוד Boilerplate שנראה כך:

function myThunkActionCreator(someValue) {
    return (dispatch, getState) => {
        dispatch({type : "REQUEST_STARTED"});
        
        myAjaxLib.post("/someEndpoint", {data : someValue})
            .then(
                response => dispatch({type : "REQUEST_SUCCEEDED", payload : response}),
                error => dispatch({type : "REQUEST_FAILED", error : error})
            );
    };
}

לאורך זמן ה Thunk-ים האלה ממלאים את המערכת והופכים את הקוד להרבה פחות קריא והרבה יותר קשה לתחזוקה. ## העדפה ל Middlewares יותר ספציפיים גם כשכבר יש לנו פעולות אסינכרוניות שאנחנו רוצים להפעיל ברמת המערכת כמעט תמיד נקבל תוצאה יותר טובה אם נכתוב Redux Middleware ספציפי בעצמנו. בקורס החדש בחלק על Redux אני מתמקד ביצירת Middleware ספציפי עבור כל Use Case, לדוגמא בעבודה עם פיירבייס במקום לקחת משהו קיים אני מראה איך לכתוב את המידלוור שמטפל בנושא התקשורת. ברוב המקרים כתיבת קוד Middleware אומרת שנכתוב את הקוד פעם אחת ברמת המערכת במקום לכתוב אותו שוב ושוב בכל Action, וכך הופכת את כל המערכת להרבה יותר קלה לתחזוקה. מידלוורים כמו redux-saga או redux-observable הפכו בשנים האחרונות להרבה יותר פופולריים מ Thunk בדיוק מסיבה זו: הם מאפשרים בניה של מנגנונים יותר ספציפיים, כל אחד עם הגישה הייחודית שלו. בשורה התחתונה - בפיתוח מערכת חדשה היום הייתי חושב פעמיים (או עשר פעמים) לפני שהייתי מכניס Redux Thunk וברוב המקרים גם ממליץ להשאיר את פעולות ה Ajax בתוך הקומפוננטות ורחוק מה Redux Store.

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

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

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

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

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