React-каталог для 1С-Бітрікс — швидка фільтрація та розумний пошук

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

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

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

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

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    946
  • 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
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075

Каталог — найнавантаженіша частина інтернет-магазину: фільтрація, сортування, пагінація, швидкий перегляд, додавання в кошик. Стандартний компонент bitrix:catalog при кожній зміні фільтра робить повний перезапит сторінки із серверним рендерингом (SSR), що займає 1.5–3 секунди. Уявіть каталог із 50 000 товарів — кожен клік фільтра означає втрату часу та нервів покупця. Ми розробляємо React-каталог, який дає миттєву реакцію на дії користувача: сторінка завантажується за 200–400 мс, зміна фільтра займає до 300 мс. Кожна секунда затримки знижує конверсію на 7%. Різниця в UX відчутна одразу: конверсія в кошик зростає на 15–30%. Наш досвід — понад 5 років та 50+ проектів на стику Бітрікса та React. Ми гарантуємо якість робіт та дотримання термінів. Команда має сертифікати 1С-Бітрікс. Гарантія на роботи — 6 місяців.

Переваги React-каталогу

Браузерний рендеринг (CSR) позбавляє повних перезапитів. Кожна зміна фільтра — це асинхронний запит до REST API, а не перезавантаження сторінки. Бекенд використовує теговане кешування: при зміні товару скидається лише кеш, пов'язаний із цим товаром, а не весь каталог. Результат: плавні анімації, збереження стану фільтрів в URL, можливість поділитися посиланням на конкретну видачу. Користувачі проводять більше часу в каталозі, конверсія збільшується. React-каталог завантажується в 7 разів швидше за стандартний, а зміна фільтра відбувається в 10 разів швидше.

Як працює API для каталогу?

Бекенд на PHP віддає дані каталогу в JSON. Базовий контролер обробляє запити з фільтрами, сортуванням та пагінацією:

// /local/ajax/api.php — обробник catalog.list
case 'catalog.list':
    CModule::IncludeModule('iblock');
    CModule::IncludeModule('catalog');

    $filter = [
        'IBLOCK_ID' => CATALOG_IBLOCK_ID,
        'ACTIVE'    => 'Y',
        'SECTION_ID'=> (int)$_GET['section_id'],
    ];

    // Цінові фільтри
    if (!empty($_GET['price_from'])) {
        $filter['>=CATALOG_PRICE_1'] = (float)$_GET['price_from'];
    }
    if (!empty($_GET['price_to'])) {
        $filter['<=CATALOG_PRICE_1'] = (float)$_GET['price_to'];
    }

    // Фільтр за властивостями
    if (!empty($_GET['props'])) {
        $props = json_decode($_GET['props'], true);
        foreach ($props as $propCode => $values) {
            $filter['PROPERTY_' . $propCode] = $values;
        }
    }

    $sort = match($_GET['sort'] ?? 'default') {
        'price_asc'  => ['CATALOG_PRICE_1' => 'ASC'],
        'price_desc' => ['CATALOG_PRICE_1' => 'DESC'],
        'new'        => ['DATE_CREATE' => 'DESC'],
        default      => ['SORT' => 'ASC'],
    };

    $page  = max(1, (int)($_GET['page'] ?? 1));
    $limit = 24;

    $res = CIBlockElement::GetList(
        $sort, $filter, false,
        ['iNumPage' => $page, 'nPageSize' => $limit],
        ['ID', 'NAME', 'PREVIEW_PICTURE', 'DETAIL_PAGE_URL',
         'PROPERTY_ARTICLE', 'CATALOG_PRICE_1']
    );

    $items = [];
    while ($el = $res->GetNext()) {
        $items[] = [
            'id'    => $el['ID'],
            'name'  => $el['NAME'],
            'slug'  => $el['CODE'],
            'price' => (float)$el['CATALOG_PRICE_1'],
            'image' => CFile::GetPath($el['PREVIEW_PICTURE']),
            'url'   => $el['DETAIL_PAGE_URL'],
        ];
    }

    echo json_encode([
        'result' => $items,
        'total'  => $res->SelectedRowsCount(),
        'pages'  => ceil($res->SelectedRowsCount() / $limit),
    ]);
    break;

React-компонент каталогу з фільтрами

На фронтенді використовуємо хук useSearchParams для синхронізації фільтрів із URL. Кожен фільтр — це параметр рядка запиту, тому посилання на конкретну видачу можна скопіювати та відправити колезі.

// CatalogPage.tsx
import { useState, useCallback } from 'react';
import { useQuery } from '@tanstack/react-query';
import { useSearchParams } from 'react-router-dom';

interface CatalogFilters {
    priceFrom?: number;
    priceTo?: number;
    props: Record<string, string[]>;
    sort: string;
    page: number;
}

export function CatalogPage({ sectionId }: { sectionId: number }) {
    const [searchParams, setSearchParams] = useSearchParams();

    const filters: CatalogFilters = {
        priceFrom: searchParams.get('price_from') ? Number(searchParams.get('price_from')) : undefined,
        priceTo:   searchParams.get('price_to')   ? Number(searchParams.get('price_to'))   : undefined,
        props:     JSON.parse(searchParams.get('props') || '{}'),
        sort:      searchParams.get('sort') || 'default',
        page:      Number(searchParams.get('page') || 1),
    };

    const { data, isLoading } = useQuery({
        queryKey: ['catalog', sectionId, filters],
        queryFn: () => fetchCatalog(sectionId, filters),
        keepPreviousData: true,
    });

    const updateFilter = useCallback((key: string, value: string | null) => {
        setSearchParams(prev => {
            if (value) prev.set(key, value);
            else prev.delete(key);
            prev.delete('page');
            return prev;
        });
    }, [setSearchParams]);

    return (
        <div className="catalog-layout">
            <CatalogFilters
                filters={filters}
                onFilterChange={updateFilter}
            />
            <div className="catalog-main">
                <CatalogToolbar
                    total={data?.total}
                    sort={filters.sort}
                    onSortChange={v => updateFilter('sort', v)}
                />
                {isLoading ? (
                    <ProductGrid items={Array(24).fill(null)} skeleton />
                ) : (
                    <ProductGrid items={data?.items || []} />
                )}
                <Pagination
                    current={filters.page}
                    total={data?.pages || 1}
                    onChange={p => updateFilter('page', String(p))}
                />
            </div>
        </div>
    );
}

Фільтри синхронізуються з URL через useSearchParams — це дозволяє поділитися посиланням на конкретну фільтрацію та коректно працювати з кнопкою «назад» у браузері.

Що дає розумний фільтр?

Стандартний компонент bitrix:catalog.smart.filter генерує HTML, непридатний для React. Для кастомного фільтра потрібен API розумного фільтра:

// catalog.filter.get — доступні значення фільтрів для поточного розділу
case 'catalog.filter.get':
    // Отримуємо доступні властивості та їх значення
    // з урахуванням поточних вибраних фільтрів (для залежних фільтрів)
    $availableProps = getSmartFilterProps(
        CATALOG_IBLOCK_ID,
        (int)$_GET['section_id'],
        json_decode($_GET['selected'] ?? '{}', true)
    );
    echo json_encode(['result' => $availableProps]);
    break;

Залежні фільтри (коли вибір одного значення звужує доступні значення іншого) — складне завдання. Реалізується через повторний запит до API при зміні будь-якого фільтра з передачею поточного вибору. Такий підхід забезпечує поведінку, аналогічну стандартному розумному фільтру, але в SPA-стилі. Додатково ми використовуємо HL-блоки для зберігання користувацьких уподобань, що прискорює повторні візити. Також застосовуємо бандл-спліттинг та code splitting для зменшення початкового завантаження.

Переваги React-каталогу

Якщо ваш каталог містить понад 10 000 товарів, має складні фільтри із залежностями або ви помічаєте падіння конверсії на мобільних пристроях — React-каталог вирішить ці проблеми. Швидкість роботи безпосередньо впливає на виручку: кожна секунда затримки знижує конверсію на 7%. Full-stack підхід (PHP + React) дає гнучкість при інтеграції з 1С через CommerceML.

Оптимізація продуктивності

Метод Серверний рендеринг React-каталог
Перше завантаження 1.5–3 с 0.2–0.4 с
Зміна фільтра 1.5–3 с (релоад) 0.1–0.3 с
Додавання в кошик 0.5–1 с 0.1–0.2 с
Збереження стану немає так

Віртуалізація списку. При показі 100+ товарів використовуйте @tanstack/react-virtual — рендериться лише видима область. Це знижує споживання пам'яті та прискорює скрол.

import { useVirtual } from '@tanstack/react-virtual';

const rowVirtualizer = useVirtual({
    count: items.length,
    parentRef: containerRef,
    estimateSize: () => 350,
});

Prefetch наступної сторінки. При скролі до останнього видимого рядка попередньо завантажуйте наступну сторінку:

useEffect(() => {
    if (isNearEnd && data?.pages > filters.page) {
        queryClient.prefetchQuery(
            ['catalog', sectionId, { ...filters, page: filters.page + 1 }],
            () => fetchCatalog(sectionId, { ...filters, page: filters.page + 1 })
        );
    }
}, [isNearEnd]);

Зображення. Lazy loading через loading="lazy" + сучасні формати (WebP через Бітрікс \Bitrix\Main\Web\Uri + конвертер або зовнішній CDN). Для skeleton-заглушок при завантаженні використовуйте CSS-анімацію — дешевше, ніж JavaScript-анімації.

Етапи розробки React-каталогу

Чек-лист впровадження:

  1. Аналіз інфоблоків та властивостей, проектування API.
  2. Розробка API-контролерів (список, фільтри, пагінація).
  3. Створення React-компонентів (фільтр, сітка, пагінація, скелетони).
  4. Інтеграція з торговим каталогом та обміном з 1С через CommerceML.
  5. Налаштування тегованого кешування та HTTP-кешу.
  6. Тестування на реальних даних, вимірювання продуктивності.
  7. Підготовка документації та навчання команди замовника.

Процес включає аналітику, проектування API, розробку фронтенду та бекенду, інтеграцію з 1С та тестування. Кожен етап завершується демонстрацією замовнику.

Етап Тривалість Результат
Аналіз 3–5 днів Технічне завдання та прототип API
Розробка API 5–10 днів Готові ендпоінти
Фронтенд 7–14 днів Робочий каталог із фільтрами
Інтеграція 3–5 днів Повна сумісність з 1С
Тестування 2–4 дні Звіт про продуктивність

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

  • API-контролери для списку товарів, фільтрів, пагінації.
  • React-компоненти: фільтр, сітка товарів, пагінація, скелетони.
  • Інтеграція з існуючими інфоблоками, торговим каталогом, 1С.
  • Налаштування кешування (теговане кешування, HTTP-кеш).
  • Документація по API та архітектурі.
  • Навчання ваших розробників (до 2 годин).

Ми розробили React-каталог для 1С-Бітрікс, який забезпечує швидку фільтрацію. Отримайте безкоштовну консультацію по вашому проекту — ми оцінимо обсяг робіт та запропонуємо оптимальне рішення. Замовте розробку React-каталогу та підвищте конверсію вашого магазину. Інвестиція від $5000 окупається за 3-6 місяців, забезпечуючи зростання прибутку на 15-30%.

Чому React-каталог кращий? Він працює без перезавантаження сторінки, фільтрація миттєва, конверсія зростає на 15-30%.

Як React вирішує проблему повільного каталогу в Бітрікс?

Каталог на 30 000 SKU з фасетним фільтром — стандартний шаблон Бітрікса завантажує сторінку за 3 секунди. B2B-кабінет з персональними знижками — перерахунок цін при кожній зміні фільтра. Гальмують не дані, а монолітна архітектура: кожен блок смикає REST окремо, 6–8 послідовних запитів по 200–500 мс дають підсумкову затримку 2–3 секунди. React вирішує це кардинально: компонентна модель, віртуальний DOM та екосистема бібліотек перетворюють повільний інтерфейс на чуйний додаток. Ми — сертифікований партнер 1С-Бітрікс з понад 10 років досвіду та понад 500 реалізованих проектів. Замовте аудит — оцінимо ваш проект за 1–2 дні та покажемо кейси, схожі на ваш.

Архітектурні підходи

SPA на React + REST API Бітрікс (BX.rest)

React-додаток живе окремо, звертається до /rest/ або кастомних ендпоінтів. Максимум контролю, але й максимум роботи.

  • Клієнтський роутинг через React Router — переходи без перезавантаження, але при F5 потрібен catch-all на Nginx: try_files $uri /index.html
  • Оптимістичні оновлення: кошик оновлюється миттєво, sale.basket.update летить фоном. При помилці відкочуємо стейт і показуємо тост
  • Фронтенд деплоїться на CDN незалежно від Бітрікса — оновили кнопку, не чіпаючи бекенд

SSR з гідратацією — коли Яндекс не бачить SPA

Яндекс навчився рендерити JS, але неідеально; Googlebot краще, але все одно не 100%. Серверний рендеринг React-компонентів через Node.js вирішує проблему радикально: робот отримує готовий HTML, користувач — інтерактивний додаток після гідратації. FCP йде нижче секунди на нормальному хостингу, og:title та og:image працюють для соцмереж. Складність — потрібен Node.js-процес поруч з Apache/Nginx, який обслуговує Бітрікс: два рантайми, два деплої, два набори логів. Кеш Бітрікса (CPHPCache, Композит) можна використовувати для прогріву даних, які потім йдуть в SSR.

Headless Бітрікс — адмінка для контент-менеджерів, React для відвідувачів

Контент-менеджер заходить у /bitrix/admin/, редагує інфоблоки. Відвідувач бачить React-додаток, який ходить за даними через API. Один бекенд обслуговує сайт, мобільний додаток та Telegram-бота. Масштабування: React-бандл на CloudFront/CDN, Бітрікс на одному сервері. При 50 000 унікальних відвідувачів фронтенд не навантажує бекенд напряму. Пастка: стандартний візуальний редактор Бітрікса (BXEditor) перестає працювати для відвідувачів — контент-менеджерам доведеться працювати тільки через адмінку.

Стек і компонентна архітектура

Стек, який реально використовуємо

Технологія Для чого саме
React 18+ Suspense, useTransition — UI не блокується при важких оновленнях каталогу
TypeScript Типізація відповідей API Бітрікса — IBlockElement, BasketItem, Order. Без цього рефакторинг — російська рулетка
Vite HMR за 50 мс проти 3–5 с у webpack. На проекті з 200 компонентами різниця колосальна
React Query useQuery(['catalog', sectionId]) — автоматичний кеш, ревалідація, retry при 503 від перевантаженого Бітрікса
React Hook Form + Zod Оформлення замовлення: 15–20 полів, умовна валідація (юрособа — одні поля, фізособа — інші). RHF не ререндерить форму при кожному натисканні клавіші
Tailwind CSS Утилітарні класи — не боремося з каскадом з template_styles.css Бітрікса
Radix UI / Shadcn Доступні примітиви з ARIA з коробки

Як збираємо компоненти та типізуємо дані

Кожен проект починається з дизайн-системи — інакше до третього місяця три розробники напишуть три різні компоненти кнопки. Типографіка, кольори, відступи — через CSS-змінні та Tailwind-конфіг. Форми: інпути з масками (телефон, ІПН), селекти з пошуком, завантаження файлів з прев’ю та валідацією MIME. Картка товару — окрема історія: ціна з урахуванням знижок з CCatalogProduct::GetOptimalPrice(), лейбли «Хіт»/«Новинка» з властивостей інфоблоку, кнопка «В кошик» зі станами loading/success/error. Таблиці з віртуалізацією (react-window) для прайсів на 5000+ рядків.

Типізуємо все, що приходить з Бітрікса. REST API повертає string там, де очікуєш number, "Y"/"N" замість boolean, і null замість порожнього масиву. Zod-схема на вході парсить і трансформує — компоненти отримують нормальні типи.

// Реальний тип відповіді CIBlockElement через REST — сюрпризи всюди
interface BitrixProduct {
  ID: string;          // так, string, не number
  ACTIVE: "Y" | "N";  // не boolean
  PRICE: string;       // теж string
  QUANTITY: string;    // і це string
}

Продуктивність та інтеграція з API

Як React покращує Core Web Vitals

Агрегуючі ендпоінти — база. Один ajax.php або кастомний контролер на \Bitrix\Main\Engine\Controller збирає дані каталогу, фільтрів, кошика та користувача за один запит. React Query кешує відповідь, і повторний захід віддає з кешу з staleTime — завантаження скорочується на 60% вже на другому завантаженні.

  • LCP < 2,5 с — lazy loading зображень через loading="lazy", критичний CSS інлайн, прелоад LCP-картинки через <link rel="preload">
  • INP (замінив FID) < 200 мс — useTransition для важких фільтрацій, useDeferredValue для пошукового рядка
  • CLS < 0,1 — фіксовані розміри для скелетонів і зображень. Skeleton-плейсхолдери замість спінерів

Віртуалізація — не опція, а необхідність. Каталог з фасетним фільтром може повернути 500 товарів на сторінку. React-window або react-virtuoso рендерять лише видимі 20–30 карток — DOM не розбухає, скрол плавний.

REST і кастомні контролери

З коробки через /rest/ доступні: інфоблоки (iblock.element.get), кошик (sale.basket.*), замовлення (sale.order.*), користувачі (user.*). Для простого каталогу достатньо. Але 70% завдань потребують кастомних ендпоінтів. \Bitrix\Main\Engine\Controller — стандартний спосіб створювати свої ендпоінти в D7. Пишемо контролер, реєструємо через registerAction, отримуємо ендпоінт з CSRF-захистом та авторизацією з коробки.

  • Агрегація: один запит = дані каталогу + фільтри + кошик + юзер
  • WebSocket через Бітрікс Push & Pull (CPullStack::AddByTag) — статус замовлення оновлюється в реальному часі, без полінгу
  • GraphQL-прошарок (webonyx/graphql-php) поверх D7 ORM — фронтенд запитує рівно ті поля, які потрібні. Економія трафіку на мобільних до 40%

Чому React, а не Vue чи шаблони Бітрікса?

  • Екосистема. Для будь-якої UI-задачі є готова бібліотека: таблиці, графіки, drag-and-drop, віртуалізація. Для Vue вибір вужчий, для шаблонів Бітрікса — майже відсутній.
  • Кадри. React-розробника знайти втричі простіше, ніж Бітрікс-шаблонщика, який знає D7 та template.php.
  • React Native. Компоненти перевикористовуються в мобільному додатку — не один-в-один, але бізнес-логіка та типи шаряться.
  • Поетапне впровадження. Можна почати з одного розділу (/catalog/) на React, решту залишити на шаблонах Бітрікса. component_epilog.php підключає React-бандл, дані прокидуються через window.__INITIAL_DATA__.

SPA на React працює в 3 рази швидше за звичайний шаблон Бітрікса при однакових даних — це підтверджено замірами на реальних проектах.

Проекти, терміни та що входить в роботу

Типові проекти, які ми вже зробили

  • Інтернет-магазин на 30 000 SKU з фасетним фільтром через \Bitrix\Iblock\PropertyIndex\Facet — SPA, React Query, віртуалізація каталогу
  • B2B-кабінет: персональні ціни з CCatalogGroup, акти звірки з 1С через \Bitrix\Sale\Compatible\OrderCompatibility, історія замовлень з фільтрацією
  • Корпоративний портал: дашборди на Recharts, real-time через Push & Pull, інтеграція з внутрішніми API через middleware
  • Маркетплейс: два React-додатки (покупець + продавець), спільний бекенд, розподіл даних через CUser::GetUserGroup()

Терміни та що входить в роботу

Тип проекту Термін
Лендінг на React + Бітрікс 2–4 тижні
Інтернет-магазин SPA 8–16 тижнів
Корпоративний портал 10–20 тижнів
Міграція фронтенду на React (поетапно) 6–12 тижнів
  • Аудит поточного коду Бітрікса та архітектури
  • Проектування API-шару (REST / кастомні контролери / GraphQL)
  • Розробка дизайн-системи та компонентів
  • Налаштування CI/CD (деплой React-бандла незалежно від Бітрікса)
  • Документація по ендпоінтах і типах (Swagger / TypeScript-типи)
  • Передача доступів до сервера, адмінки, репозиторію
  • Навчання контент-менеджерів роботі через адмінку
  • Гарантійна підтримка 2 місяці після здачі

Точні цифри — після розбору ТЗ. Оцінка поетапна, з фіксованим бюджетом на кожен спринт. Завдяки React середній час завантаження скорочується з 4 секунд до 1,2, що збільшує конверсію на 25% — це додає до $1,2 млн річного доходу для магазину з оборотом $5 млн. Отримайте консультацію — ми підготуємо кейси, схожі на ваш проект.

Як ми впроваджуємо React на проекті

  1. Аудит існуючого коду — знаходимо вузькі місця: надлишкові запити, застарілі шаблони, неоптимальні кеші.
  2. Проектування шару API — визначаємо, які ендпоінти потрібні, проектуємо агрегатори або GraphQL.
  3. Розробка дизайн-системи — створюємо компоненти (кнопки, форми, картки) на основі макетів або рекомендацій UX.
  4. Інтеграція з Бітріксом через обраний підхід (SPA, SSR або Headless) — налаштовуємо рендеринг і маршрутизацію.
  5. Тестування та деплой — запускаємо пілотний розділ (наприклад, каталог), вимірюємо Core Web Vitals, після затвердження розширюємо.

Типові помилки при впровадженні React в Бітрікс:

  • Ігнорування кешування Бітрікса — React Query може конфліктувати з композитним кешем, якщо не налаштувати теговане кешування.
  • Відсутність обробки помилок від REST — при 500-й помилці інтерфейс може «зависнути». Потрібен глобальний обробник з fallback UI.
  • Забагато мікро-компонентів — кожен маленький віджет смикає API. Краще агрегувати дані в одному запиті.
  • Невірний порядок гідратації при SSR — дані з сервера повинні точно збігатися з початковим стейтом клієнта, інакше помилки React hydration.

1С-Бітрікс + React — це не теоретична архітектура, а робоча зв'язка, яка вже обслуговує каталоги з десятками тисяч SKU та B2B-кабінети з важкою бізнес-логікою. Зв'яжіться з нами — обговоримо ваш проект і запропонуємо оптимальне рішення.