שיעור 2: יצירת אפליקציה חדשה

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

השלב הראשון:

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

אני נכנס לתיקיה דרך ה – cmd. ניווט ב – dos shell מתבצע על ידי פקודות. בעזרת הפקודה cd ניתן לנווט בין התיקיות השונות.

בתיקיית הבסיס נרשום את הפקודה הבאה:

ng new app-name

 

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

בהמשך, נישאל איזה גליון עיצוב (stylesheet) נרצה להשתמש – css או pre compiled css. אני אישית אוהב לעבוד עם scss, אבל כל אחד יבחר מה שבא לו. לאחר שהאפליקציה מוכנה נכנס לתיקייה של האפליקציה:כעת נריץ את האפליקציה בפעם הראשונה על ידי הפקודה:

ng open --serve

 

נקבל את המסך הבא:

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

אז בשלב ראשון נפתח את הקובץ src/app/app.component.html ופשוט נמחק את כל התוכן הנוכחי שלו. עכשיו נוכל להתחיל לכתוב את הקוד שלנו.

אבל לפני כן, בואו נבין איזה קבצים יש לנו כרגע בתיקייה app:

app.component.html

app.component.ts

app.component.spec.ts

app.component.scss

app.module.ts

app-routing.module.ts

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

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

בואו נראה עכשיו בפירוט, מה התפקיד של כל קובץ בתקייה app:

כל אפליקציה באנגולר מורכבת מארבעה קבצים: view, שהוא קובץ html. מחלקה, שהיא קובץ TypeScript, שזה למעשה הקוד מאחורי קובץ ה – html. גיליון עיצוב, שהוא קובץ ה – css (או .scss למשל באפליקציה שלנו – שזה למעשה כמו css רק מהודר מראש – Pre-Processor), וקובץ spec שזה ה – testing – נלמד על זה בהמשך. עקרונית כרגע אתם יכולים להתעלם, כי זה לא משפיע ישירות על האפליקציה. אבל יש לזה חשיבות מאוד גדולה. נלמד בהמשך. השורה התחתונה היא שאתם יכולים לפתח אפליקציה שלמה בלי לגעת בקבצי spec, אבל זה כמובן לא מומלץ. בקצרה: קבצי spec אלו קבצי הבדיקות – testing שמריצים, על מנת לוודא שהאפליקציה פועלת בלי שגיאות ובאגים.

app.component.html:

קובץ ה- html של הקומפוננטה. לכן הסיומת שלו היא html. נקרא גם ה – view. בקובץ הזה אנחנו כותבים את ה – html.

app.component.ts:

מכיל את מחלקת ה – Typescript. למעשה הקוד של הקומפוננטה. אנגולר ככלל עובדת במודל של MVVM: Model View View Model. זה מבנה בו יש לנו מודל – כלומר, הנתונים והקוד, שמופרד מה – view, הלא הוא ה – html.

app.component.scss:

גיליון העיצוב של הקומפוננטה. בדיוק כמו שיש לנו גיליון עיצוב לכל אתר אינטרנט שאנחנו מכירים. קומפוננטות באנגולר כפי שכבר ציינו, הם יחידות עצמאיות. לכן, לכל קומפוננטה יש מחלקת Typescript, ה – class. את ה – view, הלא הוא קובץ ה – html. וגיליון העיצוב, ה – css (בדוגמה שלנו בחרנו להשתמש ב – scss).

app.component.spec.ts:

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

לכן נרצה לוודא שהקוד תקין ועובד. אבל זה נושא בפני עצמו וכרגע אנחנו רק בהתחלה. כפי שכבר ציינתי, אתם יכולים לפתח אפליקציה שלמה בלי לכתוב בדיקת יחידה אחת. אבל, כמובן שזה לא מומלץ. בדיקות יחידה הם חלק בלתי נפרד מתהליך הפיתוח. בייחוד בתעשייה. כשאתם כותבים אפליקציה בבית בשביל הכיף, כנראה שלא ממש תקפידו על testing (רגע של כנות – גם אני כשאני מפתח לעצמי אני לא ממש מקפיד לכתוב בדיקות יחידה… – אבל ששש, אל תספרו !!) , אבל בעבודה תצטרכו לכתוב. והרבה. למעשה, ברוב המקומות תהיו חייבים. אבל לא נורא, זה לא כזה מסובך, ואפילו לפעמים די כיף.

app.module.ts:

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

את החלוקה למודולים אגב, חשוב לעשות לפני שמתחילים לפתח את האפליקציה. אפשר גם לאחר שמתחילים, אבל אז זה בלאגן. כאשר מקבלים את המפרט לאתר / אפליקציה, או כשיש רעיון לאתר או אפליקציה, חשוב לשבת לפני, ולתכנן את המבנה הלוגי של האתר / אפליקציה. כדאי ממש לשבת עם עיפרון, עט ונייר ולשרטט את מבנה האתר. הדפים שיהיו בו וכו׳. ואז להחליט על המודולים. עקרונית אתם יכולים להחליט שכל קישור בתפריט יהיה לו מודול משלו. זה נתון לבחירתכם. חשוב שזה ברור והגיוני. בד״כ מקובל ליצור מודול shared שיכיל בתוכו את הקומפוננטות הנפוצות, services (נלמד בהמשך), directives, וכו׳. אבל, כל זה, בהמשך הלימוד.

תחילת עבודה:

בואו ניגש לעבודה. יאללה להפשיל שרוולים.

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

תפתחו את הקובץ app.component.html בעורך קוד שלכם (notepad++, VSCode, או כל מה שבא לכם …), ודבר ראשון תמחקו את כל מה שכרגע יש שם. הקוד שאתם רואים זה אפליקציית דוגמא שה – CLI הכין עבורכם באופן אוטומטי. אנחנו לא צריכים את זה, כי אנחנו הולכים לכתוב את האפליקציה שלנו.

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

<h1>שלום עולם</h1>

 

אתם יכולים עכשיו להריץ את האפליקציה. זוכרים? פותחים את ה – Command line, מנווטים לתיקייה הראשית בה יצרתם את הפרוייקט, ומקלידים את הפקודה הבאה:

ng serve --open

עכשיו מה שיקרה, ה – CLI יהדר (compile) את האפליקציה ויריץ אותה בכתובת http://localhost:4200 בדפדפן שלכם. כל פעם שתשנו משהו ותשמרו, ה – CLI יעשה אוטומטית refresh ויציג את השינויים.

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

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

קוראים לזה אינטרפולציה (Text interpolation). בעזרת אינטרפולציה אנחנו יכולים להציג ב – html משתנים ממחלקת ה – Typescript. כלומר, נניח שהגדרנו במחלקה משתנה:

public message: string = "Hello World";

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

בואו נעשה את זה:

נפתח ונערוך את הקובץ app.component.ts: שימו לב למבנה של הקובץ. עוד רגע נבין אותו. אבל כרגע, מה שמעניין אותנו זה הבלוק קוד הזה:

export class AppComponent {
    public message: string = "Hello World";
}

שימו לב שה – CLI כבר שם לנו את title = 'my-tutorial';

אנחנו יכולים להשתמש בזה, אבל בוא נכתוב את הקוד שלנו. אז תמחקו את השורה הזו ושימו במקום את השורה הבאה: public message: string = "Hello World";

כעת, בקובץ ה – html, תחליפו את השורה הקיימת בשורה הזו: <h1>{{message}}</h1>

מה למעשה עשינו פה? אינטרפולציה למשתנה message

אתם יכולים עכשיו לתת כל ערך אחר שבא לכם במחלקה (class) ל – message והוא יוצג בדף.

עכשיו תתחילו להבין את העוצמה של אנגולר.

בואו נשים לב לשתי נקודות קטנות בקוד:

1. השתמשתי ב – public למשתנה. זה לא חובה כרגע, אבל אני רוצה שתתחילו להתרגל לכתוב קוד נכון. Typescript היא שפה מונחית עצמים. כלומר, אנחנו יכולים להגדיר משתנה כציבורי, פרטי וכו' (public, private). תכנות מונחה עצמים זה תחום בפני עצמו ומומלץ מאוד לקרוא וללמוד את הנושא. עקרונית, ברירת המחדל של משתנים בקומפוננטה הם public אבל כדאי תמיד להגדיר. לעיתים אגב, תרצו שמשתנה יהיה פרטי (private), כך שתוכלו להשתמש בו במחלקה בלבד. משתנה שהוגדר כ – private לא יוצג ב – html.
2. הגדרתי את message כמחרוזת: message: string  – הסיבה לכך היא כיוון שהסיבה ש – Typescript נקראת כך, היא כי אנחנו נותנים type למשתנים. זה שדרוג גדול מג'אווה סקריפט בה כל משתנה יכול להיות כל דבר – מחרוזת, מספר וכו'. זה לא חובה להגדיר את זה כך, אבל זה מאוד מומלץ וזוהי הפרקטיקה הנכונה. עקרונית הברירת מחדל של משתנה אם לא הוגדר לו ה – type יהיה any, שזה למעשה אומר כל סוג של משתנה. אבל זה לא מומלץ. ב – Typescript אנחנו מגדירים את ה – type של כל משתנה, וכדאי להתרגל לעשות זאת מהתחלה.

בוא נבין עכשיו את הקוד של הקומפוננטה:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  public message: string = "Hello World";
}

הקוד מתחיל בשורת ה – import.

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

אז מה הדבר הראשון שנייבא? כמובן, Component.

הרי אנחנו עובדים עכשיו על קומפוננטה, אז צריך לייבא את הקומפוננטה. מאיפה מייבאים אותה? מהליבה של אנגולר. או במילים אחרות: @angular/core

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

בשורות 4-7 אנחנו מגדירים את הסלקטור של הקומפוננטה שאנחנו יוצרים ואת הקבצים של הקומפוננטה. אנגולר למעשה מרחיבה את ה – html וכל קומפוננטה למעשה יוצרת תג html חדש. אז בשורה 4 אנחנו מגדירים את תגית ה – html של הקומפוננטה החדשה.

בשורה 8 אנחנו נותנים שם לקומפוננטה. אנגולר היא שפה מונחית עצמים. קומפוננטה מורכבת כפי שציינו למעלה מארבעה קבצים:

1. קובץ html. נקרא גם ה – view
2. מחלקה. TypeScript Class
3.  קובץ עיצוב – StyleSheet
4.  spec file – יחידות בדיקה

זו גם הסיבה שאנגולר נקראית MVVM: Model View View Model. כלומר, כל קומפוננטה מורכבת ממודל – כלומר, הנתונים והלוגיקה. ו – View. מה שרואים. ה – html.

אז בשורה 8 אנחנו מגדירים את המחלקה.

בשורה 9 אנחנו פשוט מגדירים משתנה ציבורי של המחלקה שאותו נציג ב – view.

בתכנות מונחה עצמים יש לנו מספר סוגי משתנים:

public: משתנה ציבורי. זמין במחלקה, ב – view וגם למחלקות אחרות.

private: זמין במחלקה בלבד.

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

זה הכל! יש לנו קומפוננטה!

רגע. בוא נעיף מבט זריז ב – html.

נפתח את הקובץ app.component.html:

<h1>{{message}}</h1>

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

אם נריץ עכשיו את האפליקציה בעזרת הפקודה:

ng serve --open

אנגולר CLI יקמפל את האפליקציה ויפתח בדפדפן בכתובת http://localhost:4200/ את האפליקציה. מה שכרגע נראה על המסך זה פשוט: Hello World.

והנה לנו האפליקציה הראשונה שלנו!

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