לוח זמנים וסטיט מורכב בריאקט - חוות דעת על מקרה מסוים

[נתנאל]

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

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

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

הענין הוא שכל האפקציה עצמה היא בריאקט, וצריך לשמור את כל זה בסטיט, ואחרי זה שמקבלים את זה מכניסים לסטיט ולפי זה זה מוצג.
המושכל הראשון היה אומר - מה הבעיה - תשמור בסטיט ימים, והוא יהיא אובקט או מערך או משהו, ושמה תשים את כל המידע שלך ושלום על ישראל. אך, בריאקט - אי אפשר להכניס לסטיט סתם כך, אלא צריך לעשות setState, וזה אומר שרק על אוביקט אפשר לעשות כזה דבר. ואם יש לי בסטיט את הימים בערך אחד, כדי להכני לשם מידע אני צריך לשכפל את כל הימים, לשנות משהו ולהחזיר בחזרה את כל האוביקט הגדול הזה. וגם ככה זה מידע ענק, יש שם עוד דברים חוץ מזה, ובגלל שהכל נשמר בסטיט זה מאוד איטי.
אני חשבתי לעשות איזה משהו די יצירתי, וקבלתי ביקורת. אני הייתי שמח לשמוע איך אתם ניגשים לבעיה מסוג זה.
אני חשבתי בכיון כזה. מכיון שהכל חייב להיות בסטיט, ואי אפשר לשים את הכל על אותו ערך כיון שזה מאוד יכביד, אני צריך לחשוב על דרך לבודד את הkeys של הימים משאר אלו שנמצאים בסטיט. ומכיון שימות השבוע הם מספריים, חשבתי ליצור KEY שהוא מספר. לעבור באיטרציה על כל הקיס בסטיט ומה שהוא מספר, הוא יהא יום. וככה כאשר אני עושה setState אני לא צריך לשכפל אוביקט גדול - שבמקרה הזה הוא באמת מאוד גדול - וגם מורגש בברוזר, אלא רק את אותו יום.
הדיון הסוער ניסוב על משל של ארון ובגדים.
היו שטענו - אתה צריך לשים קופסא בארון - ושם לשים את הגרביים, לא יתכן שסתם תזרוק את זה פנימה ואחרי זה תעבור אחד אחד isGerev
ואילו אני טענתי - זה יותר כמו ארון גדול שכתוב "חולצות" בגדול, רק למטה יש קצת מקום ולא נורא גם להפגש איתו.
בסופו של דבר - נוצרה בעיה עם זה כי קיס של אוביקט בעקרם הם סטרינגיים, ולא נומבריים, ולכן היה צריך איזה התאמה של מה שבא והולך לDB בשלבם - אבל אני נפנפתי בזה שהנה עכשיו זה עובד הרבה יותר מהר עם חווית משתמש הרבה יותר טובה באופן משעמותי ומורגש.
אשמח לשמוע תובנות בנודע לעינן חשוב זה.

הקוד הזה:

save() {
    let temp = this.state
    let arr = []
    for (let key in temp) {
      if (!isNaN(key)) {
        for (let index = 0; index < temp[key].length; index++) {
          if (temp[key][index].times) {
            temp[key][index].times = temp[key][index].times.filter(p => p.value === true)
            temp[key][index].productId = this.state.productId
            arr.push(temp[key][index])
          }
        }
      }
    }

פורסם במקור בפורום CODE613 ב09/11/2017 21:40 (+02:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב09/11/2017 22:30 (+02:00)

[נתנאל]

מסעדה אחת, יש לה זמנים מסוימים בשבוע שהיא יכולה לקבל הזמנות ממני.
בא משהו מהמסעדה וצריך להכניס את השעות האלו. ואני צריך לשמור אותם.
נניח - כל יום בשבוע ביום שלישי אני יכול לקבל 6 אנשים לארוחת בוקר משעה 10 עד 12
ואחרי זה לארוחת ערב בין 7-9, 9 אנשים.
ביום שני אני יכול בין 1-2 לבראנץ.
וכן על זה הדרך.

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

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

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

פורסם במקור בפורום CODE613 ב09/11/2017 22:40 (+02:00)

[dovid]

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

1. המציאות:
   א. מתווך שרוצה לשלוח אנשים למסעדה המתאימה להם לפי קירטריונים של איזור ועוד פרטים. ב. אלא שהוא צריך גם לדעת על כל מסעדה אדות זמן* נתון איזה ארוחה יש לה וכמה כמות היא יכולה לקבל.
   ג. המסעדות נותנות לו את התחזית של מקומות לפי זמן, ד. התחזית לפעמים לא רלוונטית. הם מודיעים לו על כך, והוא יודע לא לשלוח אליהם עד שהם יודיעו לו על חזרה לשגרה.
   ה. לפני שהוא משתמש בתחזית הוא עובר לבדוק אם המסעדה בסטנדרטים שמתאים לו לעבוד איתה.
   ו. זמנים אלו של סעיף א' נמדדים עד רזולוציה מדוייקת אבל הכללים על הזמנים יכולים לנוע מכללים ברמת השבוע לכללים ברמת היום (למשל: כל יום מ9 עד 8 ומ4-5 למעט יום שלישי).

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

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

אפשרות ב'
הדילמה בכלל בחלק השלישי. ש...

פורסם במקור בפורום CODE613 ב09/11/2017 23:23 (+02:00)

[נתנאל]

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

פורסם במקור בפורום CODE613 ב10/11/2017 09:24 (+02:00)

[avr416]

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

אבל אודה ואתוודה שלא הצלחתי להבין את מה שתיארת, אשמח אם תבהיר יותר.

פורסם במקור בפורום CODE613 ב10/11/2017 09:35 (+02:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב10/11/2017 10:09 (+02:00)

[נתנאל]

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

this.state.myObj.myProp = myVl

אלא אתה חייב לעשות כזה

let temp = this,.state.myObj
temp.myProp = myVal
this.setState({myObj : temp});

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

deleteSlot(d, i) {
    let temp = this.state[d]
    if (temp[i].objectId) {
      this.setState({ arrToDelete: [...this.state.arrToDelete, temp[i].objectId] }, () => console.log(this.state.arrToDelete))
    }
    temp.splice(i, 1)
    this.setState({ [d]: temp })
  }

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

פורסם במקור בפורום CODE613 ב10/11/2017 10:47 (+02:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב10/11/2017 11:30 (+02:00)

[נתנאל]

ידעתי שלא תאהב את התפאורה של זה

פורסם במקור בפורום CODE613 ב10/11/2017 11:52 (+02:00)

[avr416]

@נתנאל

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

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

this.setState({days: [מה שתרצה] });

ריאקט לבד יודע לעדכן בסטייט רק את הפרופרטיס הזה, לא?
או שלא הבנתי אותך..

בכל אופן, שיהיה בהצלחה!

פורסם במקור בפורום CODE613 ב10/11/2017 13:31 (+02:00)

[נתנאל]

את זה אתה יכול לעשות, אכן, אבל את זה אתה לא יכול לעשות

this.setState){days.sunday[i].times[i].value : 700})

ואת זה אתה יכול לעשות

this.setState({sunday :temp})

פורסם במקור בפורום CODE613 ב10/11/2017 14:43 (+02:00)