Чому обране на Битрикс і Vue.js втрачається при перезавантаженні
Найчастіша причина втрати списку обраного на Битрикс і Vue.js — зберігання в localStorage без прив'язки до користувача. Компонент Vue.js записує масив ідентифікаторів товарів у браузерне сховище, все працює, поки відвідувач не відкриє сайт з іншого пристрою або не очистить кеш.
При перезавантаженні з очищенням сховища список обнуляється, а на другому пристрої його просто немає — синхронізація обраного між браузером і обліковим записом не виконується.
Другий сценарій — зберігання в сесії на стороні сервера. Поки сесія жива, обране віддається в шаблон, але варто сесії спливти або користувачу увійти з іншого браузера, як дані зникають.
Якщо при цьому Vue.js-компонент підвантажує список асинхронно, а серверний рендер віддає порожній контейнер, виникає розсинхрон: інтерфейс показує одне, база — інше. Користувач додає товар повторно, в базі з'являється дубль, а частина позицій втрачається при злитті списків.
Третє джерело втрат — гонка запитів. Клік по «сердечку» надсилає запит на додавання, але якщо користувач швидко перемикає сторінки або товари, відповіді приходять не в тому порядку, і останній запит перезаписує список більш раннім станом. Без серверного підтвердження і версіонування списку частина додавань відкочується мовчки.
Корінь проблеми один: обране живе у двох незв'язаних місцях — браузері та обліковому записі. Поки немає єдиного джерела правди і синхронізації обраного між ними, список буде втрачатися при кожній зміні пристрою, очищенні кешу або спливанні сесії. Розбираємо, як це закривається на зв'язці Битрикс і Vue.js.
Що дає зв'язка Vue.js і 1С-Битрикс для списку обраного
Список обраного — типовий приклад місця, де класичний серверний рендеринг починає заважати. Користувач натискає «сердечко», і замість миттєвої реакції браузер надсилає запит, чекає відповіді та перемальовує всю сторінку цілком.
При десятку товарів це непомітно, при каталозі на сотні позицій кожне таке перемальовування — зайвий трафік, повторна відрисовка шаблону та втрата позиції скролу.
Зв'язка Vue.js і 1С-Битрикс знімає це обмеження: інтерфейсна частина бере на себе реактивне оновлення, а платформа залишається джерелом даних і логіки.
Натискання на іконку змінює стан компонента одразу, запит до сервера йде у фоні та оновлює лише потрібний фрагмент — без перезавантаження сторінки. Користувач бачить результат миттєво, а сервер обробляє точковий запит замість складання сторінки заново.
Що це дає за навантаженням і досвідом
Єдиний список обраного зберігається на стороні платформи та підтягується при вході з будь-якого пристрою — додане з телефона видно в браузері на комп'ютері.
Стан синхронізується через користувацьку сесію, тому не доводиться тримати окреме сховище в браузері та миритися з розбіжностями між вкладками.
Зниження навантаження на сервер виходить завдяки відмові від повного перемальовування: замість генерації всієї сторінки віддається компактна відповідь за конкретною операцією. На каталогах з активною аудиторією це помітно розвантажує обробку запитів і прискорює відгук інтерфейсу.
Чому це не ламає наявний сайт
Компоненти обраного підключаються до поточного шаблону та не потребують переписування каталогу чи кошика. Ми виносимо в реактивний шар лише ті блоки, де важлива миттєва реакція, а решта сторінок продовжують працювати як раніше.
Такий підхід дає єдиний список обраного без перезавантаження сторінки та без ризику для вже працюючих сценаріїв.
Способи зберігання обраного: порівняння підходів
Вибір місця зберігання визначає, що побачить гість після закриття вкладки і як поводитиметься каталог за високого навантаження. Нижче — чотири робочі схеми, між якими реально обирають на проєктах з 1С-Бітрікс і Vue.js.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Сесія | Разові добірки, порівняння товарів у межах однієї сесії | Список втрачається при закритті браузера, не переживає очищення cookies, не працює для неавторизованих між пристроями |
| localStorage | Швидкий відгук інтерфейсу, гість без реєстрації | Прив'язаний до конкретного браузера й пристрою, чиститься разом з даними сайту, не видно серверу і не потрапляє в аналітику |
| Серверне сховище в інфоблоках | Обране має жити між пристроями й сесіями | Потребує авторизації, кожен клік — запит до сервера, за частих звернень потрібен кеш і продумана схема властивостей |
| Гібридна схема | Каталог з гостьовим сценарієм і подальшою авторизацією | Складніша в підтримці: потрібна синхронізація локального списку з серверним при вході та злиття дублів |
Сесія хороша там, де список живе хвилини: порівняти три позиції й піти. Щойно гість повертається наступного дня, схема розсипається — даних уже немає.
localStorage дає миттєве відображення без звернення до сервера, тому інтерфейс не чекає відповіді. Плата — прив'язка до браузера: з телефона список не видно, а очищення даних сайту стирає його безслідно.
Серверне зберігання в інфоблоках прив'язує обране до користувача, а не до пристрою. Ціна — авторизація й запит на кожну дію, тому список кешують, а запис ведуть пакетами.
Гібридна схема закриває обидва сценарії: гість збирає список локально, при вході він зливається з серверним. Такий підхід найчастіше й обирають для каталогів з особистим кабінетом.
Як ми впроваджуємо обране на Vue.js у Бітрікс: етапи робіт
Процес розбитий на етапи так, щоб кожен наступний спирався на перевірений результат попереднього, а не на припущення. Нижче — як це виглядає на проєктах, де обране вже частково працює або потребує перенесення на Vue.js.
Аудит і проєктування
- Аудит поточної реалізації. Дивимося, де зараз зберігається список: у сесії, у cookie, у користувацьких властивостях або в окремій таблиці. Перевіряємо, що відбувається при очищенні cookie, зміні пристрою та вході під тим самим акаунтом з іншого браузера — саме тут найчастіше губляться позиції.
- Проєктування схеми зберігання. Визначаємо, що живе на клієнті, а що на сервері: гість отримує локальне сховище, авторизований — запис, прив'язаний до користувача. Фіксуємо формат обміну та момент злиття двох списків при вході.
- Налаштування обміну з 1С. Узгоджуємо, які ідентифікатори товарів і розділів надходять з каталогу, щоб обране не «розсипалося» після оновлення номенклатури. Перевіряємо поведінку при знятті товару з публікації.
Перевірка і передача
- Реалізація інтерфейсу на Vue.js. Компонент обраного оновлюється без перезавантаження сторінки: додавання, видалення та лічильник змінюються миттєво, а запит до сервера йде фоново. Окремо закриваємо сценарій з кількома відкритими вкладками.
- Перевірка сценаріїв. Проганяємо гостя, авторизованого користувача, вхід у середині сесії, очищення сховища та повторний візит. Дивимося не лише на список, а й на лічильник у шапці та на сторінку порівняння, якщо вона є.
- Здача та документація. Передаємо опис схеми зберігання, точок інтеграції та того, які дані вважаються джерелом істини. Команда замовника далі сама додає нові типи сутностей в обране.
Такий порядок знімає головний ризик — коли обране працює в демо, але губиться в реального покупця після зміни пристрою.
Що замовник отримує на руки після доопрацювання
Після доопрацювання обраного на Vue.js і 1С-Бітрікс замовник отримує не лише робочий функціонал, а й повний комплект артефактів, за якими проєкт можна передати будь-якій команді підтримки або розвивати власними силами. Нижче — що саме фіксується в документації та передається разом із кодом.
- Конфігурація компонентів. Опис усіх задіяних компонентів Бітрікс, їхніх параметрів, прив'язок до інфоблоків і шаблонів, а також налаштувань Vue-застосунку — з поясненням, який параметр за що відповідає і що станеться при його зміні.
- Схема обміну даними. Діаграма взаємодії фронтенду і бекенду: які запити йдуть на сервер, у якому форматі надходить відповідь, як синхронізується стан обраного між вкладками і сесіями, де зберігаються дані користувача.
- Політики доступу. Розмежування прав на читання і запис обраного, правила роботи для авторизованих і гостьових користувачів, поведінка при зміні статусу, обробка конфліктів при паралельних діях.
- Документація. Технічний опис архітектури, інструкція з розгортання і налаштування, перелік залежностей і вимог до оточення, коментарі в коді на ключових ділянках логіки.
- Регламент підтримки. Порядок оновлення залежностей і ядра Бітрікс, правила регресійного тестування при змінах, точки контролю продуктивності, контакти і терміни реакції за інцидентами.
- Набір тестових сценаріїв. Перевірки додавання, видалення і синхронізації обраного, поведінка при втраті з'єднання, коректність відображення для різних ролей — щоб зміни в майбутньому не ламали вже працюючий функціонал.
Такий комплект знімає залежність від конкретного виконавця: новий інженер входить у проєкт за документацією, а не за усними поясненнями. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Кейс: як обране перестало губитися при перезавантаженні
Клієнт — роздрібний магазин на 1С-Бітрікс з каталогом на кілька тисяч позицій. Обране зберігалося в cookie браузера: список жив до першого очищення, при вході з телефона виявлявся порожнім, а після оновлення сторінки товари періодично зникали.
Покупці сприймали це як збій і писали в підтримку — звернення щодо «зникнення списку» йшли потоком, а частина кошиків просто не доживала до оформлення замовлення.
Що змінили
Список обраного перенесли на сервер і прив'язали до профілю користувача, а інтерфейс переписали на Vue.js: додавання й видалення товару відбувається без перезавантаження сторінки, стан одразу підтягується з відповіді сервера.
Для гостей список складається в тимчасове сховище і переноситься в профіль при вході або реєстрації — перехід «гість → покупець» більше не обнуляє добірку.
Синхронізація між пристроями запрацювала автоматично: той самий список відкривається і на телефоні, і на комп'ютері. Окремо закрили конфліктні сценарії — повторне додавання товару, видалення на одному пристрої при відкритій вкладці на іншому, застаріла відповідь сервера.
Що стало
Час відгуку інтерфейсу на додавання в обране скоротився з перезавантаження сторінки до миттєвої реакції — покупець бачить результат одразу, без очікування. Звернення в підтримку щодо зникнення списку припинилися: скаржитися стало нема на що.
Частка кошиків, зібраних з обраного, зросла — добірка перестала губитися на півдорозі до замовлення.
Окремий ефект — передбачуваність для бізнесу: список обраного став повноцінними даними в профілі, за ними видно, що покупець відкладає і до чого повертається. Це вже не косметика інтерфейсу, а робочий сигнал попиту.
Чим відрізняється зберігання обраного в сесії від localStorage?
Сесія та localStorage вирішують одне завдання — зберегти список обраного між переходами по сторінках, — але по-різному відповідають на питання «як довго живуть дані та до кого вони прив'язані».
Сесія зберігається на стороні сервера і прив'язана до ідентифікатора відвідувача: поки браузер тримає сесійну cookie, сервер знає, що цей набір товарів належить саме цьому візиту. Закрив вкладку або минув термін сесії — список зник.
localStorage живе в браузері, не скидається при закритті й не залежить від серверної сесії, тому переживає і перезапуск браузера, і повернення на сайт через кілька днів.
Прив'язка до пристрою — друга принципова відмінність. Сесія та localStorage однаково локальні: і те, і інше прив'язане до конкретного браузера на конкретному пристрої. Якщо відвідувач додав товар з телефона, а відкрив сайт з ноутбука — списку там не буде.
Синхронізація між пристроями можлива лише при серверному зберіганні, прив'язаному до облікового запису: тоді обране слідує за користувачем, а не за браузером.
Для серверної частини різниця теж відчутна. Сесія навантажує сервер: кожен запит списку — це звернення до сховища сесій, а при великій кількості відвідувачів зростає обсяг даних, які потрібно тримати в пам'яті.
localStorage знімає це навантаження повністю: список читається й пишеться в браузері, сервер про нього не знає, поки користувач сам не відправить його, наприклад при оформленні замовлення або перенесенні в кошик.
На практиці підходи комбінують. Гостю віддають localStorage — швидко, без навантаження на сервер, список зберігається між візитами. Після входу в обліковий запис обране переноситься на серверну сторону й прив'язується до користувача — тоді воно доступне з будь-якого пристрою.
Vue.js бере на себе реактивне оновлення інтерфейсу: лічильник та іконки змінюються без перезавантаження сторінки, а шар зберігання залишається тим, який обрано під сценарій.
Часті технічні сумніви при доопрацюванні обраного
Обране на Vue.js у зв'язці з 1С-Бітрікс найчастіше викликає три технічні сумніви: чи не зламає це наявний шаблон, що робити з уже накопиченими списками і чи витримає сервер зростаючу кількість звернень. Розбираємо кожне предметно — без загальних слів.
Чи сумісне це з поточним шаблоном і компонентами?
Vue-шар підключається точково: компонент обраного монтується в окремий DOM-вузол, не зачіпаючи серверний рендеринг інших блоків. Шаблон, компоненти каталогу і кошик продовжують працювати як раніше — змінюється лише поведінка кнопки та лічильника.
Якщо в проєкті вже є свій JS, конфліктів не буде: збірка ізолює залежності, а обмін іде через штатні методи Бітрікс.
Що станеться з уже накопиченими списками обраного?
Міграція даних виконується до ввімкнення нового інтерфейсу. Наявні записи переносяться в цільову структуру зберігання зі збереженням прив'язки до користувача і товарів, старі ключі залишаються як резерв на період відкату.
Після звірки контрольних сум списків старий механізм вимикається — користувач бачить ті самі товари, що й раніше, просто без перезавантаження сторінки.
Чи витримає сервер зростаюче навантаження?
Саме по собі обране не створює важких запитів: додавання і видалення — це легкі операції запису, а читання віддається з кешу і не перераховує каталог.
Основне навантаження припадає на момент монтування компонента, тому список підвантажується окремим запитом, а не разом зі сторінкою. При зростанні трафіку додається серверне кешування і обмеження частоти звернень — пікові значення залишаються в межах штатного режиму.
Чи можна відкотитися, якщо щось піде не так?
Так. Новий інтерфейс вмикається окремо від старого, тому відкат — це перемикання прапорця, а не розгортання заново. Дані за період роботи зберігаються в обох структурах, тож після повернення до попередньої версії списки залишаються актуальними. Такий порядок дозволяє обкатати обране на частині користувачів і зняти сумніви до повного запуску.
Обговоримо ваше завдання щодо обраного на Битрикс і Vue.js
Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, нам потрібно зрозуміти вашу поточну реалізацію: як зараз влаштовано обране, де зберігається стан, як сторінки отримують дані про товари. Опишіть це у вільній формі — далі ми поставимо уточнювальні запитання та запропонуємо рішення.
Корисно додати до опису те, що вже є під рукою:
- як зараз працює обране — перезавантаження сторінки, окремий розділ в особистому кабінеті або локальне сховище браузера;
- де лежать дані — інфоблок, торгові пропозиції, зовнішній сервіс, і чи є прив'язка до авторизованого користувача;
- як влаштований фронтенд — Vue.js підключено точково на окремих блоках чи вже збирається окремим застосунком;
- які шаблони та компоненти задіяні — картка товару, каталог, кошик, шапка сайту;
- як зараз влаштовані обміни з 1С — що і з якою періодичністю надходить на сайт;
- які обмеження важливі — навантаження, кешування, вимоги до швидкості відгуку інтерфейсу;
- чи є тестовий контур, де можна перевірити зміни до викочування на робочий сайт.
За цим описом ми оцінимо обсяг: чи потрібно переписати зберігання стану, додати шар обміну між Vue.js і серверною частиною, переробити шаблони чи достатньо точкових правок.
Окремо перевіримо, як рішення поводитиметься при очищенні кешу, зміні браузера та в неавторизованого відвідувача, — це типові місця, де обране «губиться».
У відповідь ви отримаєте оцінку робіт, план за етапами з порядком викочування та список того, що потрібно з вашого боку: доступи, тестовий контур, контакт розробника, який вів проєкт.
Якщо за описом видно, що завдання можна закрити малою кров'ю, ми так і скажемо — без нав'язування переписування всього фронтенду.
Опишіть поточну реалізацію обраного — повернемося з оцінкою та планом робіт.
