Vue.js + 1C-Bitrix: favorites without page reload

Why favorites on Bitrix and Vue.js get lost on reload

The most common reason for losing the favorites list on Bitrix and Vue.js is storing it in localStorage without tying it to the user.

The Vue.js component writes an array of product IDs to browser storage, and everything works until the visitor opens the site from another device or clears the cache.

On reload with storage cleared, the list resets to empty, and on the second device it simply isn't there — synchronization of favorites between the browser and the account is not performed.

The second scenario is storing it in a server-side session. While the session is alive, the favorites are passed to the template, but as soon as the session expires or the user logs in from another browser, the data disappears.

If, at the same time, the Vue.js component loads the list asynchronously while the server render outputs an empty container, a desync occurs: the interface shows one thing, the database shows another.

The user adds a product again, a duplicate appears in the database, and some items are lost when the lists are merged.

The third source of loss is a request race. A click on the "heart" sends an add request, but if the user quickly switches pages or products, the responses arrive out of order, and the last request overwrites the list with an earlier state. Without server-side confirmation and list versioning, some additions are silently rolled back.

The root of the problem is one thing: favorites live in two unconnected places — the browser and the account.

As long as there is no single source of truth and no synchronization of favorites between them, the list will be lost on every device change, cache clear, or session expiry. Let's break down how this is solved with the Bitrix and Vue.js stack.

What the Vue.js and 1C-Bitrix combination provides for a favorites list

A favorites list is a typical example of a place where classic server-side rendering starts to get in the way. The user clicks a "heart," and instead of an instant reaction, the browser sends a request, waits for a response, and re-renders the entire page.

With a dozen products this goes unnoticed; with a catalog of hundreds of items, each such re-render means extra traffic, re-rendering of the template, and loss of scroll position.

The combination of Vue.js and 1C-Bitrix removes this limitation: the front-end takes on reactive updating, while the platform remains the source of data and logic.

Clicking an icon changes the component state immediately, the request to the server goes out in the background and updates only the needed fragment — without reloading the page.

The user sees the result instantly, and the server processes a targeted request instead of assembling the page anew.

What this provides in terms of load and experience

A single favorites list is stored on the platform side and is pulled in when logging in from any device — something added from a phone is visible in the browser on a computer.

The state is synchronized through the user session, so there is no need to maintain a separate store in the browser and put up with discrepancies between tabs.

The reduction in server load comes from abandoning full re-rendering: instead of generating the entire page, a compact response for a specific operation is returned. On catalogs with an active audience, this noticeably offloads request processing and speeds up interface response.

Why this does not break the existing site

Favorites components connect to the current template and do not require rewriting the catalog or the cart. We move into the reactive layer only those blocks where instant reaction matters, while the rest of the pages continue to work as before.

This approach provides a single favorites list without page reloading and without risk to already working scenarios.

Ways to store favorites: comparing approaches

The choice of storage location determines what a guest sees after closing the tab and how the catalog behaves under high load. Below are four working schemes that are actually chosen between on projects with 1C-Bitrix and Vue.js.

A session is good where the list lives for minutes: compare three items and leave. As soon as the guest returns the next day, the scheme falls apart — the data is already gone.

localStorage provides instant rendering without a request to the server, so the interface does not wait for a response. The price is being tied to the browser: the list is not visible from a phone, and clearing site data wipes it without a trace.

Server-side storage in information blocks ties favorites to the user rather than to the device. The price is authorization and a request for every action, so the list is cached and writes are done in batches.

The hybrid scheme covers both scenarios: the guest builds the list locally, and upon login it merges with the server-side one. This approach is most often chosen for catalogs with a personal account.

How we implement favorites on Vue.js in Bitrix: stages of work

The process is broken down into stages so that each subsequent one builds on a verified result of the previous one, rather than on assumptions. Below is how this looks on projects where favorites are already partially working or need to be migrated to Vue.js.

Audit and design

1. Audit of the current implementation. We look at where the list is currently stored: in the session, in cookies, in user properties, or in a separate table. We check what happens when cookies are cleared, when the device is changed, and when logging in under the same account from another browser — this is exactly where items are most often lost.
2. Designing the storage schema. We determine what lives on the client and what lives on the server: a guest gets local storage, while an authorized user gets a record tied to the user. We fix the exchange format and the moment when the two lists are merged upon login.
3. Setting up exchange with 1C. We agree on which product and section identifiers come from the catalog so that favorites don't "fall apart" after the nomenclature is updated. We check the behavior when a product is unpublished.

Verification and handover

• Implementing the interface on Vue.js. The favorites component updates without reloading the page: adding, removing, and the counter change instantly, while the request to the server is sent in the background. We separately cover the scenario with multiple open tabs.
• Testing scenarios. We run through a guest, an authorized user, logging in mid-session, clearing storage, and a repeat visit. We look not only at the list, but also at the counter in the header and at the comparison page, if there is one.
• Handover and documentation. We hand over a description of the storage schema, the integration points, and which data is considered the source of truth. The customer's team then adds new entity types to favorites on its own.

This order removes the main risk — when favorites work in a demo but are lost for a real buyer after changing devices.

What the client receives after the enhancement

After enhancing the favorites feature on Vue.js and 1C-Bitrix, the client receives not only working functionality but also a complete set of artifacts that allow the project to be handed over to any support team or developed in-house. Below is exactly what is captured in the documentation and delivered together with the code.

• Component configuration. A description of all Bitrix components involved, their parameters, bindings to information blocks and templates, as well as the settings of the Vue application — explaining what each parameter is responsible for and what will happen if it is changed.
• Data exchange schema. A diagram of frontend-backend interaction: which requests are sent to the server, in what format the response arrives, how the favorites state is synchronized between tabs and sessions, and where user data is stored.
• Access policies. Separation of read and write permissions for favorites, operating rules for authorized and guest users, behavior when status changes, and conflict handling during concurrent actions.
• Documentation. A technical description of the architecture, deployment and configuration instructions, a list of dependencies and environment requirements, and code comments at key logic points.
• Support regulations. Procedures for updating dependencies and the Bitrix core, regression testing rules for changes, performance control points, and contacts and response times for incidents.
• Set of test scenarios. Checks for adding, removing, and synchronizing favorites, behavior when the connection is lost, and correct display for different roles — so that future changes do not break already working functionality.

Such a set removes dependence on a specific contractor: a new engineer enters the project through documentation rather than verbal explanations. Describe your task — we will get back to you with an estimate and a work plan.

Case study: how favorites stopped getting lost on reload

The client is a retail store on 1C-Bitrix with a catalog of several thousand items. Favorites were stored in the browser cookie: the list survived until the first cleanup, appeared empty when logging in from a phone, and after a page refresh the items periodically disappeared.

Customers perceived this as a malfunction and wrote to support — requests about the "disappearing list" came in a stream, and some carts simply did not make it to checkout.

What was changed

The favorites list was moved to the server and tied to the user profile, and the interface was rewritten in Vue.js: adding and removing an item happens without a page reload, and the state is immediately pulled from the server response.

For guests, the list is stored in temporary storage and transferred to the profile upon login or registration — the "guest → customer" transition no longer resets the selection.

Synchronization between devices started working automatically: the same list opens on both the phone and the computer. Conflict scenarios were addressed separately — re-adding an item, deletion on one device while a tab is open on another, and a stale server response.

What was achieved

The interface response time for adding to favorites was reduced from a page reload to an instant reaction — the customer sees the result immediately, without waiting. Support requests about the disappearing list stopped: there was nothing left to complain about.

The share of carts assembled from favorites grew — the selection stopped getting lost halfway to the order.

A separate effect is predictability for the business: the favorites list became full-fledged data in the profile, showing what the customer sets aside and what they return to. This is no longer interface cosmetics, but a working demand signal.

How does storing favorites in a session differ from localStorage?

A session and localStorage solve the same problem — preserving a favorites list across page navigations — but they answer the question "how long does the data live and who is it tied to" differently.

A session is stored server-side and tied to a visitor identifier: as long as the browser holds the session cookie, the server knows that this set of products belongs to this particular visit. Close the tab or let the session expire — the list is gone.

localStorage lives in the browser, is not reset when the browser is closed, and does not depend on the server session, so it survives both a browser restart and a return to the site several days later.

Tying to a device is the second fundamental difference. A session and localStorage are equally local: both are tied to a specific browser on a specific device. If a visitor added a product from a phone but opened the site from a laptop — the list won't be there.

Cross-device synchronization is only possible with server-side storage tied to an account: then favorites follow the user rather than the browser.

For the server side, the difference is also noticeable. A session puts load on the server: every request for the list is a call to the session store, and with a large number of visitors the volume of data that must be kept in memory grows.

localStorage removes this load entirely: the list is read and written in the browser, and the server knows nothing about it until the user sends it themselves, for example when placing an order or moving items to the cart.

In practice, the approaches are combined. A guest is given localStorage — fast, with no load on the server, and the list is preserved between visits.

After signing in to an account, favorites are transferred to the server side and tied to the user — then they are available from any device.

Vue.js handles reactive UI updates: the counter and icons change without a page reload, while the storage layer remains whichever one is chosen for the scenario.

Common technical concerns when enhancing favorites

Favorites on Vue.js in conjunction with 1C-Bitrix most often raise three technical concerns: whether it will break the existing template, what to do with already accumulated lists, and whether the server will handle the increased number of requests. We break down each one concretely — without generalities.

What will happen to already accumulated favorites lists?

Data migration is performed before enabling the new interface. Existing records are transferred to the target storage structure while preserving the link to the user and products; the old keys remain as a backup for the rollback period.

After verifying the checksums of the lists, the old mechanism is disabled — the user sees the same products as before, just without page reloading.

Will the server handle the increased load?

Favorites by itself does not create heavy queries: adding and removing are lightweight write operations, while reading is served from the cache and does not recalculate the catalog.

The main load falls on the moment the component is mounted, so the list is loaded with a separate request rather than together with the page. As traffic grows, server-side caching and request rate limiting are added — peak values remain within the standard mode.

Is it possible to roll back if something goes wrong?

Yes. The new interface is enabled separately from the old one, so a rollback is a flag switch, not a redeployment. Data for the period of operation is preserved in both structures, so after returning to the previous version the lists remain up to date.

This order makes it possible to test favorites on a subset of users and remove doubts before the full launch.

Let's discuss your task for favorites on Bitrix and Vue.js

To come back with an estimate and a work plan, rather than generalities, we need to understand your current implementation: how favorites are structured now, where the state is stored, how pages receive product data. Describe this in free form — then we'll ask clarifying questions and propose a solution.

It's helpful to attach to the description whatever you already have on hand:

• how favorites currently work — page reload, a separate section in the personal account, or browser local storage;
• where the data lives — infoblock, trade offers, an external service, and whether it's tied to an authorized user;
• how the frontend is structured — Vue.js is connected selectively on individual blocks or is already built as a separate application;
• which templates and components are affected — product card, catalog, cart, site header;
• how exchanges with 1C are currently structured — what comes to the site and how often;
• which constraints matter — load, caching, requirements for interface response speed;
• whether there is a test environment where changes can be verified before rolling out to the production site.

Based on this description, we'll assess the scope: whether state storage needs to be rewritten, a communication layer between Vue.js and the server side added, templates reworked, or whether targeted edits are enough.

Separately, we'll check how the solution behaves when the cache is cleared, the browser is changed, and for an unauthorized visitor — these are typical places where favorites "get lost."

In response, you'll receive a work estimate, a phased plan with the rollout order, and a list of what will be required on your side: access credentials, a test environment, a contact for the developer who led the project.

If the description shows that the task can be closed with minimal effort, we'll say so — without pushing a rewrite of the entire frontend.

Describe your current favorites implementation — we'll come back with an estimate and a work plan.