עידן יצחקיבכל פרויקט של אנגולר רצוי להחליט לפני שמתחילים לבנות אותו, מה הדרך הכי נכונה לבנות את הרכיבים שלו.
ישנם 2 דרכים פופולריות לבנות רכיבים בפרויקט אנגולרי וצריך לשקול ולהבין את היתרון והחיסרון של כל שיטה.
נתחיל קודם בהגדרות שכנראה שתשמעו ותיתקלו בהן הרבה כשמדברים על מבנה רכיבים בפרויקט:
- smart component – רכיב חכם
- dumb component – רכיב טיפש
המשמעות של כל אחד מהם:
רכיב חכם
זהו רכיב שמתקשר עם השרת, עושה מניפולציות על המידע ובעצם לא תלוי באף רכיב אחר כדי לקבל ולהחזיר מידע מהשרת.
רכיב טיפש
זהו רכיב שמקבל בדרך כל את המידע ב-input מהרכיב שמארח אותו (שהוא בדרך כלל רכיב חכם) והתפקיד שלו רק להציג את המידע ולעדכן את המארח שלו אם המשתמש לחץ על משהו שגורם לשינוי בנתונים. רכיבים אלו בדרך כלל דורשים מבנה נתונים מסויים ויותר קל לעשות מכמה רכיבים כאלו הרכבות של רכיב גדול יותר.
נתחיל במספר כללים שאני מוצא אותם מקלים בבנית פרויקט, גם אם הוא מתרחב
כל רכיב שבונים מכיל בספריה שלו בנוסף ל-html, ts, css/scss גם את ההגדרות (interface) של האוביקטים שלו.
במידה שיש הגדרות כלליות שחוזרות על עצמן במספר רכיבים שונים אפשר להקים ספריית share ובתוכה תת-ספריה interfaces ושם לשים קבצי הגדרות משותפים.
במידה שאין שרת והמידע מגיע מאוביקט שמדמה תשובה של שרת (mock) , יש לפתוח בתוך ספריית assets תת-ספריה mocks ושם לשים את כל הקבצים עם המידע שלנו.
תמונות יהיו ב- assets/images ואייקונים יהיו ב- assets/images/icons
פונטים (במידה שאתם משתמשים בפונטים מיוחדים) יהיו ב- assets/fonts
את הרכיבים שמרכיבים דפים יש לשים בספריית components.
את הרכיבים שמיצגים את דפים עצמם יש לשים בספריית pages.
עם הזמן יהיו לכם עוד קבצים מסוגים שונים אבל עד אז אתם תבינו כבר את הרעיון ולאן הקבצים האלו צריכים ללכת.
כמובן, שכל אחד יכול להחליט על מבנה שמתאים לו יותר, אני מצאתי את המבנה הזה כמאוד נוח לי.
נמשיך עם הרכיבים!
על פי מה אחליט באיזה שיטה להשתמש?
אם הפרויקט (על פי עיצוב או איפיון) בנוי מכמות רכיבים יחודיים לא גדולה וכל רכיב לא מסובך בבניה שלו ברשות עצמו אז בדרך כלל אלך לכיוון רכיבים חכמים בלבד וכך אני יודע שבכל מקום שאשים את הרכיב, אני לא צריך לדאוג ליצר בקשה לשרת מהאבא שלו אלא הוא בעצמו דואג לזה ובמידת הצורך גם משדר לשרת או לסרויס (service) את המידע על פי הצורך. זאת אומרת, שהוא קופסא שעומדת ברשות עצמה עם תפעול מלא ללא התערבות מבחוץ.
ככל שהרכיבים מסובכים יותר וחוזרים על עצמם כאשר הם מראים מדע אחר אני אעדיף ללכת יותר לכיוון של רכיבים חכמים ורכיבים טיפשים להצגת המידע.
נכון שהרכיבים הטיפשים תלויים במארח שלהם ומתקשרות איתו כך שאנחנו צריכים לטפל וליצר באבא פונקציות שידעו לתקשר עם הרכיב הטיפש אבל היתרון המאוד גדול של השיטה היא, מרגע שיש לי את הרכיבים הטיפשים אני צריך להתעסק רק בהרכבות (כמו פאזל) של הרכיבים לרכיב גדול יותר.
אני גם יודע שכל השליטה נמצאת ברכיב החכם והוא עושה את העברה של המידע בין הרכיבים השונים, שינוי של המידע בין רכיב לרכיב ותקשורת עם השרת. זה יתרון משמעותי בתחזוקה מאוחר יותר בפרויקט.
עוד יתרון, כאשר רוצים לשנות משהו בדף, השינוי הוא רק ברכיב אחד קטן ללא השפעה על הסביבה שלו ולכן גם יותר קל לתחזק את זה גם אם מגיע מפתח שלא מכיר את הקוד בכלל.
מצד שני
בניה רק ברכיבים חכמים עלולה לגרום לבקשות מהשרת עם מדע כפול שהיה כבר בבקשה אחרת של רכיב אחר.
כל רכיב בדרך כלל עם יותר לוגיקה ויותר HTML בתוכו ולכן התחזוקה לפעמים קשה יותר ושינויים בו קשים יותר.
בניה ברכיבים חכמים וטיפשים גורמת לכתיבת קוד יותר ארוכה, עבור כל רכיב , יותר פונקציות. צריך לשים לב ששינוי ברכיב טיפש גורר שינויים בעוד רכיבים בדף ובדפים אחרים שמשתמשים ברכיב הזה.
כדי להעביר את המידע צריך לבצע חיבורים כמו שרשרת של inputs ו- outputs , שזה קצת פחות נח.
יותר רכיבים בספרית components ולכן הפרויקט נראה גם מנופח יותר, מה שמקשה על התמצאות בו.
לסיכום
אני לא חושב שיש דרך אחת לבצע את כל הפרויקטים ולכן זה מאוד תלוי בפרויקט, לא הייתי ממליץ לשלב את הדרכים ביחד בתוך הפרויקט, זאת אומרת, שחלק מהרכיבים יהיו רק חכמים וחלק יהיו גם וגם.
זה יסרבל את התחזוקה בעיקר ואת הצפייה של המפתח כשהוא בה לבצע שינויים ברכיבים.
