רידקס - יצירת Data Service
store (getState, dispatch, subscribe) יהיה אך ורק בסרוויסים.ProductService. ממנה נוצר אובייקט אחד שמיוצא כ-export default.getAllProducts היא async שמחזירה Promise של אוסף מוצרים. אם אין מוצרים ב-State היא פונה ל-Backend ושולחת ל-Redux, ובסוף מחזירה אותם מה-State. בקומפוננטת הרשימה נשארת שורה אחת עם await.getOneProduct מקבלת ID, מחפשת מקומית עם find ואם אין מוצר פונה ל-Backend. כך עובד גם משתמש שהקליד כתובת של מוצר שאין לו אצלו. אין בעיה לכתוב שהפונקציה מחזירה Promise ולהחזיר ערך רגיל, כי async עוטף אותו אוטומטית.addProduct, updateProduct ו-deleteProduct מקבלות את הקוד שהיה בקומפוננטות: הפנייה ל-Backend ואחריה dispatch. בעדכון צריך להכניס למוצר את ה-ID לפני השליחה, כי הטופס לא מכיל אותו.subscribe מהקומפוננטה: בסרוויס נבנית פונקציית subscribe שמקבלת callback ומחזירה את ה-unsubscribe. ה-callback מקבל רק את ProductState ולא את כל ה-State, ולכן הקוד בקומפוננטת total products קצר יותר.getAllEmployees.store.: חיפוש בכל הפרויקט (Ctrl+Shift+F) אחרי store. מראה שנשארו שימושים מחוץ לסרוויסים, וכך מוצאים מה עוד להעביר.await בקריאה ל-addProduct: הרשימה מוצגת לפני שהמוצר מגיע ל-Backend ולכן הוא לא מופיע. אחרי הוספת await זה עובד.פרקי ההרצאה: רידקס - יצירת Data Service
תמלול ההרצאה: רידקס - יצירת Data Service
הטקסט המלא של הדקות הראשונות בהרצאה «רידקס - יצירת Data Service» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טוב, אז אנחנו בעצם ראינו את כל ה-Basics של Redux. אנחנו ראינו איך אנחנו בונים את התשתית של Redux, איך אנחנו יוצרים את כל האלמנטים האלה שנמצאים בתשתית עצמה, כמו את ה-State, Action Types, Action,
את ה-Action Creators ואת ה-Reducer וכמובן את ה-Store. אנחנו ראינו איך אנחנו משתמשים, Dispatch, Get State, Subscribe ו-Unsubscribe.
אבל יש משהו שהוא לא פחות חשוב שכדאי להבין בנוגע לעבודה עם רידאקס. אם אנחנו מסתכלים רגע על השימוש ברידאקס אז כמובן אנחנו משתמשים ברידאקס בתוך הקומפוננטות.
מתוך קומפוננטות שצריכות את הגלובל סטייט הזה אז אנחנו יכולים לגשת לסטור ולקרוא לגט סטייט ולהגיע לאיזה סטייט גלובלי שאנחנו רוצים ואנחנו יכולים לבצע dispatch ואנחנו יכולים לבצע subscribe ו-unsubscribe מכל מקום במערכת אבל זה לא הכי אלגנטי ולא הכי קוד דיזיין יפה מה שנקרא שיש לנו הרבה
קוד שנמצא בתוך הקומפוננטה שמתעסק עם המידע הזה בואו נסתכל רגע מה כתוב לנו משורה 21 עד שורה 26 כל השורות האלה בעצם אנחנו באים בתור קומפוננטה שאחראית על UI, User Interface, מה שהיא עושה זה אומרת בואו נראה רגע אם יש לי את המידע הזה ב-State שלי, כלומר המידע נמצא אצלי.
אם לא, אז אני גולש ל-Backend ומביא את המידע, שולף אותו, מעדכן את ה-State ואז יש לי את המידע אצלי מקומית בצד של ה-Front End ואז אני מעדכן את ה-State המקומי.
כל הדבר הזה זה too much logic שקשור לדאטה שהקומפוננטות צריכות עכשיו להתעסק איתו. זה לא שזה לא עובד, אנחנו ראינו שהכל בעצם עבד עד כאן. אבל מה קורה אם יש לנו הרבה לוגיקה בתוך קומפוננטות?
ראינו שנכון להוציא את כל הלוגיקה הזאת לסרוויסים נפרדים, וזה בעצם מה שנכון לעשות במקרים האלה. אז אנחנו רוצים עכשיו לבנות סרוויס שמאפשר לנו להתעסק עם כל המנהלות האלה של בוא תבדוק לי אם המידע קיים ואם לא לך לשרת ותביא לי אותו ואם כן פשוט תחזיר אותו לקומפוננטה או למי שרוצה ואז מירב העבודה נמצאת
בתוך הסרוויסים והקומפוננטה מכילה את המינימום לוג'יק קוד שדרוש רק בשביל להביא את המידע. במילים אחרות, הקומפוננטה לא אמורה להתעסק עם השאלה האם המידע נמצא אצלי כן או לא ואם לא לך לשרת תביא לי אותו.
זה לא משהו שה-UI צריך להתעסק איתו. הקומפוננטה צריכה לבוא לסרוויס ולהגיד לסרוויס בצורה הכי פשוטה תביא לי בבקשה את המידע. זהו.
הסרוויס שהוא מכיל את הלוגיקה צריך לעשות את ההחלטה רגע יש לי את המידע מקומית אין בעיה אני אביא לך אה אין לי אותו מקומית אני אלך ל-Backend אני אביא אותו אני אשים אותו מקומית ואז אני אביא לך.
זאת אומרת רוב הקוד הזה שמתעסק עם השאלות האלה לגבי הדאטה בכלל לא אמור להיות בקומפוננטות. אחרי שנעשה את זה תראו שבתוך הקומפוננטות הולך להיות מינימום קוד.
בואו נעשה את זה על ידי בניית סרוויס נפרד. אז ניגש רגע לסרוויסים, אני אייצר פה סרוויס, אני אקרא לו product service, הוא מתעסק עם כל מה שקשור למידע של המוצרים.
יש לנו פה class product service, ואנחנו רוצים לייצר אובייקט, קונסט פרודקט סרוויס, ניו פרודקט סרוויס, ולהחצין את האובייקט, אקספורט דיפולט פרודקט סרוויס כאובייקט.
כאן בתוך המחלקה שלנו הולכות להיות כל הפונקציות הדרושות על ידי הקומפוננטות השונים של המוצרים. לדוגמה הולכת להיות לנו פונקציה, בואו נעשה אותה כבר אסינק, של get all products.
הפונקציה הזאת ניגשת ל-Backend אם צריך ומביאה לי את כל המוצרים ואם לא אז יש לי גם מוצרים מקומיים היא כבר תחזיר אותם אז בגלל שהיא יכולה ללכת ל-Backend אז היא תחזיר promise של מערך מוצרים product model collection והפונקציה עושה את הבדיקה אם Store האמת יש לנו כבר את הבדיקה הזאת כאן אז basically זה כל זה כבדיקה אחת את ה-Store אנחנו רוצים תביא לי את ה-Store, תביא לי את ה-Access,
תביא לי בבקשה, מאיזושהי סיבה הוא שם לי את זה במסולסלים, הוא לא אמור, תביא לי את הפונקציה של ה-Action Creators ותביא לי את ה-Config, הוא לא מוצא לי אותו, למה הוא לא מוצא לי?
הוא אמור למצוא לי, הנה הוא פה. מעולה. אז בואו נסתכל, אם אין לנו את המידע המקומית, לך ל-Backend, אנחנו רוצים ללכת ל-Delay, יאללה, בואו נשאיר עם ה-Delay כרגע, תביא לי את ה-Response, אשלוף לי אותו לכל
המוצרים ואשלח אותם ל-Redux. בסופו של דבר, אחרי הפונקציה הזאת, כי הפונקציה הזאת במקרה הזה היא סינכרונית, אז אנחנו יכולים לדעת שאחרי ה-if הזה, אם ה-if הזה מתבצע כמובן, אני כבר כאן יכול to return, store, get state, product state,
אנחנו multiple reducers, products. זהו, alright, בואו נשתמש איתה. מה שאנחנו רוצים לעשות זה לגשת לפרודקט ליסט ולהיפטר מכל זה אנחנו לא צריכים את כל זה וגם אנחנו לא צריכים את כל זה אנחנו רוצים, בואו רגע נמחק את הכל אנחנו רוצים כאן לבוא לפרודקט סרוויס נקודה
get all products זהו, תשמע, פה חסר לי כמובן awake בוא תבדוק לי אתה האם יש לך את המוצרים כן או לא. אם יש, תביא לי, אם אין, לך לשרת ואז תביא לי.
יש לנו פה מינימום קוד שמתבצע בתוך product list וגם כאן אנחנו יכולים עכשיו לנקות, אנחנו לא צריכים את ה-access ואנחנו לא צריכים את זה ואת זה ואת זה.
הרבה יותר קוד נקי יש פה בקומפוננטה. סך הכל שורה אחת, הסרוויס מתעסק עם להביא או לא להביא את המידע. יופי, בואו נראה מה יש לנו בקומפוננטה הבאה. בקומפוננטה הבאה זה Product Detail.
Product Details, בואו נראה מה יש. Product Details, הלכנו לסטור ועשינו את החיפוש. שוב פעם, הנה לוגיקה, לא אמורה להיות בדרך כלל בתוך הקומפוננטה.
ותביא לי את המוצר ואז תעדכן לי. לא רוצה לעשות את כל הדבר הזה. אנחנו רוצים כמה שפחות קוד. אנחנו בעצם כמעט לא רוצים להשתמש עם הסטור, לא עם ה-GetState ולא עם ה-Dispatch בקומפוננטות השונות.
כל הדברים האלה זה סוג של לוגיקה, שימו את זה ב-Service. In a Product Service, בואו נייצר פה פונקציה Public Get One Product, היא תקבל ID, Number ותחזיר לנו את המוצר. האמת, בואו אפילו נשכלל אותה.
בואו נגיד, אם המוצר לא קיים מקומית, לך תביא לי אותו מה-Backend, אפילו שפה לא עשינו את זה. אולי מאיזושהי סיבה היוזר כן ירצה לראות איזשהו מוצר שלא קיים לו על ידי זה שהוא רושם אותו ב-URL למעלה ואין לו את המוצר, אנחנו יכולים לגלוש ולהביא לו.
אז אנחנו רוצים פה אסינק, אנחנו רוצים פרומיס של פרודקט מודל, ואנחנו רוצים קודם כל לגשת מקומית ולהביא את המוצר.
אם אין, אז אני אלך ואביא אותו מהשרת. אז בואו נלך ונייצר פה עם let product, store, get state, product state, שימו לב כמה קוד מיותר כתוב כאן שאם לא הייתי כותב אותו פה הוא סתם היה לי בתוך הקומפוננטות
ואני לא רוצה הרבה לוגיקה בתוך הקומפוננטות. אני רוצה בתוך הקומפוננטות מינימום לוגיקה, מינימום קוד ורק UI. בואו נעשה find, תחפש לי את ה-ID שהתקבל לפונקציה, רק אם אין לי את המוצר הזה, product, אז לך תביא לי אותו מהבקאנד.
קונסט רספונס, ה-wait, access, get product model, config urls, product משורשר עם ה-id וה-product שהוגדר למעלה ו-response data, turn product.
אם אתם שואלים את עצמכם איך זה יכול להיות שפה כתוב promise ופה אני מחזיר product model, זה כאילו לא מסתדר, אז מה שמתרחש בפועל זה שברגע שכתבתם פונקציה async, כל מה שאתם מחזירים אוטומטית נהטף בפרומיס.
אם הייתי מחזיר פה 1, 2, 3 אז היה נהטף פה כמובן שפה number כתוב אז היה נהטף ה-1, 2, 3 בפרומיס שמחזיר את 123. אז אין שום בעיה לכתוב פה פרומיס ופה להחזיר משהו שהוא כביכול לא פרומיס כי אסינק כן מחזירה בסופו של דבר פרומיס מהפונקציה.
כנ"ל גם כאן כמובן. הנה יש לנו עכשיו פונקציה ששימו לב כמה לוגיקה כתבתי בתוכה ואני בעצם מוציא את הלוגיקה הזאת מהקומפוננטות.
בואו ניגש עכשיו לקומפוננטה הזאת של product details ונגיד this.setStateAwait של productService.getOne. קח את ה-ID הזה, שלח לפונקציה ותיפטר משתי השורות האלה.
הנה יש לנו עכשיו מינימום לוגיקה. ממש רואים, שורה אחת ויחידה. ניפטר מהסטור גם, כל מה שאנחנו לא צריכים פה באזור הגלובלי. למה אנחנו צריכים את הקונפיג?
אה, יש לנו פה תמונה, בסדר. בואו רגע נבדוק אם כל הסיפור הזה עובד. אז ניגש רגע לפרודקטס, הנה הוא רץ לו, שלוש שניות, וניגש ל-one product, הכל עובד פרפקט.
יופי. בואו נשלים. יש לנו את הוספה של מוצר חדש. הנה הוא. וואו, תראו כמה קוד מיותר יש פה.
כל זה וזה וזה בכלל לא אמורים להיות בקומפוננטה. זה לוגיקה, לוגיקה, לוגיקה. אלרט, זה בסדר, זה UI. היסטורי פוש, יאללה, פיין, משהו שהקומפוננטה כן אמורה להתעסק איתו.
בואו ניגש לפרודקט סרוויס ונבנה כאן פונקציה. נקרא לפונקציה הזאת Public Async Add Product. תן לי פרודקט מסוג פרודקט מודל, אני אחזיר לך פרומיס, האמת אני לא צריך להחזיר לך אפילו שום דבר.
אני אחזיר פרומיס של ווייד. מה עשינו כאן? אה, פה הצגנו את ה-ID, אני אפטר מזה, אני לא צריך להציג ID's של מוצרים, ל-user זה משהו שאף פעם לא עושים, לא מציגים ID's של דאטאבייסים, וזה גם לא אמור לעניין את המשתמש, וזה גם סוג של Out Security, הוא לא אמור לראות מה הקודים שיש לנו בדאטאבייס.
אז מה אנחנו רוצים לעשות? הדבר הראשון שאנחנו רוצים לעשות זה לבנות את כל זה, ואז לגלוש לבאק, ואז לקבל את המידע, ואז להוסיף לרידקס. האמת, כל הקוד הזה אני אגזור ואני אשים פה.
מה אנחנו צריכים? את זה אנחנו צריכים. ויצרנו פורום דאטה, מפני שהבאק-אנד צריך להתעסק עם פורום דאטה. הנה הוא נשלח לבאק. הנה ה-product to add, והנה שלחנו אותו ל-Redux ונראה לי שזהו, אנחנו לא אמורים להחזיר שום דבר מהפונקציה, יכלנו להחזיר את המוצר אבל אני לא רואה סיבה כרגע למה.
הדבר שאנחנו רוצים לעשות כאן, את זה ניפטר, בואו ניפטר מההודעה של ה-ID הזה ונכתוב כאן Product Service Add, הנה המוצר, תוסיף לי אותו, בואו נראה מה אפשר למחוק מפה למעלה, אני אוהב למחוק קודים, לא יודע מה איתכם, הנה אני מוחק מוחק מוחק מוחק ויש לנו הרבה הרבה פחות קוד שנמצא לנו בקומפוננטות כמו שאנחנו יכולים לראות עכשיו.
אתם רואים Ui זה בסדר שיהיה לוגיקה פחות את זה גם היינו יכולים להוציא אבל רק אם בא לכם כרגע ויכול להישאר. פול בואו נבדוק האם כל הסיפור הזה עובד. אז אנחנו רוצים להוסיף מוצר בואו נוסיף כרגע אפל 1.2 יש לנו 30 במלאי הנה יש לנו גרין אפל ובואו נבצע אד אנחנו רואים את ההודעת הצלחה אנחנו רואים פה למטה את הגרין אפל אנחנו לא רואים אותו זה לא אוקיי למה אנחנו לא רואים אותו אמרו שפה אנחנו רואים 81 זה
מוזר לי בואו נרפרש אולי הוא לא או שלח אותו לבאק אנד, כן שלח, אוקיי, יש לנו באג, לא קרה כלום, אורנג', 1, 1, 2, 2, תן לי אורנג', go, add, הוספת, אין לנו אורנג', טוב, אנחנו צריכים למצוא את הבאג, למה יש לנו באג פה, ומה יכולה להיות הבעיה, פה קראנו לפונקציה, הפונקציה הזאת היא אסינכרונית, ושכחתי ה-wait, אוקיי, לא קרה כלום.
אז מה שקרה זה הוא לא הספיק להגיע ל-back וכבר הציג לנו את הקומפוננטה של המוצרים מפה, גלש עליה ועדיין לא ראינו את המוצר. בואו נבדוק את זה שוב, האמת, אולי ניפטר קצת, לא משנה, בואו נרפרש רגע ונראה מה אנחנו עוד יכולים להוסיף, בואו נוסיף עוד Pitch, אוקיי, אז פיצ' טיים נקרא לו,
נראה שהכל עובד כמו שצריך, גו והנה פיצ' יופי היה חסר לנו הווייט, לא