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

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

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

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

    console.count("Counter::render");

    function handleClick() {
        setCount(c => c + 1);
        setCount(c => c + 1);
    }

    return <button onClick={handleClick}>Clicks: {count}</button>;
}

התוצאה בקונסול צריכה להיות הדפסה פעם אחת של הטקסט Counter::render, למרות שקראנו ל setCount פעמיים. זה קורה בגלל ש React מחכה עם העדכון עד שכל פקודות ה set ייגמרו. אבל אם הסיפור היה נגמר כאן לא היה מה להכין דוגמה עליו; מה שמעניין בריאקט זה שאם הקוד היה נקרא כתוצאה מ setTimeout במקום כתוצאה מלחיצה על כפתור, אז ריאקט כבר כן היה קורא ל render פעמיים במקום לאחד את ה set-ים (התנהגות מתועדת ועם הבטחה לאי תאימות בעתיד - כלומר אל תבנו על זה שזה יישאר ככה).

אבל אנחנו לא כאן בשביל לדבר על ריאקט אלא על הדוגמה שלי שלא עבדה. לא משנה כמה התאמצתי הקומפוננטה שלי הדפיסה על המסך Counter::render פעמיים!. בדיוק כשחשבתי לוותר הלכתי להעיף מבט בקוד של index.js שנוצר אוטומטית עם create-react-app:

  ReactDOM.render(
     <React.StrictMode>
       {app}
     </React.StrictMode>,
    document.getElementById('root')
  );

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

StrictMode renders components twice (on dev but not production) in order to detect any problems with your code and warn you about them (which can be quite useful).

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

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

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

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

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

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

ספריית react-testing-library היא היום הדרך המקובלת לכתוב בדיקות ליישומי ריאקט. קוד rtl נוצר כל פעם שאנחנו בונים אפליקציה חדשה עם create-react-app וגם הסקריפטים הדרושים להריץ אותו. בואו נראה איך להתחיל להשתמש בספריה כדי לכתוב בדיקות ולמה זה כדאי.

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

For any meaningful application, putting all your update logic into a single reducer function is quickly going to become unmaintainable.

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

אבל הניואנס במשפט שקל לפספס אותו הוא שיש יותר מדרך אחת לפצל Reducer. השיטה הפופולרית של combineReducers (שנקראת בתיעוד Slice Reducer) היא רק אחת מהן.

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

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

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

בקיצור הכלי החדש האהוב עליי בימים אלה נקרא nano-react-app והוא תחליף ממש פשוט ל create-react-app (קיבל כבר מעל 300 כוכבים בגיטהאב). וזה מצחיק כי הוא באמת לא עושה כלום - כלומר הוא עושה קצת. הוא לוקח טמפלייט מהאינטרנט ליישום ריאקט JavaScript או TypeScript, משנה קצת את התוכן בקבצים וזה בערך כל הסיפור.

בניגוד ל create-react-app הוא לא מבטיח לכם פרויקט עם כל התוספים וכל הספריות מחוברות במקום אלא בדיוק להיפך. אתם תקבלו קומפוננטה קטנה (ב JavaScript או ב TypeScript) ותמשיכו לבד. בדיקות? הצחקתם אותו. סרביס וורקר? למי יש כח לזה. טמפלייטס מורכבים עם Redux או MobX? עזבו, תכתבו לבד.

ועכשיו רק נשאר להבין: אם כל מה שצריך זה לשים כמה קבצים בתיקיה, בשביל מה היינו צריכים את הכלי הזה מלכתחילה?

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

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

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

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

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

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

מסלול בוטקמפ ללימוד ריאקט ייפתח בתאריך 14.06.2020 למשך שלושה שבועות. מפגשי העבודה יתקיימו בימי ראשון ורביעי בין השעות 9:00 ל-11:00 בבוקר בתאריכים: 14/06, 17/06, 21/06, 24/06, 28/06, 01/07. מחיר הקורס 970 ש"ח וזה כולל חודש מנוי לתקופה של הקורס (אם אתם כבר מנויים החודש הזה יתווסף לכם אוטומטית לתקופת המנוי). הצטרפות לבוטקמפ בקישור: https://www.tocode.co.il/quickjoin2?term=15.

מסלול בוטקמפ ללימוד פייתון יפתח בתאריך 14.06.2020 למשך שלושה שבועות. מפגשי העבודה יתקיימו בימי ראשון ורביעי בין השעות 13:00 ל-15:00 בצהריים בתאריכים: 14/06, 17/06, 21/06, 24/06, 28/06, 01/07. מחיר הקורס 970 ש"ח וזה כולל חודש מנוי לתקופה של הקורס (אם אתם כבר מנויים החודש מתווסף אוטומטית לתקופת המנוי). הצטרפות לבוטקמפ פייתון בקישור: https://www.tocode.co.il/quickjoin2?term=16.

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

אחת הטכנולוגיות הנשכחות של פיתוח Web היא SVG. איכשהו כש Canvas יצאה היא הצליחה לעשות המון רעש, וכמובן ש WebGL היה מלהיב, אבל SVG? זה לא הדבר ההוא שדומה ל XML?. אז כן ולא. תקן SVG יצא לראשונה ב 2001 והשילוב בינו לבין דפדפנים ידע עליות ומורדות לאורך השנים, אבל בשנים האחרונות התמיכה ב SVG בדפדפנים ובספריות פיתוח היא מאוד יציבה ו SVG יכול לתת לכם פיתרון אמין ומהיר להצגה של נתונים בצורה ויזואלית.

בגלל ש SVG נראה כמו אלמנטים רגילים ב DOM אנחנו יכולים ליצור SVG מתוך ריאקט בדיוק כמו שהיינו יוצרים אלמנט רגיל. הקוד ריאקט הבא למשל מצייר מעגל:

function App(props) {
  return (
    <div>
      <svg>
        <circle cx="100" cy="100" r="40" />
      </svg>
    </div>
  )
}

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

svg {
  background: white;
  border: 1px solid black;;
}

circle {
  fill: red;
}

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

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

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