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

[נתנאל]

מסעדה אחת, יש לה זמנים מסוימים בשבוע שהיא יכולה לקבל הזמנות ממני.
בא משהו מהמסעדה וצריך להכניס את השעות האלו. ואני צריך לשמור אותם.
נניח - כל יום בשבוע ביום שלישי אני יכול לקבל 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)