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

1. בואו נספור מלים ב jQuery

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

המימוש ב jQuery מאוד פשוט ואפשר ללחוץ על טאב JS כדי לראות אותו. כל התוכנית נכנסת ב-22 שורות אז לכו להעיף מבט. מדובר בקוד jQuery די טיפוסי, אז מה בדיוק הבעיה?

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

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

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

2. תנו צ'אנס לריאקט

כך זה נראה בריאקט. מוזמנים ללחוץ על טאב Babel לראות את הקוד שמאחור:

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

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

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

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

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

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

שוכנעתם? עדיין חושבים ש jQuery או Angular עדיפים? ספרו לי על זה בתגובות.