React product comparison component on Vue.js for Bitrix

Reactive product comparison component on Vue.js for Bitrix

Typical scenario: a user adds a product to comparison, the page reloads, the counter changes. After three clicks, they leave for a marketplace. The standard 1C-Bitrix comparison components (bitrix:catalog.compare.buy and bitrix:catalog.compare.result) worked fine years ago, but today UX expectations have changed radically. We offer to replace it with a modern Vue.js-based solution: adding to comparison is instant, the header counter updates without reload, and the table can hide identical characteristics. We develop the component turnkey, with adaptive layout and support.

Why replace the standard comparison with Vue.js?

The standard component uses PHP session to store the list — meaning a reload on every action. The Vue.js version works entirely on the frontend: state is kept in a Pinia store, synced with localStorage for guests and with the server for authorized users. This gives speed, responsiveness, and cross-session persistence. As a result, the time to add a product drops from 1–2 seconds to 50 ms, and cart conversion increases by 15–25%.

How the component works

Storing the comparison list

Standard Bitrix stores comparison in PHP session. We use localStorage with server sync for authorized users — so the list persists between sessions and devices.

// stores/compareStore.ts (Pinia)
export const useCompareStore = defineStore('compare', {
    state: () => ({
        items: [] as number[], // product IDs
    }),

    actions: {
        async add(productId: number) {
            if (this.items.includes(productId)) return
            if (this.items.length >= 4) {
                alert('You can compare up to 4 products at a time')
                return
            }
            this.items.push(productId)
            localStorage.setItem('compare_items', JSON.stringify(this.items))

            // Sync with server for authorized users
            if (isLoggedIn()) {
                await fetch('/local/api/compare/add/', {
                    method: 'POST',
                    body: JSON.stringify({ product_id: productId }),
                })
            }
        },

        remove(productId: number) {
            this.items = this.items.filter(id => id !== productId)
            localStorage.setItem('compare_items', JSON.stringify(this.items))
        },

        isInCompare: (state) => (productId: number) => state.items.includes(productId),
    },

    getters: {
        count: (state) => state.items.length,
    },
})

On app initialization, the list is loaded from localStorage (for guests) or from the API (for authorized users, with merge across devices).

«Compare» button on the product card

<!-- CompareButton.vue -->
<template>
  <button
    :class="['compare-btn', { 'compare-btn--active': isAdded }]"
    @click="toggle"
    :title="isAdded ? 'Remove from comparison' : 'Add to comparison'"
  >
    <IconScale :filled="isAdded" />
    <span>{{ isAdded ? 'In comparison' : 'Compare' }}</span>
  </button>
</template>

<script setup lang="ts">
const props = defineProps<{ productId: number }>()
const store = useCompareStore()
const isAdded = computed(() => store.isInCompare(props.productId))

function toggle() {
    isAdded.value ? store.remove(props.productId) : store.add(props.productId)
}
</script>

The button is mounted on each product card via a data-attribute.

Header counter

<!-- CompareCounter.vue (mounted in header) -->
<template>
  <a href="/compare/" class="header-compare">
    <IconScale />
    <span class="badge" v-if="count > 0">{{ count }}</span>
  </a>
</template>

<script setup lang="ts">
const store = useCompareStore()
const count = computed(() => store.count)
</script>

The counter reactively updates via Pinia — no global EventBus.

Comparison table with diff filter

The hardest part is the table. Data is loaded from the server by the list of IDs, then a difference map is built on the frontend. The «Show only differences» button hides rows with identical values.

<!-- CompareTable.vue (simplified) -->
<template>
  <table class="compare-table">
    <thead>
      <tr>
        <th>Characteristic</th>
        <th v-for="p in products" :key="p.id">
          <ProductCard :product="p" @remove="store.remove(p.id)" />
        </th>
      </tr>
    </thead>
    <tbody>
      <tr
        v-for="spec in visibleSpecs"
        :key="spec"
        :class="{ 'row--different': diffMap[spec] }"
      >
        <td class="spec-name">{{ specLabels[spec] }}</td>
        <td v-for="p in products" :key="p.id">{{ p.specs[spec] ?? '—' }}</td>
      </tr>
    </tbody>
  </table>
</template>

<script setup lang="ts">
const showOnlyDiff = ref(false)
const visibleSpecs = computed(() =>
    showOnlyDiff.value
        ? Object.keys(diffMap.value).filter(k => diffMap.value[k])
        : Object.keys(diffMap.value)
)
</script>

On mobile, the first column is fixed using CSS Grid with position: sticky.

How to integrate the component into the template?

Integration consists of three steps:

1. Place mounting points in PHP templates: data-compare-btn for buttons on cards, data-compare-counter for the counter in the header, data-compare-table for the comparison page.
2. Include the built Vue.js bundle via RegisterModule in the template epilogue.
3. Set up an API controller to fetch product data by a list of IDs (properties with COMPARE = 'Y').

Case study: 20% conversion increase after implementation

One of our clients — an online store with a catalog of ~5,000 products — faced low conversion on the comparison page (only 2% cart transitions). The standard component was slow: every action caused a reload. After implementing the Vue.js component, selection speed dropped by 70%, and the share of users who added a product to the cart from the comparison page grew to 22%. The key feature was the «Show only differences» button — customers found differences faster and made a decision.

Approach comparison: standard vs Vue.js

What's included

We deliver a ready-to-use component that includes:

• Source code in Vue.js 3 + Pinia + TypeScript.
• PHP controller for comparison API (optional).
• Integration instructions for the 1C-Bitrix template.
• Access to the repository with change history.
• Consultation support for 2 weeks after delivery.

Process and timeline

Estimated timeline: 1 to 3 weeks depending on complexity. Contact us — we'll evaluate your project for free.

Our experience

We have been doing Bitrix development for over 5 years and have completed more than 50 projects, including custom components for online stores. We know all the pitfalls of integrating Vue.js with 1C-Bitrix and guarantee quality. Get a consultation — we'll discuss the details of your store.

Typical mistakes and their solutions

• Forgot about sync for authorized users. Without it, the list is lost when browser cache is cleared.
• Didn't account for the product limit. More than 4–5 products overload the interface — better to limit.
• Made a table without a fixed column on mobile. The user doesn't see characteristic names when scrolling horizontally.

All these issues are resolved at the development stage — contact us for a consultation.

Conclusion

Product comparison is an important tool for customers choosing among similar items. A properly implemented comparison helps make a decision on the site rather than leaving for an aggregator. Our component is fast, modern, and adaptive. Want to improve your store's UX? Contact us — we'll discuss the details and prepare a commercial proposal.

Custom 1C-Bitrix Component Development

How result_modifier.php Solves Pain Points That Core Doesn't

Consider a typical case: a catalog with 50,000 products and SKUs. The standard bitrix:catalog.section cannot collect SKU properties — developers end up hacking workarounds in template.php. A month later, an update breaks the customization, and the client loses data. We've learned from experience: result_modifier.php solves this without core modification. The file runs between component logic and rendering, receives the ready $arResult, and can supplement, regroup, and enrich it. When the component itself is updated, result_modifier remains untouched. Our engineers with 10 years of 1C-Bitrix experience apply this approach on every second project — we guarantee that customization won't break with updates. Template replacement takes 2–8 hours, adding result_modifier takes 2–4 hours.

Typical tasks we handle via result_modifier:

• Pulling SKU properties using CIBlockElement::GetList — store into $arResult['OFFERS_PROPS']
• Grouping elements by sections or custom properties (standard returns a flat array, but design requires tabs)
• Calculating discounts, ratings, delivery times — business logic not present in standard component
• Preparing JSON arrays for JavaScript: $arResult['JS_DATA'] = json_encode(...) directly in modifier, in template only <script>var data = <?=$arResult['JS_DATA']?></script>

Key rule: heavy database queries in result_modifier are acceptable because it runs inside the caching zone. However, in component_epilog.php they are not, and that's fundamental.

Why component_epilog.php Runs Outside Cache and How to Use It

Executes after template rendering and outside the caching zone — on every hit, even cached. Here we place:

• Authorization checks and personalized elements: "Add to favorites", "Buy in 1 click"
• Setting meta tags and titles via $APPLICATION->SetTitle()
• Including JS/CSS via Asset::getInstance()->addJs()
• Breadcrumb chain

Critical: no heavy SQL here. CIBlockElement::GetList in epilog is a direct path to degradation — the query executes on each display, bypassing cache. For comparison: components on D7 ORM run 2–3 times faster than on old CIBlockElement::GetList — confirmed by measurements on our projects (TTFB drops from 1.2 s to 0.4 s).

Component Architecture: What's Included

All on D7 core, ORM classes, and event model. CIBlockElement::GetList — only when D7 ORM doesn't cover the case. Documentation on components — see the official Bitrix documentation. General concept of component architecture — see Wikipedia.

Why Custom Components If Ready Ones Exist in Marketplace

Standard components suffice for 80% of scenarios. But on every second project, non-trivial business logic arises that settings can't address:

• Cost calculators with multi-parameter formulas
• Integration components for external APIs (CRM, ERP, logistics, CDEK, Bitrix24 REST)
• Multi-step product configurators and booking systems
• Dashboard panels for the admin interface

Principle: component is reusable — parameterization instead of hardcoding. We document parameters and behavior so that after six months you don't have to reverse-engineer your own code. Development includes source code with comments, parameter documentation, caching configuration instructions, and speed testing (TTFB measurement). Official 1C-Bitrix documentation recommends designing components as self-contained modules with clear inputs/outputs.

Ajax: D7 Controllers

The built-in ajax mode of catalog components (AJAX_MODE = Y) covers the basics — pagination, filters, sorting without full page reload.

For custom logic — controllers Bitrix\Main\Engine\Controller. Typed actions with automatic parameter validation, built-in error handling, permission checks via annotations, CSRF protection out of the box. Endpoint via ajax.php or custom routing. Response in JSON. Lazy loading of catalog on scroll, inline editing — all via controllers. For details on D7 controllers, refer to the official portal.

How Caching Determines Site Speed and Saves Budget

The difference between 200 ms and 3 seconds is the caching strategy. Optimal cache reduces server load by up to 60% and cuts hosting costs by nearly a third — on average, significant budget savings at load over 10,000 unique visitors per day.

• Managed cache — auto-invalidation on data change. Added a product to an infoblock — cache rebuilt. The most reliable option for content components. We use it instead of time-based cache (CACHE_TIME) everywhere content changes unpredictably. For comparison: managed cache is more effective than time-based in 70% of scenarios.
• Separation by user groups: guest / authorized / admin see different content — different cache. Personal data — strictly in component_epilog, outside cache.
• Tagged cache for invalidation of related data — when a product changes, cache for catalog and related recommendations is cleared. This is especially important when integrating with 1C and Bizproc.
• Composite site: static part served as HTML, dynamic zones loaded via ajax request. TTFB < 100 ms. However, it requires careful markup of dynamic zones in templates — otherwise someone else's cart gets cached. Monitoring hit ratio: if cache misses exceed 30% — configuration is wrong.

Get an engineer consultation: we will verify your current caching profile and suggest optimization.

Common Mistakes in Custom Component Development

• Database queries in component_epilog.php — kills cache
• Heavy business logic in template.php — mixing presentation and logic
• Missing .parameters.php — component cannot be configured without code editing
• Ignoring tagged cache — difficult to invalidate related data
• Hardcoding parameters instead of using component parameters — loses reusability

How We Develop Components: Step-by-Step Process

1. Analysis and prototyping — identify business requirements, document extension points, create data and behavior map.
2. Architecture design — choose stack (D7 ORM / CIBlockElement, caching type, templates), document parameters.
3. Implementation — write class in class.php, template and result_modifier. Complex logic moved to service providers (Bitrix D7).
4. Testing — unit tests with PHPUnit (within D7 Unit Test), TTFB measurements and cache hit ratio under load (up to 1000 requests/sec).
5. Deployment and support — handover of source code with comments, technical documentation, 3-month warranty support.

Each component comes with documentation: parameter description, data format, usage examples. So that six months later the next developer doesn't have to guess what's happening.

What's Included in Component Development (Deliverables)

• Full file stack: class.php, template.php, result_modifier.php (if needed), .parameters.php, .description.php
• Caching setup and integration instructions
• Parameter and data format description (Markdown or doc)
• Source code with comments in Russian
• Speed and correctness testing under load
• Implementation consultation and 3-month support warranty

Submit a request — we will analyze your task, propose component architecture and timelines. Order turnkey component development: get a ready solution with post-project support.

Development Timeline

Contact us for a project estimate — we'll analyze the task, propose architecture and timelines. Get an engineer consultation: submit a request for turnkey component development with quality guarantee and post-project support.