מועדפים ב-Bitrix עם Vue.js: מדוע הרשימה נעלמת בעת רענון
תמונה קלאסית: המשתמש מוסיף מוצר למועדפים, מרענן את הדף — והרשימה ריקה. הסיבה היא שבתבניות צד-שרת של Bitrix מצב המועדפים חי רק בתגובת השרת הנוכחית. הקומפוננטה עיצבה את הרשימה, החזירה HTML — וזה הכל, מכאן הדפדפן לא מנהל דבר. כל פעולה שמרעננת את הדף (מעבר לכרטיס המוצר, עימוד, חזרה מהסל) מוחקת את המצב הזה.
עם Vue.js התמונה משתנה: המועדפים הופכים למצב ריאקטיבי בצד הלקוח. המשתמש לחץ על הלב — הממשק התעדכן באופן מיידי, בלי פנייה לשרת ובלי רענון. אך כאן מופיעה הבעיה השנייה, הפחות מובנת מאליה — חוסר סנכרון.
אם לשמור את הרשימה רק בזיכרון של הלשונית, היא תיעלם בעת רענון ולא תופיע בלשונית שנייה פתוחה. בדיוק בשלב הזה לרוב אובדים הנתונים, וכאן בדיוק נדרש חיבור בין מצב צד-הלקוח לאחסון בצד-השרת.
הסכמה העובדת נראית כך: Vue.js מחזיק את מצב המועדפים בסטור ריאקטיבי, ורינדור צד-שרת של Bitrix מספק את הרשימה הראשונית בעת טעינת הדף. לאחר מכן כל שינוי נשלח ל-backend ונרשם בצמוד למשתמש — מאומת או לפי מזהה אנונימי.
בביקור הבא רינדור צד-השרת שוב ממלא את הסטור בנתונים עדכניים, והמשתמש רואה את המועדפים שלו מיד, בלי הבהוב ובלי טעינה מדורגת.
בנפרד נפתר הסנכרון בין לשוניות: שינוי בלשונית אחת נקלט באחרת, ולכן הרשימה לא מתפצלת. כך המועדפים מפסיקים להיות אפקט זמני של הדף והופכים למצב יציב, ששורד רענון, מעברים ועבודה במספר חלונות.
מפרקים כיצד זה נסגר בפרויקטים אמיתיים.
מה נותן השילוב של Vue.js ו-1С-Битрикс לרשימת המועדפים
השילוב בנוי כך: Vue.js מחזיק את רשימת המועדפים במצב ריאקטיבי בצד הלקוח, ו-1С-Битрикс Битрикс24 אחראי על האחסון והסנכרון עם פרופיל המשתמש. לחיצה על ה"לב" משנה את המצב באופן מיידי — ללא רענון הדף וללא המתנה לתגובת השרת. הכתיבה יוצאת ברקע, והממשק אינו נחסם, גם אם ערוץ התקשורת נחלש.
זמן התגובה מפסיק להיות תלוי ברינדור בצד השרת: תרחיש טיפוסי של "הוספתי — ראיתי" מסתכם בשברירי שנייה במקום במחזור של "בקשה — רינדור — רינדור מחדש של הדף".
זה מורגש בקטלוגים, שבהם המשתמש מסמן עשרות פריטים ברצף: הרשימה אינה "מתנדנדת", המונה בכותרת מתעדכן מיד, והמסנן "רק מועדפים" נבנה מחדש בצד הלקוח.
אחסון מקומי סוגר את הפער בין הפעלות: כל עוד המשתמש אינו מחובר, הרשימה חיה בדפדפן, ולאחר ההתחברות היא מסונכרנת עם הפרופיל שלו ב-Битрикс. סנכרון לשוניות דרך ערוץ שידור רחב מונע התפצלות בין שני חלונות פתוחים — הוספתם מוצר באחד, ובשני המונה כבר מעודכן.
העומס על השרת יורד באופן צפוי: במקום רינדור מחדש מלא של הדף על כל פעולה יוצאת בקשה קומפקטית אחת, ופתיחות חוזרות של הקטלוג מחזירות את הרשימה מהאחסון המקומי. בעומס שיא זה מסיר חלק מהבקשות למסד הנתונים ומפחית את זמן התגובה עבור כולם, ולא רק עבור מי שמשתמש במועדפים.
בנפרד אנו סוגרים תרחישים שבהם גישה זו נשברת: ניקוי האחסון המקומי, התחברות ממכשיר אחר, התנגשות גרסאות של הרשימה. את הלוגיקה של פתרון התנגשויות ואת כללי המיזוג אנו מתארים בשלב התכנון — אחרת המשתמש מאבד את הרשימה בעת החלפת דפדפן.
דרכים לאחסון מועדפים: השוואת גישות
בחירת מאגר הנתונים קובעת מה יקרה למועדפים בעת החלפת מכשיר, ניקוי הדפדפן וצמיחת הקטלוג. סכימת שרת על אינפובלוקים של Битрикс מקשרת את הרשימה לחשבון משתמש: אורח מוסיף מוצר, מתחבר — והאוסף נטען בכל מכשיר. המחיר לכך הוא שאילתה למסד הנתונים על כל פעולה והצורך בסנכרון בעת ההתחברות.
אפשרויות צד הלקוח מהירות יותר: localStorage מחזיר נתונים באופן מיידי ושורד רענון, אך מוגבל לנפח של כמה מגה-בייט, חוסם באופן סינכרוני את התהליך הראשי ואובד בעת ניקוי המאגר. IndexedDB נטול מגבלות אלו — אסינכרוני, מכיל נפחים גדולים, שומר לא רק מזהים אלא גם תמונות מצב של כרטיסים. סכימה היברידית משלבת את שני העולמות: תגובה מיידית מהדפדפן בתוספת שחזור הרשימה מהשרת לאחר התחברות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אינפובלוקים של Битрикс | משתמשים מחוברים, סנכרון בין מכשירים | שאילתה למסד הנתונים על כל פעולה, נדרשת התקשרות לחשבון משתמש |
| localStorage | רשימות קטנות, אורחים, תרחישים פשוטים | מגבלת נפח, פעולות סינכרוניות, איפוס בעת ניקוי הדפדפן |
| IndexedDB | קטלוגים גדולים, אחסון תמונות מצב של כרטיסים, מצב לא מקוון | מורכב יותר ליישום, דורש עבודה אסינכרונית עם נתונים |
| אחסון היברידי | חנויות עם אורחים והתחברות, חשובה מהירות התגובה | נדרשת לוגיקה של מיזוג רשימות בעת התחברות ופתרון קונפליקטים |
בפועל, הבחירה לעיתים רחוקות מסתכמת באפשרות אחת. לתרחיש אורח מספיק localStorage, למחובר — אינפובלוקים, וקטלוגים גדולים עם גישה לא מקוונת דורשים IndexedDB.
סכימה היברידית מכסה את שני התרחישים בבת אחת, אך מוסיפה עבודה על מיזוג נתונים בעת ההתחברות — שלב זה מתכננים בנפרד, כדי שהמועדפים לא יוכפלו ולא יאבדו.
כיצד אנו מטמיעים מועדפים ב-Bitrix עם Vue.js: שלבי העבודה
את העבודה מתחילים בביקורת התבנית: בוחנים כיצד בנוי כעת פלט הקטלוג, היכן נשמר מצב סל הקניות והאם קיים בפרויקט מטמון של רכיבים. בשלב זה חשוב לאתר את המקומות שבהם הוספת מועדפים תשפיע על הלוגיקה הקיימת — אחרת הפונקציונליות החדשה שוברת את מה שכבר עובד.
- ביקורת התבנית הנוכחית. מפרקים את מבנה העמודים, הסקריפטים המחוברים ונקודות הפלט של כרטיסי המוצר. מתעדים אילו בלוקים נעשה בהם שימוש חוזר והיכן יידרש רכיב נפרד.
- תכנון סכמת הנתונים. קובעים היכן נשמרת רשימת המועדפים: בפרופיל המשתמש עבור משתמשים מאומתים ובאחסון המקומי של הדפדפן עבור אורחים. מתכננים תרחיש איחוד הרשימות בעת הכניסה לחשבון, כדי שדבר לא יאבד.
- הגדרת חילופי API. מכינים מתודות צד-שרת לקריאה, הוספה ומחיקה של פריטים. את החילוף בונים כך שהממשק לא ימתין לטעינה מלאה מחדש של העמוד ויקבל רק את הנתונים שהשתנו.
- הטמעת הרכיב. מחברים את חלק הפרונטאנד לסימון של הקטלוג וכרטיס המוצר, ומקשרים אותו למתודות צד-השרת. מונה המועדפים ומצב הכפתורים מתעדכנים מיד, ללא רענון העמוד.
- בדיקות. בודקים את ההתנהגות עבור אורח ומשתמש מאומת, את תרחיש הכניסה לחשבון, את העבודה במובייל ובחיבור איטי. בנפרד בוחנים מה קורה בעת ניקוי אחסון הדפדפן.
- מסירה ותיעוד. מוסרים תיאור של סכמת הנתונים, רשימת מתודות צד-השרת והוראות תחזוקה, כדי שצוות הלקוח יוכל לפתח את הפונקציונליות הלאה.
סדר עבודה כזה מאפשר לא לכתוב מחדש את הקטלוג כולו: השינויים נוגעים רק בבלוקים הנדרשים, ושאר העמודים ממשיכים לעבוד כבעבר. בסיום כל שלב מציגים את התוצאה בסביבת בדיקות — הלקוח רואה את ההתקדמות עוד לפני המסירה הסופית.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר הטמעת המועדפים על Vue.js מעל 1С-Битрикс, הלקוח מקבל לא "בלוק עובד באתר", אלא ערכה שלפיה ניתן לפתח את המערכת ולהעביר אותה לצוות אחר ללא הנדסה הפוכה.
- תצורת הרכיב — פרמטרי השליפה, הקישור לאינפובלוקים, הגדרות המטמון ומצב מסירת הנתונים, כדי שהמועדפים לא ימשכו בקשות מיותרות למסד הנתונים.
- סכמת התקשורת — מפת המסלולים בין הממשק לשרת: אילו נתונים נשלחים ללקוח, מה נשמר מקומית, ובאיזה רגע מסתנכרן עם חשבון המשתמש.
- מדיניות הגישה לנתונים — הכללים שלפיהם הרשימה גלויה רק לבעליה, ההתנהגות לאורח ולמשתמש מאומת, וההבחנה לפי תפקידים וקבוצות משתמשים.
- תיעוד — תיאור מבנה הרכיב, נקודות ההרחבה והתלויות, כדי שניתן יהיה לבצע הרחבות ללא מחבר המימוש המקורי.
- נוהל תמיכה — סדר עדכון התלויות, בדיקת התאימות לגרסאות חדשות של הליבה וכללי החזרה לאחור בעת רגרסיה.
- הוראות למנהל התוכן — כיצד לנהל את ההרכב והתצוגה של המועדפים ללא עריכת קוד.
- רשימת בדיקה לקבלה — התרחישים שלפיהם נבדקת תקינות העבודה: הוספה, מחיקה, סנכרון בין מכשירים, והתנהגות בעת אובדן סשן.
כל ארטיפקט מכסה סוג סיכון משלו: תצורה וסכמת תקשורת מסירות שאלות של ביצועים, מדיניות גישה — דליפת רשימות של אחרים, תיעוד ונוהל — תלות במבצע אחד. תארו את המשימה — נחזור עם הערכה ותוכנית לפרויקט שלכם.
מקרה בוחן: האצת העבודה של המועדפים פי 4 בפורטל בעומס גבוה
הפורטל של הלקוח הוא קטלוג עם מבחרים אישיים: המשתמש הוסיף מוצרים למועדפים, אך הרשימה התקיימה רק בכרטיסייה הנוכחית.
לאחר רענון או כניסה מחדש היא אופסה, וכל לחיצה על "הלב" נשלחה כבקשה סינכרונית לשרת — בשעות שיא של תנועה הדבר יצר תורים, השהיות מורגשות בתגובה ומפולת של פניות חוזרות למסד הנתונים.
מפרקים מה בדיוק נשבר וכיצד זה נסגר בצד הפרונטאנד והבקאנד.
מה היה לפני השינויים
המועדפים נשמרו בזיכרון הכרטיסייה ללא קישור לפרופיל. כל רענון עמוד מחק את המבחר, וחלק השרת קיבל בקשה נפרדת לכל פעולה — ללא איחוד וללא מטמון. בפורטל בעומס גבוה הדבר התבטא בגידול בפניות לשרת, בירידה בביצועים בשעות שיא ובתלונות משתמשים על מוצרים "נעלמים".
מה שינו
רשימת המועדפים הועברה למצב בצד הלקוח עם שמירה בין סשנים: המבחר מקושר למשתמש ומשוחזר בכניסה הבאה, כולל תרחיש אורח עם סנכרון לאחר אימות. פעולות המשתמש נצברות ונשלחות בחבילה, ולא אחת-אחת — חלק השרת מקבל עדכון מרוכז אחד במקום זרם של בקשות קטנות. לפניות חוזרות הוספה שכבת מטמון בצד השירות, כדי ששליפות זהות לא יחושבו מחדש.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| תגובת הממשק בעת הוספה | השהיה מורגשת | מיידי, ללא רענון |
| שמירת הרשימה בין סשנים | לא | כן, עם קישור לפרופיל |
| פניות לשרת על פעולות עם המועדפים | רמה בסיסית | ירידה של 60% |
| התנהגות בשעות שיא | תורים של בקשות | עבודה יציבה |
את הפרויקט הוביל המהנדס שלנו, שעבד עם הצירוף 1С-Битрикс ו-Vue.js. לאחר ההטמעה צוות הלקוח תיעד ירידה של 60% בפניות לשרת והסיר את איפוס הרשימה — התמיכה הפסיקה לקבל תלונות על מועדפים "נעלמים".
במה שונה שמירת המועדפים בצד הלקוח לעומת בצד השרת?
אחסון בצד הלקוח הוא נתונים בדפדפן של המשתמש: localStorage, sessionStorage או IndexedDB. המועדפים נקראים ונכתבים באופן מיידי, ללא פנייה לשרת, ולכן הממשק מגיב ללחיצה מיד, והעומס על הבקאנד נשאר אפסי.
Vue.js נוח כאן בזכות הריאקטיביות: store ב-Pinia או Vuex מחזיק את הרשימה בזיכרון, ותוסף מסנכרן אותה עם אחסון הדפדפן. גם המגבלות הוגנות — הנתונים קשורים למכשיר ולדפדפן מסוימים, ניקוי המטמון או מצב גלישה בסתר מוחקים אותם, ובמכשיר אחר המשתמש יראה רשימה ריקה.
אחסון בצד השרת מעביר את הרשימה למסד נתונים ומקשר אותה לחשבון משתמש. זה מאפשר סנכרון בין מכשירים: הוספת מוצר מהטלפון — ואתה רואה אותו במחשב בעבודה לאחר ההתחברות. מהימנות הנתונים גבוהה יותר: הרשומה שורדת ניקוי דפדפן, החלפת מכשיר והתקנה מחדש של המערכת. המחיר לכך הוא בקשת רשת על כל פעולה, השהיה בתגובה, והצורך להחליט מה לעשות עם אורח ללא אימות.
הפשרה בפועל נראית כך. עבור אורח הרשימה חיה בדפדפן — מהר וללא רשומות מיותרות במסד הנתונים. בעת התחברות או הרשמה הרשימה המקומית מתמזגת עם זו שבשרת: מאחדים לפי מזהה המוצר, פותרים קונפליקטים לפי זמן השינוי, ומסירים כפילויות.
מכאן והלאה השרת הופך למקור האמת, ואחסון בצד הלקוח פועל כמטמון לתצוגה מיידית. גישה כזו מסירה את הסיכון העיקרי — אובדן הרשימה בעת החלפת מכשיר — ושומרת על מהירות הממשק.
בנפרד כדאי לתכנן את ההתנהגות כאשר השרת אינו זמין: עדכון אופטימי של הממשק עם תור של בקשות נדחות ושליחה חוזרת עם חידוש הקשר. אחרת המשתמש או מאבד את הפעולה, או רואה אי-סנכרון בין מה שעל המסך לבין מה שבמסד הנתונים.
הבחירה בין הלקוח לשרת אינה «או», אלא שאלה של היכן עובר הגבול בין מהירות התגובה לבין הבטחת שלמות הנתונים.
ספקות טכניים נפוצים בעת שילוב Vue.js ב-Bitrix
Vue.js בפרויקט על Bitrix כמעט תמיד חי לצד פרונטאנד קיים: תוספי jQuery, ווידג'טים של צד שלישי, מונים, קוד עצמאי ישן בתבנית. קונפליקטים כאן אינם נדירים, אך הם צפויים ונפתרים בשלב התכנון, ולא לאחר ההשקה. להלן מה שמועלה לרוב בדיונים טכניים.
האם Vue.js ישבור סקריפטים קיימים בדף?
לא, אם מגדירים בבירור את תחומי האחריות. Vue מותקן בקונטיינר מסוים ומנהל רק את חלקו בתבנית, מבלי להתערב ב-DOM שמחוצה לו. ספריות גלובליות ממשיכות לעבוד כבעבר.
קונפליקט אפשרי במקרה אחד — כאשר תוסף של צד שלישי ו-Vue עורכים בו-זמנית את אותו צומת; מקומות כאלה אנו מזהים בשלב ניתוח התבנית ומפרידים לקונטיינרים שונים.
כיצד תוכן דינמי מסתדר עם מטמון של Bitrix?
מטמון קומפוננטות מחזיר תבנית מוכנה, והנתונים עבור Vue נטענים בבקשה נפרדת לאחר רינדור הדף. המטמון ממשיך לעבוד, והאינוולידציה אינה נשברת. עבור מועדפים וסל קניות זה עקרוני: החלק בצד השרת נשמר במטמון, והחלק בצד הלקוח מתעדכן ללא רענון.
האם בלוקים דינמיים מאונדקסים על ידי מנועי חיפוש?
כן, ברינדור נכון. הרינדור הראשון מוחזר מהשרת, ולכן הסורק רואה את התוכן מיד, ולא קונטיינר ריק. אם הבלוק נטען רק בצד הלקוח, עבורו מוגדר רינדור בצד השרת או הגשה מוקדמת. אנו בודקים את התוצאה באמצעות כלי סריקה — לא לפי העין.
מה עם דפדפנים ישנים ודיבוג?
הבנייה עוברת טרנספילציה עבור רשימת דפדפנים מוסכמת, ולכן התחביר אינו נשבר במנועים ישנים. לצורך דיבוג אנו מחברים מפות מקור: שגיאה בקובץ הבנוי נקראת כקוד קומפוננטה רגיל. זה חוסך שעות בניתוח תקלות בפרודקשן.
נדון במשימה שלך בנושא המועדפים ב-Bitrix
כדי לחזור עם הערכה ולא עם מילים כלליות, אנחנו צריכים להבין את המימוש הנוכחי שלך: היכן נשמרת רשימת המועדפים — ב-localStorage, ב-cookie, במאפיין משתמש או בטבלה נפרדת; כיצד היא מגיעה לתבנית — דרך קומפוננטה, תבנית או מטפל AJAX; ומה כבר נעשה ב-Vue.js, אם הפרונטאנד הועבר חלקית. מכך תלוי אם אנחנו כותבים מחדש את המנגנון הקיים או משתלבים בו בלי לשבור תרחישים אחרים.
מבחינת הדרישות חשוב לתעד: אימות והאורחים, סנכרון בין מכשירים, מגבלה על מספר הפריטים, התנהגות בעת מחיקת מוצר מהקטלוג, מטמון וכיצד המועדפים קשורים לסל ולהשוואה.
הפרטים האלה קובעים את הארכיטקטורה — אם אנחנו מוסרים את המצב דרך API או בונים אותו בצד הלקוח, והיכן בדיוק עובר הגבול בין Bitrix ל-Vue.
תאר את המשימה בצורה חופשית — מה יש כיום, מה לא מספק, אילו תרחישים צריכים לעבוד. נחזור עם הערכת העבודות ותוכנית יישום: שלבים, לוחות זמנים ומה יידרש מצדך.
- ניתוח המימוש הנוכחי של המועדפים ונקודות האינטגרציה עם Vue.js
- דרישות להתנהגות עבור אורחים ומשתמשים מאומתים
- סכימת אחסון וסנכרון של הרשימה בין מכשירים
- תוכנית יישום עם שלבים וסדר העלייה לאוויר
- הערכת עבודות לפי כל שלב
- רשימת סיכונים: מטמון, התנגשויות עם הסל, מיגרציית נתונים
- מה נדרש מהצוות שלך: הרשאות גישה, סביבת בדיקות, אנשי קשר אחראיים
נדון במשימה — שלח תיאור של המימוש הנוכחי והדרישות, ונחזור עם הערכה ותוכנית עבודה.