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