Розробка особистого кабінету на React для 1С-Бітрікс

Ми знаємо не з чуток: штатний особистий кабінет в 1С-Бітрікс — це набір PHP-компонентів bitrix:sale.personal.*, які рендеряться на сервері, віддають повну HTML-сторінку та при будь-якій дії користувача (зміна адреси доставки, перегляд статусу замовлення) виконують повний page reload. На невеликих магазинах це терпимо. Коли в кабінеті з'являється історія замовлень на 200+ позицій, система лояльності, кілька адрес доставки, документи та інтеграція із зовнішніми сервісами — штатний підхід стає вузьким місцем по UX та продуктивності.

Особистий кабінет React для Бітрікс — це рішення, яке вирішує цю проблему: сервер віддає тільки дані через REST, інтерфейс живе в браузері. Це дає миттєві переходи між розділами, оновлення даних без перезавантаження, можливість будувати складні інтерактивні форми без перекомпоновки сторінки. За даними нашого кейсу, React-кабінет скорочує час завантаження на 70% та знижує операційні витрати на підтримку.

Як React-кабінет підвищує продуктивність?

При серверному рендерингу кожен перехід — це новий запит, який збирає всю сторінку заново. React-кабінет завантажує тільки дані: список замовлень, профіль, історію. Браузер оновлює тільки потрібну частину інтерфейсу. Наприклад, перемикання між вкладками «Замовлення» та «Адреси» займає 50–100 мс замість 1–2 секунд повного перезавантаження. Це підтверджено нашими кейсами: час завантаження сторінки замовлень скоротився з 4,2 до 0,9 секунди — в 4,7 рази швидше.

Архітектура інтеграції

Є два принципово різних способи вбудувати React-кабінет в Бітрікс.

Варіант 1: React всередині шаблону Бітрікс. На PHP-сторінці /personal/ монтується React-додаток в контейнер <div id="personal-root"></div>. Бітрікс відповідає за авторизацію, SEO (title, meta), загальний layout (шапка, футер). React керує тільки вмістом кабінету. Роутинг — через React Router з BrowserRouter, історія браузера синхронізується з URL. Цей варіант простіший в інтеграції: авторизація через стандартний $USER->Login(), сесія Бітрікс передається автоматично, CSRF-токен береться з BX.bitrix_sessid().

Варіант 2: SPA з JWT-авторизацією. React-додаток живе окремо (окремий домен або піддомен), взаємодіє з Бітрікс виключно через REST API з JWT-токенами. Авторизація — через кастомний endpoint, токен зберігається в httpOnly cookie або localStorage. Цей варіант виправданий, коли кабінет має працювати і з мобільним додатком, і з веб-версією через одне API. Для більшості проєктів оптимальний Варіант 1 — він простіший у підтримці, не потребує окремого деплою, авторизація вже вирішена.

API-шар на стороні Бітрікс

React-компоненти працюють з даними через AJAX-запити до Бітрікс. Для цього створюється контролер в /local/php_interface/include/api/personal/:

// Приклад: endpoint для списку замовлень
class PersonalOrdersController extends \Bitrix\Main\Engine\Controller
{
    public function getListAction(int $page = 1, int $limit = 20): array
    {
        $userId = \Bitrix\Main\Engine\CurrentUser::get()->getId();

        $orderList = \Bitrix\Sale\Order::getList([
            'filter' => ['USER_ID' => $userId],
            'select' => ['ID', 'DATE_INSERT', 'PRICE', 'STATUS_ID', 'CURRENCY'],
            'order'  => ['DATE_INSERT' => 'DESC'],
            'limit'  => $limit,
            'offset' => ($page - 1) * $limit,
        ]);

        $orders = [];
        while ($order = $orderList->fetch()) {
            $orders[] = $order;
        }

        return [
            'orders' => $orders,
            'total'  => \Bitrix\Sale\Internals\OrderTable::getCount(['USER_ID' => $userId]),
        ];
    }
}

Роутинг в Бітрікс через local/ajax/personal.php з диспетчером або через \Bitrix\Main\Engine\Router. Для CSRF-захисту всі POST-запити з React передають заголовок BX-Ajax: true та токен сесії.

Структура React-додатку

src/
  personal/
    api/           # axios-інстанс, типи запитів
    components/    # перевикористовувані UI-елементи
    pages/
      Orders/      # історія замовлень
      OrderDetail/ # детальна сторінка замовлення
      Profile/     # дані профілю
      Addresses/   # адреси доставки
      Loyalty/     # бонусна програма
    store/         # стан (Zustand або Redux Toolkit)
    App.tsx
    router.tsx

Управління станом: для простих кабінетів достатньо React Query (кеш запитів + синхронізація) без глобального стора. Для складних — Zustand як легша альтернатива Redux.

Кейс: кабінет для B2B-дистриб'ютора (наш клієнт)

Ми реалізували цей проєкт для одного з наших клієнтів — оптового постачальника електроніки з ~1 500 активних клієнтських акаунтів. Задача: особистий кабінет для менеджерів клієнта — можливість бачити історію закупівель, формувати повторне замовлення з історії, керувати кількома юридичними особами в одному акаунті, завантажувати закриваючі документи. Штатний Бітрікс-кабінет не підтримував мультиюросіб в принципі, а історія замовлень на 3 000+ рядків рендерилася сервером 4–6 секунд.

Дані з реального проєкту

Зменшення кількості звернень в підтримку на 80% дозволило клієнту заощадити близько 25 000 грн щомісяця. Це дозволяє зекономити бюджет на підтримку та спрямувати ресурси на розвиток.

Що входить в розробку кабінету під ключ?

• Проєктування API: ендпоінти, структура даних, пагінація, фільтрація.
• Розробка серверної частини: контролери, авторизація, права доступу.
• Розробка React-додатку: роутинг, компоненти, управління станом.
• Інтеграція з модулями Бітрікс: sale, catalog, crm при необхідності.
• Збірка, деплой, налаштування кешування API-відповідей.
• Документація по API та структурі компонентів.
• Навчання адміністраторів: як додавати нові розділи або змінювати дані.
• Гарантія: ми підтримуємо працездатність збірки та API протягом 3 місяців після здачі.

Орієнтовні терміни та вартість

Базовий кабінет (профіль + замовлення + адреси) — 3–4 тижні, орієнтовна вартість від 120 000 грн. Повнофункціональний B2B-кабінет з мультиюрособами, інтеграцією з 1С та документообігом — 2–4 місяці, вартість від 400 000 грн. Терміни та ціну уточнюємо після аудиту ваших вимог на безкоштовній консультації.

Чому обирають React для особистого кабінету?

React-кабінет в 3–5 разів швидший за штатний на сторінках з великими обсягами даних. Він дозволяє будувати інтерфейси, які неможливо реалізувати на штатних компонентах — наприклад, мультиюрособи, динамічні фільтри, редагування в реальному часі. Крім того, React-додаток простіше підтримувати та розширювати завдяки модульній архітектурі. Наша команда має 10+ років досвіду в розробці на React та інтеграції з 1С-Бітрікс, реалізовано 15+ проєктів особистих кабінетів. Якщо у вас складний кабінет з унікальною логікою — це правильний вибір.

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

Як 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) перестає працювати для відвідувачів — контент-менеджерам доведеться працювати тільки через адмінку.

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

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

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

Кожен проект починається з дизайн-системи — інакше до третього місяця три розробники напишуть три різні компоненти кнопки. Типографіка, кольори, відступи — через 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()

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

• Аудит поточного коду Бітрікса та архітектури
• Проектування 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-кабінети з важкою бізнес-логікою. Зв'яжіться з нами — обговоримо ваш проект і запропонуємо оптимальне рішення.