כלומר זה מתווך שמקבל את הבקשה מסיים את ההתקשורת ואז שולח את הבקשה לקוד הקיים שלי
תודה רבה גם ל @מנסה@אביי-ורבא@שמואל-ש עזרתם לי מאוד לחשוב על הדבר הטוב ביותר
תזכו למצוות
@מה כמו שכתבתי, אני מוכן לפתח את זה, אבל אין לי זמן להעתיק את ההגדרות מהפורום, ועד שהעניין הזה לא יתקדם, אני לא ימשיך להתקדם בענין הפיתוח (שכבר כעת הוא יעיל מאוד, אם רק יכניסו לו את ההגדרות..)
יתכן והם חסמו את עצמם על ידי הקשה על 9 בזמן שמיעת קמפיין
יתכן שהם דיווחו דרך השירות לקוחות בשלוחה 4
או שיש לך שלוחה ייעודית לכך
אם כל אלו ברור לך שלא קרו מציע לפנות לשירות הלקוחות בשאלה
עדיף כמובן מספר שהיה לא חסום והפך פתאום להיות חסום
(באופן רגיל הייתי יכול להחזיק טבלה במסד הנתונים שבשרת המקשרת מספרים לקטגוריות, וכך הייתי יכול לקבוע שכאשר הלקוח הקיש על 1 לדוגמא, הרי הוא בחר בקטגוריה X וכו'.
עם זאת, כאמור, בפרוייקט שלי אני שולח ללקוח בחזרה רשימת תתי קטגוריות לבחירה נוספת, כך שבפעם השנייה 1 הוא קטגוריה אחרת).
קודם כל יש לך אפשרות בread לקבוע שם לערך שתקבל מימות
כלומר בשלב השני יהיה לך בurl שני פרמטרים:
rootCat=1
subCat=5
אבל פה הרי בקבלת תשובה הוא לא ממשיך את הפעולה אלא קורא לשרת מחדש לגמרי, אז איך השרת יודע שהוא זה שאחז פה והוא אוחז בשורה X?
זה הטריק של הספריה. היא מתלבשת על מנגנון הראוטר של אקספרס
בעצם כשכותבים await call.read היא מחזיקה את הפונקציה "חיה" בהמתנה (שזה דבר שנוד מעולה בו, כל עניין האסינכרוניות) עד לקבלת בקשה נוספת עם אותו callId, ואז הPromise נפתר עם הערך שהתקבל בקריאה החדשה, והפונקציה ממשיכה בריצה.
וכך מבחינת המפתח אין שום איבוד נתונים, והפונקציה רצה מההתחלה לסוף לפי הסדר.