האם אתם שולטים ב Objective-C? ב JavaScript? ב HTML5 וב CSS3? ב ++C/C?
אם אתם הולכים לפתח למובייל – ייתכן ותאלצו ללמוד שפת תכנות חדשה: זו כבר לא כל-כך בחירה שלכם מה אתם מעדיפים – זו דרישה של הפלטפורמה.
כמה מכם מכירים Linux או Unix? כמה רגילים לעבוד ב Mac OS או חלונות 8 (שבה חוויית השימוש שונה לחלוטין)?
האם אתם רגילים ל Visual Studio, Eclipse וגם Xcode?
ייתכן ותאלצו להתרגל לסביבה חדשה וכלים חדשים.
הביטו במפה הבאה שיצרתי. עם כמה מהספריות הללו עבדתם כבר? האם אתם מזהים לאיזה תחום כל ספרייה שייכת?
אתם בוודאי יודעים שלהשתמש בצורה יעילה בספריה – לוקח זמן. ייתכן ויש לא-מעט ללמוד על מנת לפתח אפליקציות מובייל בצורה יעילה.
(נכון: חלק מהספריות ה javaScript נכונות גם לפתרונות Desktop)
מאז שנת 2000 בערך, היה מעבר משמעותי של פיתוח אפליקציות ווב על חשבון האפליקציות השולחניות. במובייל יש חזרה במידה רבה לפיתוח אפליקציות מקומיות למערכת ההפעלה (מה שנקרא גם native).
כמה מהמשתמשים שלכם כיום:
 |
| חלונות 8 מנחה את המפתחים לא לספק חיפוש-בתוך-האפליקציה מתוך ה UI של האפליקציה, אלא מתוך מקום מרכזי במערכת ההפעלה. כך היא נהגה גם עבור האפליקציות שלה. |
 |
| ב iOS מנחים את האפליקציות לנהל את ההגדרות (Settings) שלהם מתוך מסך מרכזי של מערכת ולא מתוך האפליקציה. רוב המפתחים אכן הולכים בעקבות הנחייה זו. |
שייך לסדרה: MVC בצד הלקוח, ובכלל.
בחרתי להתמקד בדוגמה "קטנונית" לכאורה. הדוגמה מבוססת על מודל ה Person וה View בשם PersonView מהפוסטים הקודמים. בחלק זה הוספתי לה את היכולת לעשות expand/collapse לפרטים של האדם (במקרה שלנו: האימייל) + אייקון יפה שמציג את המצב, "פתוח" או "סגור".
הקוד אמור להיות ברובו מוכר.
טכניקה זו מאפשרת לי להסתיר / להציג את ה markup ע"י הוספה / הסרה של CSS class – פעולה קלה בjQuery.
2 – שימוש במנגנון האירועים של BB. הפורמט הוא key: value, כאשר:
Key = מחרוזת: ".
Value = מחרוזת עם שם הפונקציה באובייקט ה View שתופעל כתגובה לאירוע.
BB בעצם מפעילה כאן את jQuery: היא רושמת את הפונקציה שהוגדרה ב value, לשם האירוע (למשל "click" או "keypress"), על האלמנט(ים) שחוזרים מהשאילתה.
בנוסף, BB גם עושה עבורנו Function Context Binding (לטיפול ב this) – כך שאין צורך לבצע bind/bindAll לפונקציית הטיפול באירוע.
את האובייקט הנכון של ה View היא מזהה בעזרת ה cid שעל ה el – מה שחוסך לנו הרבה עבודה.
3 – זו הפונקציה שתקרא לאחר שהמשתמש לחץ על ה person-frame שלנו. היא מזהה את המצב הנוכחי ומבצעת את השינויים הדרושים ב DOM. קריאת toggleClass של jQuery מסירה / מוסיפה CSS class בדיוק עבור שימושים כאלו.
הנה ההרצה של הקוד:
1 – אנו מוודאים שה default הוא הנכון.
2 – אנו מדמים לחיצה של משתמש על ה person frame ומוודאים שהמצב השתנה.
טיפ קטן: אני משתמש ב ('trigger('click, הקצת פחות קריאה, ולא ב ()click הקצת פחות אמינה. כמה דפדפנים מונעים שימוש ב click ישירות.
3 – אני בודק גם את המצב ההופכי, עבור שלמות הבדיקה.
הקוד נראה בסה"כ קריא, ולא כ"כ מסובך. מדוע אם כן אני קורא לו "קוד ספגטי"?
אפילו בקוד הבדיקות, "נגררתי" (עלק) לבדוק את מצב ב DOM: האם יש css class מסוים או לא. מבנה ה DOM הפך לציבורי.
אם אתם משתמשים ב"מודל שמן" – אזי BB מספקת פחות תשתיות מוכנות. אין בעיה להוסיף פונקציות על המודל שמחשבות ערכים, כגון ()isVIP שמכילה את הלוגיקה האם Person מסוים הוא אדם "חשוב מאוד".
הקושי נובע מהמצב בו אתם רוצים לשמור על המודל client-side state או ui state – כלומר properties שישמשו אתכם בצד הלקוח אך לא תרצו לשמור בשרת.
כיצד תוכלו לומר ל BB אילו תכונות של המודל נשמרות בשרת ואילו לא? BB לא מספקת יכולת מובנה לדילמה זו.
ההורשה ב BB, כלומר extend._ איננה הורשה אמיתית, היא בעצם ממזגת עותק של אובייקט האבא (כלומר Prototype Design Pattern) עם אובייקט חדש שאתם מגדירים.
BB גם לא תומכת בארגון מודלים בהיררכיה – רק ברשימות (כמו טבלאות ב DB רלציוני). כלומר: איננו יכולים להשתמש בהיררכיה על מנת להפריד בין ה״מודל לשמירה בשרת" ל״ערכי המודל של צד-הלקוח״.
הנה המודל שלנו ב"גרסה השמנה" (Rich Model):
הנה ה View:
אפשר לראות שיש 2 templates עבור כל מצב: Collapsed או Expanded – גישה זו טובה כאשר יש 2-3 מצבים. אם יש יותר – אז כדאי להחזיק template בסיסי ולבצע ב ()render שינויים ב markup.
המחזור של תגובה-לאירוע שונה משמעותית מזה של הדוגמה הקודמת:
אם קודם המחזור היה: רינדור View ל DOM, לחיצה של משתמש, אירוע -> שינוי ה DOM,
עכשיו המחזור הוא: רינדור View ל DOM, לחיצה של משתמש, אירוע -> שינוי המודל -> אירוע שינוי המודל -> רינדור ה View ל DOM.
השינוי מתרחש במודל – וה View משקף אותו. ב View אין חוכמה לוגית / עסקית – הוא מטפל ב UI נטו.
שימו לב שעל מנת לשנות את המחזור, הוספתי binding לאירוע ה change של המודל בבנאי – כלי נוח ש BB מספק לי.
קוד ה render הוא לא קצר הרבה יותר מהדוגמה הקודמת – אך הוא פשוט יותר ו"שביר" פחות. הוא בוחן את המודל (קוד js פרטי ולא DOM – שיכול להיות מושפע מהרבה מקורות) ורק על פיו הוא מחליט מה לצייר.
אין לי צורך "לבצע delta" (במקרה זה: הסרה של ה CSS Class בשם hidden) כי בכל מחזור אני מתחיל על בסיס ה template מחדש – דבר שמפשט את הקוד משמעותית.
אחד הדברים שהכי בולטים בקוד ה"רביולי", מלבד שהוא קצת ארוך יותר, הוא שהוא עושה יותר עבודה.
במקום לשנות ב DOM משהו קטן – רינדרנו חתיכת markup מחדש והחלפנו את כולה. "שיטת המוסכים המורשים" – אני קורא לה: "שריטה בדלת? – נחליף דלת", "רשרוש במנוע? – לא מתעסקים. נחליף את המנוע".
זה עשוי להראות דיי מרתיע – אך לרוב אין פה בעיית ביצועים אמיתית: רוב הפעמים ההחלפה תהיה של "מודל בודד" שלא יכלול הרבה markup – ולכן החלפתו לא תהיה יקרה.
אם שמתם לב, הוצאתי את "קימפול" של ה templates (פקודת template._) מחוץ ל instance הבודד של ה view – זה דבר משמעותי הרבה יותר מבחינת ביצועים!
אם בכל זאת אתם רוצים לבצע החלפה דינמית, כי ה markup שלכם גדול או הביצועים הם ממש קריטיים – BB מספק מספר כלים שיכולים לעזור.
אני בטוח שיש עוד כמה דרכים אפשריות…
בסופו של דבר, מכיוון שאין פה בהכרח בעיית ביצועים מובנה, הייתרון הוא שאתם יכולים להתמקד בכתיבת קוד שקל לתחזק, ורק אם/לאחר שהוכח שיש בעיית ביצועים – לבצע שיפורים, ולבצע אותם רק היכן שצריך. זו גישה מאוד בריאה.
כל חובב בישול יאמר לכם שרביולי הוא טוב מספגטי. ספגטי הוא דיי … פושט.
בתור מישהו שעוסק הרבה ב״הנדסת תוכנה״, אני מתפתה להצטרף למקהלה ולהעדיף אוטומטית את "מודל הרביולי" – אך לא כך.
באידאל – יש להתאים את המודל לצרכים הקונרטים: ספגטי לארוחת צהריים מהירה שבקרוב תשכח, רביולי לארוחת ערב מפנקת ומשמעותית. "קוד ספגטי" למערכות פשוטה שאנו רוצים לסיים מהר, "קוד רביולי" – למערכת שאנו צופים עליה עוד עבודה רבה ושינויים רבים.
הבעיה: כאשר מתרגלים לסגנון אחד – קשה לעבור לשני.
לאחדים (כמוני) שהתרגלו לכתוב רק "קוד רביולי" – קשה מנטלית לכתוב "קוד ספגטי" גם כשהדבר נכון. זה גורם להרגשה רעה.
לאחרים, שהתרגלו לכתוב "קוד ספגטי" – קשה מנטלית לכתוב "קוד רביולי" – זה מרגיש מיותר ומעייף.
אני מניח שאם הגעתם להתעסק ב Backbone / JavaScript MVC – כנראה שעלה צורך ל"קוד רביולי".
אני, הייתי הולך עם זה עוד צעד קדימה – ועובד עם "מודלים שמנים, Views רזים".
שיהיה בהצלחה!
בואו נפתח בדוגמה פשוטה:
אתם יכולים לזהות מודל מינימלי בשם Person ואת האוסף (Collection) בשם People – אוסף של Person.
1 – ההגדרה של model בבנאי של האוסף אינה נדרשת בשלב זה. היא משמשת רק כאשר משתמשים ביכולות ה REST המובנות ב Backbone.Model ו Backbone.Collection על מנת לסנכרן שינויים לשרת. איננו עוסקים ביכולת זו עדיין, אך אני מעדיף להגדיר את המודל לצורך הקריאות. הקונבנציה המקובלת ב BB היא לקרוא לאוסף בשם הרבים (s בסוף) של המודל, למשל Invoice ו Invoices.
2 – אנו יוצרים מודל (בצורה נאיבית, אציג דרכים יעילות יותר בהמשך) של מג'יק ג'ונסון ומוסיפים אותו לאוסף.
3 – לכל מודל (בעצם לכל אובייקט של BB) שנוצר ניתן מזהה גלובלי ייחודי, בפורמט "c". במקרה זה אני יודע שאובייקט של מג'יק ג'ונסון הוא השלישי שנוצר במערכת ועל כן אני יכול לאמת את ה cid שלו. זו הנחה שלא הייתי רוצה להסתמך עליה בקוד אמיתי.
cid הוא קיצור של Client Identifier, שנועד לסייע לזהות מופע של מודל בצורה ייחודית. ב BB מניחים שצד-השרת, בעקבות השימוש בבסיס נתונים כלשהו, יהיה לכל אובייקט זיהוי ייחודי. בטווח הזמן בו האובייקט נוצר בצד-הלקוח ועדיין לא נשמר בבסיס הנתונים וקיבל Id ייחודי מבסיס הנתונים, ה cid אמור להיות כלי העזר על מנת לזהות ייחודית את המודלים.
4 – הוספנו עוד מודל אחד לאוסף.
5 – אוסף של BB, באופן מובנה, יכול להשתמש utilities של underscore.js – שהם דיי שימושיים. הנה דוגמה של פונקציה בשם plunk שעוברת על כל אחד מהמודלים באוסף, ומכניסה לתוך מערך התשובה ערך של שדה שהוגדר, במקרה זה – כל שמות המשפחה. כמה נוח.
כן, underscore.js "מתעסק לנו" באובייקטים בסיסיים של השפה כמו "Object" או "Array"', במקרה זה הוא הוסיף את plunk ומתודות אחרות למערך. נכון, זה משהו שממליצים לא לעשות. לא לעשות באפליקציה – אך זה "מותר" לספרייה. תתרגלו.
הנה דוגמה מורכבת מעט יותר המציגה חיבור של Collection ל View:
View אחד עבור כל Person, ועוד View עוטף של האוסף People.
התוצאה, עבור אוסף מינימלי של 2 אנשים, תראה משהו כזה:
הכותרת "שני אנשים" שייכת לPeopleView, והשאר נוצר ע"י שני מופעים של PersonView. בלי שום Styling כמובן – בכדי לצמצם את גודל הדוגמה.
כמיטב המסורת, נפתח בדוגמת ההרצה, ורק לאחר מכן נעבור לקוד עצמו:
ב1 – אנו יוצרים אוסף בשם people ומזינים אותו בערכים. המשמעות של reset היא "החלף את כל הערכים הנוכחיים ברשימת הערכים הבאה" והיא האופן בו נרצה להזין ערכים כאשר אנו טוענים מצד-השרת רשימה מלאה של ערכים. אנו מזינים את people במערך של אובייקטים שכל אחד מתאר את המודל של הרשימה – Person.
ב2 – אנו יוצרים את ה PeopleView, ה View שיודע להציג את הרשימה וליצור את ה HTML הנ"ל. נראה את הקוד שלו מייד.
ב3 – כך מבצעים בדיקת-יחידה יציבה (לא-שבירה) עבור תוצאת HTML. טעות נפוצה היא להשוות את כל תוצאת ה HTML כ String לערך שהיה נכון בסוף רגע הפיתוח ובחנו שהוא תקין. הבעיה: כל שינוי ב markup – אפילו ריווח או תוספת תג לא משמעותית (למשל label) תשבור את הבדיקה – גם כאשר התוצאה עדיין תקינה. הדרך הנכונה לבדוק היא לאתר "עוגנים חשובים" ב HTML ולבדוק רק אותם. האומנות היא למצוא את רמת הפירוט האופטימלית.
אנו מאמתים את טקסט הכותרת
אנו מאמתים את מס' האלמנטים מסוג h2
אנו מאמתים שהטקסט של הראשון הוא "ג'ונסון, מגיק" – כלומר את הפורמט. eq היא המקבילה של jQuery ל index.
אנו מאמתים שאחרי ("~" ב css selector) הכותרת h2 הראשונה ישנו אלמנט p שמכיל את כתובת האימייל של זיגי. איננו רוצים "להפיל" את הבדיקה אם מחליפים את התחילית "email" באייקון קטן, למשל. אנו מתמקדים בנתונים ההכרחיים.
ב4 – אנו מבצעים reset לנתונים – עם רשימה באורך 3, רק כדי לוודא שהכותרת הראשית (h1) אכן תלויה באורך הרשימה.
הנה הקוד עצמו:
ההתחלה אמורה להיות מוכרת. פרקטיקה טובה היא להוסיף ערכי defaults למודל עבור כל שדה שאנו הולכים להשתמש בו ב View – אחרת אנו עשויים להיתקל ב Runtime Errors ללא fallback (למשל כשיש מודל עם age בלבד).
1 – לא התאפקתי והשתמשתי הפעם ב template engine – שהיא הדרך המומלצת ב BB כדי לייצר את ה markup עצמו. השתמשתי בצורה בסיסית ביותר בספרייה המובנה בתוך underscore.js (אתם יכולים לזהות ע"פ תחביר ה ERB/JSP), אבל אין שום מניעה לעבוד עם ספרייה אחרת כמו handlebars.js, mustache.js או dust.js.
אתם יכולים לשים לב שב template.people יש קו על התגית . הסיבה: התגית היא deprecated ב HTML5. הדרך ה"נכונה" ע"פ HTML5 לייצר קו תחתון הוא לעטוף ב span עם class שלי ואז להחיל עליו קו-תחתון בעזרת CSS. לצורך דוגמה זו אתעלם מזוטות שכאלה.
עוד נקודה מעניינת היא השימוש ב class (נקודה) ולא id (סולמית) על מנת לזהות את החלק שבו "יוזרקו" חתיכות ה markup של ה Person הבודד. על Id ב HTML להיות ייחודי בכל הדף ואיני יודע בוודאות אם ה PeopleView יוצג יותר מפעם אחת על הדף או לא. סיכוי אחר: אולי מישהו אחר ישתמש בid בשם people-list במקום אחר. על מנת להישאר סטנדרטיים יש להימנע משימוש ב id אלא אם אפשר לוודא שהוא אכן ייחודי – מה שלרוב קשה לדעת. הפתרון: שימוש ב css class לזיהוי.
בכל מקרה, אחפש את ה css class בצורה יחסית – כך שלא אשפיע על אזורים אחרים ב markup, גם אם הם השתמשו באותו css class בדיוק.
גישה פופולרית היום היא להקליד את ה templates עצמם בתוך ה HTML עצמו עטופים בתג ועם id ידוע מראש ואז להשתמש ב jQuery על מנת לטעון את ה template בזמן ריצה. ה template כמובן אינו משפיע על ה HTML – הוא רק "יושב שם מבלי להפריע". מדוע לעשות זאת?
מדוע, אם כן, אני מעדיף בכל זאת לשמור את ה templates בתוך ה javaScript code?
2 – ביצירה של ה PersonView אני מייצר את ה"אוטומט" של ה template. על מנת להשיג יעילות מרבית, ה template engine נוהגים לפרק את ה string של ה template לצורה מהירה יותר לשימוש. לרוב מקובל לקרוא למשתנה שמחזיק את התבנית פשוט "template", השתמשתי ב myTemplate על מנת לנסות ולהקל על ההבנה במקרה זה.
3 – כאן מבצועת ההפעלה של ה"אוטומט" של ה template engine על נתונים מתאימים, במקרה זה – המודל המדובר. ה"אוטומט" myTemplate הוא בעצם פונקציה שמרנדרת html markup ברגע שמזינים לה נתונים. אנו טוענים את התוצאה לתוך this.el שהוא, כאמור, העטיפה ב DOM ל View שלנו.
בואו נעבור עכשיו ל PeopleView המייצג את התמונה הכוללת:
4 – לאחר שרינדרתי את החלק של People ב HTML, הרי היא ה"מסגרת" (במקרה שלנו – רק כותרת), אני רוצה להזין את הנתונים של המודלים הבודדים. אני קורא ל $.this על מנת לבצע חיפוש בתוך ה markup של this.el בלבד, אחר המקום בו "אזריק" את ה Views של המודלים הבודדים. זוהי גרסה מקוצרת (ומומלצת) לכתיבת "(this.el).find('.people-list')$" (אני מניח שאתם מכירים jQuery).
5 – each של collection מאפשרת לי להריץ פונקציה עבור כל מודל באוסף – משהו כמו foreach.
6 – או יוצרים מופע של PersonView עם המודל ה person הנוכחי. אולי זה מרגיש קצת "כבד" לייצר View כל פעם ולא לייצר אחד ולעשות בו שימוש חוזר – אך זה בסדר.
7 – אנו משתמשים ב view על מנת לרנדר את ה markup ומוסיפים את ה "glueing markup", שבמקרה זה הוא רק תגית br. אנו רוצים לשמור את ה template של Person "נקייה" כך שנוכל להשתמש בה גם ללא ה PeopleView.
בפוסט זה צללנו לדוגמה ריאלית קצת-יותר (מהפוסט הקודם) של קוד ב backbone – על מנת להבין כיצד קוד ב BB "מרגיש". אני מקווה שהצלחתי להעביר את התחושה, אם כי היא עדיין מינימלית למדי. כפי שראינו, BB לא עושה "קסמים" (כמו Ember או Angular) – אנו עדיין כותבים את כל הקוד, אך BB נותן לנו מסגרת, guidance ו utilities על מנת להגיע לשם.
על הדרך השלמנו את הפער אודות השימוש ב template engine, שהוא היבט מרכזי בספריות "javaScript MVC", והדגמתי כיצד לבצע בדיקות-יחידה ל View וראינו Views מקוננים. כל זה דחוס בפוסט לא כל-כך ארוך. אני מקווה ששמרתי על איזון נכון של "לא משמעמם" ו "ניתן להבנה".
הערות יתקבלו בשמחה!
שיהיה בהצלחה!
האם השפה רלוונטית במיוחד לבעיות חדשות בתעשייה, שלא היו נפוצות בעבר? – גם לא ממש.
השינוי במקומה של ג׳אווהסקריפט נבע משילוב של שלושה גורמים עיקריים: שיפור מנועי הג׳אווהסקריפט (תאימות לתקן וביצועים), התקדמות הווב כפלטפורמה פופולרית להפצת תוכנה וקהילה פעילה שבנתה ספריות משלימות שאפשרו להשתמש בג׳אווהסקריפט בצורה יעילה ואמינה יותר. בפוסט זה נתמקד בגורם השלישי.
שייך לסדרה: MVC בצד הלקוח, ובכלל.
 |
| סמל, שאם תכתבו ב Backbone.js – תיתקלו בו עוד הרבה… |
לא ניתן להתעלם מתרומתה הרבה של ספריית jQuery ודומותיה[ב] בעיצוב מקומה החדש של שפת ג׳אווהסקריפט. במעגל השני של ההשפעה (לפחות בצד-הלקוח) נמצאות ספריות שעוזרות בכתיבת אפליקציות צד-לקוח גדולות. ספריות אלו נקראות ״MVC Frameworks" או ״ספריות ארכיטקטוניות״. השם MVC עשוי לבלבל את מי שכבר מכיר ועבד עם ספריות MVC צד-שרת כגון Struts או ASP.NET MVC.
בעוד ספריות "MVC קלאסיות" מטפלות באפליקציות רבות דפים והניווט בניהם, ספריות ה "JavaScript MVC" לרוב מטפלות באפליקציות דף-יחיד (כגון GMail) בהן יש מסך עקרי אחד שחלקים בו מתחלפים / משתנים – אך אין ניווט משמעותי. בכלל, עצם הפעולה בצד-הלקוח, ב Ajax, בו אין refresh לדף בעת פעולה – משנה את כללי המשחק: מציב בעיות חדשות ופתרונות אחרים. עוד הבדל בולט הוא שברוב ספריות ה "JavaScript MVC" אין Controller. השם MVC בא לבטא את הרזולוציה ואת הבעיה שהן באות לפתור: ארגון קוד באפליקציית UI גדולה ומורכבת.
קיימות כיום מספר רב של ספריות "JavaScript MVC" וצפוי בהן עוד תהליך של קונסולידציה. שלושת הגדולות הן:
ספריות משמעותיות אחרות הן Spine.js, JavaScriptMVC, Batman.js ו AngularJS (מבית גוגל). האתר המצוין todoMVC מציע השוואה מעמיקה בין האפשרויות בכך שמימש אפליקציית דוגמה בכל אחת מספריות הנ"ל (ועוד כמה ספריות נוספות).
כפי שציינתי, ספריות "JavaScript MVC" הן לא בדיוק MVC קלאסי. בעצם, גם ל"MVC קלאסי״ יש כמה פרשנויות שונות (לדוגמה, האם ה Controller מתמקד בעיקר בטיפול ב input או אחריות על ניהול הflow והתלויות?[ד]).
המדקדקים מגדירים את Knockout.js כ MVVM) Model, View, View-Model) – תבנית עיצוב שמייקרוסופט מקדמת בעולם הNET. זה דיי נכון.
את Backbone.js ו Ember.js נוהגים להגדיר כ Model, View, Presenter) MVP). האמת, ספריות כמו ASP.NET או GWT מתאימות יותר להגדרה זו. הגדרה כגון Model, View-Controller, Router (בקיצור MVCR) תהיה יותר מדויקת.
ההגדרה המועדפת עלי כרגע היא !Model, View, Whatever (בקיצור MVW או *MV).
התחלתי את הפוסט הזה בניסיון לעקוב אחר ההיסטוריה של תבנית העיצוב MVC, הוריאציות והשינויים שהיא עברה במשך השנים, בעיקר MVP ו MVVM, והניסיון להסביר כיצד ספריות ה "JavaScript MVC" מתאימות לתבניות אלו.
בת'כלס – הן לא בדיוק מתאימות. הפוסט התארך, התפלפל והסתבך – וחששתי שלא יהיו מספיק קוראים (או אפילו בני-אדם דוברי עברית) שבאמת יתעניינו בכל ההגדרות הללו והניסיון להתאים אותן למציאות בשטח. הנחתי את הפוסט ההוא בצד.
בסופו של דבר – MVC הוא ניסיון לארגן אפליקציית UI מורכבת בצורה שתהיה קלה לתחזוקה ושינויים. כל דור של UI (Web, Fat Client, Fully Client Side, Command Line) – והאתגרים שלו.
כפי שמרטין פאולר ציין פעם: "אנשים נוטים להסתבך עם MVC. החלק הכי חשוב הוא לבצע הפרדה אמיתית בין Business Logic ל UI. כל השאר – משני". אני מסכים ב 100%.
לכל ספרייה יש את הדרך שלה לארגן את הקוד – ואולי יותר מעשי ומעניין פשוט להתבונן בישומים קונקרטיים.
בפוסט זה אתן הצצה בסיסית ביותר ל MVW בג׳אווהסקריפט בדמות Backbone.js – הספרייה הנפוצה והמינימליסטית שיכולה להיות בסיס לימודי מצוין להבנת MVC בג׳אווהסקריפט.
הנה דוגמה למודל מינימלי שניתן לייצר ב BB:
הערה: משפטי ה expect…toBe הן בדיקות-יחידה המציגות את התנהגות הקוד. כל הבדיקות עוברות בהצלחה.
המודל שלנו, Person בדוגמה זו, הוא פשוט למדי. הייתי יכול ליצור אותו גם ללא defaults – רק עלי ידי הורשה ריקה מהמחלקה Backbone.Model. תכונות המודל (כמו שם פרטי/משפחה) הן דינמיות ומוגדרות בזמן יצירת האובייקט הספציפי. ה default היא היכולת לחייב שתכונות מסוימות יהיו בכל מקרה.
ב1 – אנו יוצרים מודל של אדם בשם אוזי כהן.
ב2 – בכדי להדגיש את השוני בינו ובין אמן אחר בשם ״ליאונרד״ ובעל שם משפחה זהה, אוזי משנה את שם המשפחה שלו.
ב3 – אנו מקבלים את המודל המלא בפורמט JSON.
כמובן שדוגמה זו היא טיפה בים. מודלים אמיתיים הם מורכבים בהרבה ו BB מספק עוד יכולות רבות. המטרה היא רק לתת הצצה מוחשית כיצד נראה שימוש ב BB. הנה עוד דוגמה, שכוללת גם View:
השתמשתי במודל הכי פשוט שאפשר – כי ברצוני להתמקד ב View.
PersonView היא המחלקה שאחראית לצייר מודל של Person. יכולים להיות, כמובן, כמה Views שונים לאותו המודל. את ה markup שה View יוצר, ארצה לשלב היכנשהו ב DOM. בדוגמה זו – זה יהיה container$, שמשתמש ב span בכדי לא לבלבל עם ה div ש Backbone יוצר באופן אוטומטי לכל מופע של המודל.
el הוא בעצם אלמנט ה DOM שיצר לי BB כחלק מה View. הוא עושה זאת על מנת לאפשר ל markup בפנים להשתנות, בלי שאצטרך לחבר את ה markup שוב ל container. הבחירה ב div היא כמובן רק default, ואם אני זקוק ל list element (תג
ב2- אנחנו בוחנים את ה markup כולל ה container. רק לוודא שהתמונה הכללית ברורה.
ב3- אנחנו מבצעים שינוי למודל ורואים שה markup ב container השתנה באופן פלאי. "פלאי" – כמובן שלא. אנחנו כותבים את הקוד שעושה זאת – backbone רק מכווין אותנו למבנה מסוים ועוזר לנו.
בואו נבחן את הפונקציה initialize שהיא לצורך העניין הבנאי (constructor) של מחלקת ה PersonView שלנו, וכוללת 2 משפטים מוזרים:
ב5- אנחנו מבצעים פעולת JavaScripts's bind לכל המתודות במחלקה שאנו הולכים ל"ייצא" כ callbacks לאובייקטים אחרים. במקרה זה – יש רק את ״render״, אך יכולתי באותה מידה לשרשר גם שמות של מתודות נוספות. למה צריך לעשות JavaScript bind? – כדי ש this ימשיך להצביע לאובייקט שלנו. מבולבלים? קראו את הפוסט להבין את JavaScript this.
הסימן "_" (קו תחתון) הוא הקיצור לגשת לספרייה underscore.js, ממש כמו שניגשים עם $ ל jQuery. אלו המקומות ש underscore מסייעת מאוד לכתוב קוד ב BB. אתם לא חייבים – אבל כדאי.
ב6- אנחנו "מחייטים" את ה View שלנו לבצע פעולת render כל פעם שהמודל משתנה (change' event'). מאוד דומה לאירועים ב jQuery.
הבהרה קלה: אם אתם מכירים את תבנית העיצוב MVC אתם יכולים להבחין שה View ב Backbone מבצע פעולות ("חיוט") של Controller. זה נכון: אפשר לומר שה View ב BB הוא בעצם View-Controller: הוא עושה הרבה פעולות שבמקור יוחסו ל Controller.
אם אתם מכירים את תבנית העיצוב MVP נראה שה View הוא בעצם יותר Presenter. הוא אחראי ל Presentation Logic. זה נכון: בעצם מה שנקרא "View" ב BB הוא דומה ל MVP's Presenter בעוד ספריית ה Templating (בעצם ה Template עצמו) – דומה מאוד ל MVP's View.
הצצנו ל Backbone וטעמנו כיצד נראה קוד שמשתמש ב Backbone.js. טעימה קטנה.
דיברנו גם על החשיבות של ספריות "JavaScript MVC" – כאשר קוד הג'אווסקריפט שלכם מתחיל לגדול ולהסתבך. וגם על החשיבות לא לחפור בתבנית-העיצוב MVC וההיסטוריה שלה יותר מדי 🙂
ייתכן ואמשיך לכתוב קצת על Backbone על מנת להתעמק בו קצת יותר, בניסיון לבחון JavaScript MVC "מהשטח".
בהצלחה!
——
[א] נקראת Harmony, ג׳אווהסקריפט 2.0 או ECMAScript 6.0. כוללות, ככל הנראה, מחלקות, מודולים (חבילות של מחלקות עם ניהול תלויות), תיקונים לכמה כשלים של שפת ג׳אווהסקריפט ועוד. ממש מהפיכה!
[ב] Prototype ו MooTools היו גם הן מועמדות ראויות, אך קהל המפתחים בחר לבסוף בjQuery. ניתן לקרוא על העיקרון מאחורי jQuery בפוסט מבוא מואץ ל jQuery.
[ג] כלים / Framework להגדרת מחלקות וכל מה שקשור בהן. בג'אווהסקריפט, כפי מתואר בפוסט מחלקות בג'אווהסקריפט. בשפת ג'אווהסקריפט לא קיימות מחלקות – ועל המתכנת לייצר אותן לבד. בעוד ספריות "JavaScript MVC" רבות מספקות סביבה אחידה / מוגנת ליצירת מחלקות עבור האלמנטים הבסיסיים בספריה (כמו Model או View).- ספריית Ember מספקת כלים שתוכלו להשתמש בהם עבור כל המחלקות בפרויקט שלכם.
[ד] המקור של MVC הוא בשפת Smalltalk בשנות ה-70. כשהגיעו ה Fat Clients (ב ++C), ולאחר מכן הווב – נוצרו פרשנויות ווריאציות שונות ל MVC על מנת להתמודד עם האתגרים החדשים שהציבו טכנולוגיות אלו.
