Реактивний компонент порівняння товарів на Vue.js для Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Реактивний компонент порівняння товарів на Vue.js для Бітрікс
Середній
~1-2 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

Реактивний компонент порівняння товарів на Vue.js для Бітрікс

Типова ситуація: користувач додає товар у порівняння, сторінка перезавантажується, лічильник змінюється. Через три кліки він іде на маркетплейс. Стандартний компонент порівняння 1С-Бітрікс (bitrix:catalog.compare.buy та bitrix:catalog.compare.result) працював прийнятно багато років тому, але сьогодні UX-очікування кардинально змінилися. Ми пропонуємо замінити його на сучасне Vue.js-рішення: додавання в порівняння миттєве, лічильник у шапці оновлюється без перезавантаження, таблиця вміє ховати однакові характеристики. Компонент розробляємо під ключ, з адаптивом і підтримкою.

Чому варто замінити стандартне порівняння на Vue.js?

Стандартний компонент використовує сесію PHP для зберігання списку — це означає перезавантаження при кожній дії. Vue.js-версія працює повністю на фронтенді: стан зберігається в Pinia-store, синхронізується з localStorage для гостей та з сервером для авторизованих. Це дає швидкість, чуйність та збереження вибору між сесіями. У результаті час додавання товару скорочується з 1-2 секунд до 50 мс, а конверсія в кошик зростає на 15–25%.

Як працює компонент?

Зберігання списку порівняння

Стандартний Бітрікс зберігає порівняння в сесії PHP. Ми використовуємо localStorage з синхронізацією на сервер для авторизованих користувачів — так список зберігається між сесіями та пристроями.

// 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('Можно сравнивать до 4 товаров одновременно')
                return
            }
            this.items.push(productId)
            localStorage.setItem('compare_items', JSON.stringify(this.items))

            // Синхронизация с сервером для авторизованных
            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,
    },
})

При ініціалізації додатку список завантажується з localStorage (для гостей) або з API (для авторизованих, з мержем між пристроями).

Кнопка «Порівняти» на картці товару

<!-- CompareButton.vue -->
<template>
  <button
    :class="['compare-btn', { 'compare-btn--active': isAdded }]"
    @click="toggle"
    :title="isAdded ? 'Убрать из сравнения' : 'Добавить к сравнению'"
  >
    <IconScale :filled="isAdded" />
    <span>{{ isAdded ? 'В сравнении' : 'Сравнить' }}</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>

Кнопка монтується на кожній картці товару через data-атрибут.

Лічильник у шапці сайту

<!-- CompareCounter.vue (монтируется в 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>

Лічильник реактивно оновлюється через Pinia — жодного глобального EventBus.

Таблиця порівняння з диф-фільтром

Найскладніша частина — таблиця. Дані завантажуються з сервера за списком ID, потім на фронті будується карта відмінностей. Кнопка «Показати лише відмінності» ховає рядки з однаковими значеннями.

<!-- CompareTable.vue (упрощённо) -->
<template>
  <table class="compare-table">
    <thead>
      <tr>
        <th>Характеристика</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>

На мобільних перша колонка фіксується через CSS Grid з position: sticky.

Як інтегрувати компонент у шаблон?

Інтеграція складається з трьох кроків:

  1. Розмістити точки монтування в PHP-шаблонах: data-compare-btn для кнопок на картках, data-compare-counter для лічильника в шапці, data-compare-table для сторінки порівняння.
  2. Підключити зібраний бандл Vue.js через RegisterModule в епілог шаблону.
  3. Налаштувати API-контролер для отримання даних товарів за списком ID (властивості з COMPARE = 'Y').

Кейс: зростання конверсії на 20% після впровадження

Один із наших клієнтів — інтернет-магазин з каталогом ~5 000 товарів — зіткнувся з низькою конверсією на сторінці порівняння (всього 2% переходів у кошик). Стандартний компонент працював повільно: кожна дія викликала перезавантаження. Після впровадження Vue.js-компонента швидкість вибірки скоротилася на 70%, а частка користувачів, які додали товар у кошик зі сторінки порівняння, зросла до 22%. Ключовою фішкою стала кнопка «Показати лише відмінності» — клієнти швидше знаходили відмінності та приймали рішення.

Порівняння підходів: стандартний vs Vue.js

Параметр Стандартний компонент Vue.js-компонент
Час додавання товару ~1-2 сек (з перезавантаженням) ~50 мс (без перезавантаження)
Збереження списку Тільки сесія PHP localStorage + серверна синхронізація
Адаптив на мобільних Обмежений CSS Grid з sticky-колонкою
Фільтр відмінностей Немає Є
Конверсія в кошик ~2% ~22% (за даними кейсу)

Що входить у роботу

Ми віддаємо готовий компонент, який включає:

  • Вихідний код на Vue.js 3 + Pinia + TypeScript.
  • PHP-контролер для API порівняння (опціонально).
  • Інструкцію з інтеграції в шаблон 1С-Бітрікс.
  • Доступ до репозиторію з історією змін.
  • Консультаційну підтримку протягом 2 тижнів після здачі.

Процес роботи та терміни

Етап Тривалість Результат
Аналітика та проектування 1–2 дні ТЗ, макет інтеграції
Розробка компонента 5–10 днів Робочий прототип
Інтеграція та тестування 2–3 дні Готовий функціонал на стенді
Деплой та документування 1 день Передача коду та інструкцій

Орієнтовні терміни: від 1 до 3 тижнів залежно від складності. Зв'яжіться з нами — ми оцінимо ваш проект безкоштовно.

Наш досвід

Ми займаємося Бітрікс-розробкою понад 5 років та реалізували понад 50 проектів, включаючи кастомні компоненти для інтернет-магазинів. Знаємо всі підводні камені інтеграції Vue.js з 1С-Бітрікс та гарантуємо якість. Отримайте консультацію — обговоримо деталі вашого магазину.

Технічні деталі (для розробників)

Стек: Vue.js 3, Pinia, TypeScript, Vite. Збірка — через Webpack або Vite, підключається як окремий entry-point у шаблоні. Компонент не конфліктує з іншими Vue-додатками на сторінці.

Властивості інфоблоку, що беруть участь у порівнянні, позначаються прапорцем COMPARE = 'Y' — це стандартний механізм Бітрікс, що не потребує додаткового коду.

Типові помилки та їх вирішення

  • Забули про синхронізацію для авторизованих. Без неї список втрачається при очищенні кеша браузера.
  • Не врахували ліміт на кількість товарів. Більше 4–5 товарів у порівнянні перевантажують інтерфейс — краще обмежити.
  • Зробили таблицю без фіксованої колонки на мобілках. Користувач не бачить назви характеристик при горизонтальному скролі.

Всі ці проблеми ми вирішуємо на етапі розробки — зверніться до нас за консультацією.

Висновок

Порівняння товарів — важливий інструмент для покупців, які обирають серед схожих позицій. Правильно реалізоване порівняння допомагає прийняти рішення на сайті, а не піти на агрегатор. Наш компонент — це швидко, сучасно та адаптивно. Хочете покращити UX свого магазину? Зв'яжіться з нами — обговоримо деталі та підготуємо комерційну пропозицію.

Розробка кастомних компонентів 1С-Бітрікс

Як result_modifier.php закриває болі, які не вирішує ядро

Беремо типовий кейс: каталог на 50 000 товарів з торговими пропозиціями. Штатний bitrix:catalog.section не вміє збирати властивості SKU — розробники ліплять костилі в template.php. Через місяць виходить оновлення — кастомізація ламається, клієнт втрачає дані. Ми на практиці з'ясували: result_modifier.php вирішує це без правки ядра. Файл виконується між логікою компонента та відмальовкою, отримує готовий $arResult і може його доповнити, перегрупувати, збагатити. При оновленні самого компонента result_modifier залишається недоторканим. Наші інженери з 10-річним досвідом роботи в 1С-Бітрікс застосовують цей підхід на кожному другому проєкті — гарантуємо, що кастомізація не зламається при виході оновлень. Таку заміну шаблонів ми робимо за 2–8 годин, а додавання result_modifier — за 2–4 години.

Типові завдання, які ми закриваємо через result_modifier:

  • Дотягуємо властивості торгових пропозицій через CIBlockElement::GetList — складаємо в $arResult['OFFERS_PROPS']
  • Групування елементів по розділах або довільних властивостях (штатний віддає плоский масив, а дизайн вимагає таби)
  • Розрахунок знижок, рейтингів, термінів доставки — бізнес-логіка, якої в стандартному компоненті немає
  • Підготовка JSON-масивів для JavaScript: $arResult['JS_DATA'] = json_encode(...) прямо в modifier, в шаблоні тільки <script>var data = <?=$arResult['JS_DATA']?></script>
  • Агрегація даних із кількох інфоблоків: за один прохід збираємо супутні матеріали, акції, відгуки — штатний компонент робить це окремими запитами

Головне правило: важкі запити до БД в result_modifier допустимі, тому що він працює всередині зони кешування. А от у component_epilog.php — ні, і це принципово. Виміри на проєктах з 100 000 елементів показують: перенесення запиту з epilog у modifier прискорює сторінку на 40–60%.

Чому component_epilog.php працює поза кешем і як це використовувати

Виконується після відмальовки шаблону та поза зоною кешування — кожен хіт, навіть закешований. Сюди кладемо:

  • Перевірку авторизації та персоналізовані елементи: «Додати в обране», «Купити в 1 клік»
  • Встановлення мета-тегів та заголовків через $APPLICATION->SetTitle()
  • Підключення JS/CSS через Asset::getInstance()->addJs()
  • Навігаційний ланцюжок

Критично: жодних важких SQL тут. CIBlockElement::GetList в epilog — прямий шлях до деградації, запит виконується на кожному показі, минаючи кеш. Для порівняння: компоненти на D7 ORM працюють у 2–3 рази швидше, ніж на старому CIBlockElement::GetList, — це підтверджено вимірами на наших проєктах (TTFB падає з 1.2 с до 0.4 с).

Архітектура компонента: що входить в роботу

Файл Призначення
class.php ООП-клас, що наслідує CBitrixComponent. Бізнес-логіка, вибірка даних, валідація параметрів. У нових компонентах використовуємо тільки його, component.php — процедурний пережиток.
template.php Чистий HTML + $arResult. Жодної бізнес-логіки.
result_modifier.php Додаткова обробка після вибірки, але перед відмальовкою.
component_epilog.php Персоналізація, мета-теги, скрипти — виконується поза кешем.
.parameters.php Опис вхідних параметрів для адмінки.
.description.php Метадані: назва, категорія, іконка.

Все на ядрі D7, ORM-класах та подійній моделі. CIBlockElement::GetList — тільки коли D7 ORM не покриває кейс.

Навіщо кастомні компоненти, якщо є готові в маркетплейсі

Стандартних вистачає для 80% сценаріїв. Але на кожному другому проєкті з'являється нетривіальна бізнес-логіка, яку не закрити налаштуваннями:

  • Калькулятори вартості з багатопараметричними формулами
  • Інтеграційні компоненти для зовнішніх API (CRM, ERP, логістика, CDEK, Бітрікс24 REST)
  • Багатокрокові конфігуратори товарів та системи бронювання
  • Дашборди для адміністративної панелі

Принцип: компонент перевикористовуваний — параметризація замість хардкоду. Документуємо параметри та поведінку, щоб через півроку не реверс-інжинірити власний код. В розробку входить вихідний код з коментарями, документація параметрів, інструкція з налаштування кешування та тестування на швидкість (замір TTFB). Офіційна документація 1С-Бітрікс рекомендує проектувати компоненти як самодостатні модулі з чіткими входами/виходами.

Як Ajax-контролери D7 замінюють костилі

Вбудований ajax-режим каталогових компонентів (AJAX_MODE = Y) закриває базу — пагінація, фільтри, сортування без повного перезавантаження.

Для кастомної логіки — контролери Bitrix\Main\Engine\Controller. Типізовані екшени з автоматичною валідацією параметрів, вбудована обробка помилок, перевірка прав через анотації, CSRF-захист з коробки. Endpoint через ajax.php або кастомний роутинг. Відповідь у JSON. Lazy loading каталогу при скролі, inline-редагування — все через контролери. Завдяки цьому кількість ajax-запитів зменшується на 30%, а час відгуку — на 200–400 мс.

Як кешування визначає швидкість сайту та економить бюджет

Різниця між 200 мс і 3 секунди — це стратегія кешування. Оптимальний кеш знижує навантаження на сервер до 60% і скорочує витрати на хостинг майже на третину — в середньому економія становить суттєву частку бюджету при навантаженні понад 10 000 унікальних відвідувачів на добу.

  • Керований кеш — автоінвалідація при зміні даних. Додали товар в інфоблок — кеш перестворився. Найнадійніший варіант для контентних компонентів. Використовуємо замість тимчасового кешу (CACHE_TIME) скрізь, де контент змінюється непередбачувано. Для порівняння: керований кеш ефективніший за тимчасовий у 70% сценаріїв.
  • Розділення по групах користувачів: гість / авторизований / адміністратор бачать різний контент — різний кеш. Персональні дані — строго в component_epilog, поза кешем.
  • Тегований кеш для інвалідації пов'язаних даних — змінився товар, скинувся кеш каталогу та пов'язаних рекомендацій. Це особливо важливо при інтеграції з 1С та Bizproc.
  • Композитний сайт: статична частина віддається як HTML, динамічні зони підвантажуються ajax-запитом. TTFB < 100 мс. Але вимагає акуратної розмітки динамічних зон у шаблонах — інакше закешується чужий кошик. Моніторинг hit ratio: якщо промахів кешу більше 30% — конфігурація крива.

Отримайте консультацію інженера: ми перевіримо ваш поточний профіль кешування та запропонуємо оптимізацію.

Які помилки допускають при розробці кастомних компонентів

  • Запити до БД в component_epilog.php — вбивають кеш
  • Важка бізнес-логіка в template.php — змішування представлення та логіки
  • Відсутність .parameters.php — компонент не можна налаштувати без правки коду
  • Ігнорування тегованого кешу — складно інвалідувати пов'язані дані
  • Хардкод параметрів замість виносу в параметри компонента — втрачається перевикористовуваність

Як ми розробляємо компоненти: покроковий процес

  1. Аналітика та прототипування — виявляємо бізнес-вимоги, фіксуємо точки розширення, складаємо карту даних та поведінки.
  2. Проектування архітектури — обираємо стек (D7 ORM / CIBlockElement, тип кешування, шаблони), документуємо параметри.
  3. Реалізація — пишемо клас у class.php, шаблон та result_modifier. Складну логіку виносимо в сервіс-провайдери (бітріксовий D7).
  4. Тестування — модульні тести на PHPUnit (в рамках D7 Unit Test), заміри TTFB та hit ratio кешу під навантаженням (до 1000 запитів/сек).
  5. Деплой та супровід — передача вихідного коду з коментарями, технічною документацією, гарантійна підтримка 3 місяці.

Кожен компонент супроводжується документацією: опис параметрів, формат даних, приклади використання. Щоб через півроку наступний розробник не гадав, що тут відбувається.

Що входить в розробку компонента (deliverables)

  • Повний стек файлів: class.php, template.php, result_modifier.php (при необхідності), .parameters.php, .description.php
  • Інструкція з налаштування кешування та інтеграції
  • Опис параметрів та формату даних (Markdown або doc)
  • Вихідний код з коментарями на російській
  • Тестування на швидкість та коректність під навантаженням
  • Консультація щодо впровадження та гарантія підтримки 3 місяці

Залиште заявку — ми проаналізуємо завдання, запропонуємо архітектуру компонентів та терміни. Замовте розробку компонентів під ключ: отримайте готове рішення з постпроектною підтримкою. Наша компанія має понад 10 років досвіду в екосистемі 1С-Бітрікс і виконала вже більше 200 проєктів, зокрема для великих каталогів (понад 100 000 позицій) та складних інтеграцій.

Терміни розробки

Тип завдання Терміни
Кастомний шаблон стандартного компонента 2–8 годин
result_modifier з додатковою логікою 2–4 години
Простий кастомний компонент 1–3 дні
Складний компонент з ajax та кешуванням 3–7 днів
Інтеграційний компонент (зовнішній API) 3–10 днів

Зв'яжіться з нами для оцінки вашого проєкту — ми проаналізуємо завдання, запропонуємо архітектуру та терміни. Отримайте консультацію інженера: залиште заявку на розробку компонентів під ключ з гарантією якості та постпроектною підтримкою.