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

1. אנגולר2

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

הנה שלום עולם באנגולר2:

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

מידע יישמר כמשתנים במחלקה וניתן לקרוא אותם ב template בדיוק כמו שאנגולר1 חיברה בין התבנית לבקר. מונה הלחיצות באנגולר 2 יראה די מוכר למי שרגיל לאנגולר 1:

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

הפקד Helper מכריז איזה קלטים הוא מצפה לקבל (במקרה שלנו הקלט hero) והפקד החיצוני מכריז באמצעות מערך Directives באיזה פקדים הוא מתכנן להשתמש. העברת המידע מהפקד החיצוני לפנימי נראית כמו הגדרת Attribute לאלמנט HTML רגיל.

2. ונעבור לריאקט

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

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

החיבור מוצג בצורה ברורה יותר בדוגמת מונה הלחיצות:

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

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

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

3. סיכום ביניים

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

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

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