PracticU

ולידציה בריאקט - React Validation

בלי כתוביותעם כתוביות
PracticU › קורס ריאקט - React › ולידציה בריאקט - React Validation
מילון מושגים:
React - ספריית JavaScript לבניית ממשקי משתמש מבוססי רכיבים, שפותחה על ידי פייסבוק.
צד לקוח - החלק של היישום שרץ בדפדפן ומולו המשתמש מתקשר, הכולל את התצוגה והאינטראקציה.
הוק - נקודת חיבור שמאפשרת להריץ קוד מותאם בשלב מסוים של תהליך. ב-React, מנגנון לניהול מצב ויכולות ברכיבים.
טופס - אזור בממשק שבו המשתמש מזין נתונים בשדות ושולח אותם, למשל טופס הרשמה או התחברות.
בקשה - פנייה שלקוח שולח לשרת כדי לקבל מידע או לבצע פעולה. השרת מחזיר עליה תגובה.
תגובה - המידע שהשרת מחזיר ללקוח בתשובה לבקשה, הכולל בדרך כלל נתונים וקוד סטטוס.
צד שרת - החלק של היישום שרץ בשרת ואחראי על הלוגיקה, מסדי הנתונים והעיבוד שמאחורי הקלעים.
תמונה - קובץ גרפי המוצג על המסך. בהקשר של וירטואליזציה או Docker, תבנית מוכנה שממנה יוצרים מכונה או קונטיינר.

ולידציה בריאקט - React Validation
ולידציה היא אימות הקלט של המשתמש. ההרצאה מסבירה למה בודקים גם בצד לקוח וגם בשרת, ומראה איך מוסיפים כללי ולידציה ל-register ב-react-hook-form.
למה ולידציה בשני הצדדים
1. מה השרת עושה: כששולחים שם של אות אחת, מחיר שלילי ומלאי גבוה מדי, השרת מחזיר שגיאת 400 Bad Request עם הסבר, למשל שהשם חייב להיות לפחות שני תווים. את הפרטים רואים ב-error.response.data.
2. למה זה לא מספיק: ההודעות באנגלית ובפורמט של השרת, והשליחה מבזבזת זמן גלישה ועומס על השרת.
3. הכלל: בודקים גם ב-Front וגם ב-Back. ה-Backend תמיד בודק, כי הוא לא יודע מי בנה את ה-Front, וייתכן שמישהו עוקף אותו ושולח לו נתונים שגויים. ב-Front בודקים כדי לחסוך נסיעה לשרת.
4. החריג: בדיקה שדורשת מידע ממסד הנתונים, כמו אם אימייל כבר קיים בהרשמה, אפשר לעשות רק בשרת.
הוספת הכללים
5. אובייקט שני ל-register: register("name", { required: true, minLength: 2, maxLength: 100 }).
6. מספרים: ב-price ו-stock משתמשים ב-min ו-max ולא ב-minLength. ל-price המינימום 0 והמקסימום 1000, ול-stock המינימום 0 והמקסימום 10000.
7. תמונה: רק required: true.
בדיקה
אחרי הוספת הכללים, לחיצה על Add עם נתונים שגויים לא שולחת בקשה לשרת. אבל המשתמש לא מקבל הסבר מה לא תקין, ולכן ההרצאה הבאה עוסקת בהצגת הודעות שגיאה.
אחרי ההרצאה אפשר להגדיר כללי ולידציה לכל שדה בטופס ולהבין איפה הם נבדקים.
השיעור הבא בקורס: הצגת הודעות שגיאה למשתמש בריאקט - Validation Messages

פרקי ההרצאה: ולידציה בריאקט - React Validation

  1. 00:00

    מהי ולידציה של קלט

  2. 00:43

    שגיאת Bad Request 400

  3. 01:41

    שגיאות הוולידציה מהשרת

  4. 02:43

    ולידציה בפרונט ובבק

  5. 03:22

    מקרים שרק השרת בודק

תמלול ההרצאה: ולידציה בריאקט - React Validation

הטקסט המלא של הדקות הראשונות בהרצאה «ולידציה בריאקט - React Validation» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

  1. 00:02

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

  2. 00:30

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

  3. 00:48

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

  4. 01:01

    בעצם כי זה access, access מחזירה את זה. ננסה שוב פעם, והוא נותן לנו error שלא כל כך ניתן להבין מה זה. בואו נראה, אולי יש לנו פה data ב-error הזה.

  5. 01:17

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

  6. 01:47

    לנו יש לכם פה name must be minimum 2 chars, the price must be minimum 0, אתם רואים שהשרת מחזיר את המידע הזה. שימו לב שספציפית השרת לא מחייב אותנו לשלוח תמונה עבור מוצר, אבל זו כבר החלטה של השרת עצמו.

  7. 02:11

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

  8. 02:22

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

  9. 02:32

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

  10. 02:48

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

  11. 03:16

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

  12. 03:30

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

  13. 03:46

    רגע, למה לשכפל את הוולידציה? למה לא מספיק רק בפרונט? ה-Backend לא יודע מי זה הפרונט, הוא לא יודע מי בונה את הפרונט-אנד והאם באמת הייתה

לקורס המלא: קורס ריאקט אונליין

ההרצאה הקודמת: הצגת תמונה בריאקט

ההרצאה הבאה: הצגת הודעות שגיאה למשתמש בריאקט - Validation Messages

הרצאות קשורות מקורסים אחרים

  • ולידציה - Validation
  • Validation - ולידציה
  • ולידציה על קלט המשתמש - Validation
  • ביצוע ולידציה על POST Requests

קורסים נוספים במסלול

  • קורס יסודות HTML - בניית אתר אינטרנט פשוט
  • קורס CSS 3 - בדגש על Flex & Grid
  • קורס Javascript כולל JQuery
  • קורס ג'אווה סקריפט מעשי - JavaScript
  • קורס TypeScript
  • קורס NodeJS