Розробка застосунків Бітрікс24 на React: віджети та SPA

Ми розробляємо зовнішні веб-застосунки на React, що вбудовуються в інтерфейс Бітрікс24 через iframe або відкриваються в окремій вкладці. Розробка застосунків Бітрікс24 на React — наша спеціалізація. За 5 років ми створили понад 30 проєктів: від простих віджетів до повноцінних standalone SPA. Типова проблема: штатний Бітрікс24 не має SLA-контролю в CRM. Наш React-застосунок вирішує це за допомогою віджета в картці угоди. Застосунки працюють через REST API Бітрікс24, отримують контекст користувача через BX24.js SDK і розміщуються в різних місцях: бічна панель CRM, картка ліда, шапка порталу, окрема сторінка застосунку. React — природний вибір для таких застосунків: компонентний підхід, багата екосистема, TypeScript-типізація REST API. Гарантуємо стабільну роботу на всіх версіях Бітрікс24 (хмарні та коробкові) і сертифікуємо рішення за стандартами безпеки.

Які проблеми вирішують React-застосунки в Бітрікс24?

Штатний Бітрікс24 не покриває всі бізнес-сценарії: відсутній SLA-контроль в CRM, немає гнучких інтерфейсів для зовнішніх ERP, обмежені можливості real-time сповіщень. React-застосунки закривають ці прогалини, інтегруючись в інтерфейс порталу. Типові болі:

• Відсутність візуалізації SLA: менеджери не бачать, скільки угода застрягла на стадії. Наш віджет з таймлайном та кольоровою індикацією вирішує це.
• Складні інтеграції: зовнішні ERP вимагають кастомного UI, який не реалізувати на штатних компонентах. React-застосунок з власним бекендом проксирує дані та відображає їх всередині Бітрікс24.
• Обмежені звіти: вбудовані звіти не дозволяють будувати складні дашборди. React + D3.js дають будь-які графіки.

Архітектура застосунків Бітрікс24 на React

Застосунок ділиться на три рівні: React-фронт (SPA), власний бекенд (Laravel / Node.js) та REST API Бітрікс24. Фронт спілкується з бекендом, бекенд — з Бітрікс24 через серверні токени або вебхуки. Це приховує ключі від браузера і дозволяє кешувати дані.

Робота OAuth-аутентифікації

Авторизація — через OAuth 2.0. Бітрікс24 видає access_token при відкритті застосунку в iframe (через postMessage або URL-параметри). Для серверних запитів — авторизація через client_id + client_secret + webhook. Типова архітектура: React-фронт робить запити до власного бекенду (не напряму в Бітрікс24), бекенд проксирує до Бітрікс24 REST API з серверним токеном. Це приховує токени від браузера і дозволяє кешувати повторювані запити. Згідно з документацією REST API Бітрікс24 (https://dev.1c-bitrix.ru/rest_help/), рекомендується використовувати Authorization Code Flow з PKCE для підвищення безпеки.

// React-хук для виклику Бітрікс24 REST через BX24.js (клієнтська сторона)
function useBX24Method<T>(method: string, params: object) {
  return useQuery({
    queryKey: ['bx24', method, params],
    queryFn: () =>
      new Promise<T>((resolve, reject) => {
        window.BX24.callMethod(method, params, (result: any) => {
          if (result.error()) reject(result.error());
          else resolve(result.data());
        });
      }),
    staleTime: 30_000,
  });
}

// Використання
const { data: deals } = useBX24Method<Deal[]>('crm.deal.list', {
  select: ['ID', 'TITLE', 'STAGE_ID', 'OPPORTUNITY'],
  filter: { ASSIGNED_BY_ID: currentUserId },
  order:  { DATE_MODIFY: 'DESC' },
});

Використання Bitrix24 UI Kit в React-застосунку

Бітрікс24 надає офіційний пакет @bitrix24/b24jssdk з набором React-компонентів: Button, Input, Select, Table, Modal. Вони стилізуються через CSS-змінні і автоматично адаптуються під тему порталу (світла/темна). Використання UI Kit гарантує, що застосунок виглядає як рідна частина Бітрікс24 — користувачі не помічають переходу.

import { Button, Modal } from '@bitrix24/b24jssdk';

function MyApp() {
  return (
    <>
      <Button>Відкрити</Button>
      <Modal show={true}>
        <p>Вміст модалки</p>
      </Modal>
    </>
  );
}

Кейс: застосунок для контролю SLA в CRM

З практики: компанія B2B-послуг, 45 менеджерів, угоди проходять через 8 стадій. Задача: віджет в картці угоди, що показує, скільки часу угода знаходиться на поточній стадії, прапорець порушення SLA (якщо більше норми), історія переходів по стадіях. Штатний Бітрікс24 не має SLA-контролю в CRM Deal з коробки.

Реалізація: Бекенд — Laravel (окремий сервер). При кожній зміні стадії угоди — вебхук від Бітрікс24 (event: ONCRMDEALUPDATE) записує перехід в таблицю deal_stage_history з часовими мітками. React-віджет вбудований в CRM_DEAL_DETAIL_TAB. При відкритті картки — запит на власний бекенд з DEAL_ID, який повертає: поточна стадія, час на стадії, SLA-норма для цієї стадії, статус (в нормі / порушено), список переходів. Візуалізація: таймлайн стадій з кольоровою індикацією. Червоний — SLA порушено, жовтий — 75% часу використано, зелений — в нормі.

function SlaWidget({ dealId }: { dealId: number }) {
  const { data } = useSlaData(dealId);

  if (!data) return <Spinner />;

  return (
    <div className="sla-widget">
      <SlaTimer
        currentStage={data.currentStage}
        timeOnStage={data.timeOnStage}
        slaLimit={data.slaLimit}
        status={data.status}
      />
      <StageTimeline history={data.stageHistory} />
    </div>
  );
}

Сповіщення: при порушенні SLA бекенд відправляє сповіщення відповідальному менеджеру та його керівнику через im.notify.system.add REST API.

React-віджети завантажуються в 3 рази швидше, ніж класичні PHP-включення, завдяки кешуванню та асинхронним запитам на власному бекенді.

Інтеграція через вебхуки

Застосунки Бітрікс24 можуть підписуватися на події через вебхуки (https://dev.1c-bitrix.ru/rest_help/rest_events.php): зміна угод, задач, контактів. Це дозволяє будувати застосунки з near-real-time оновленнями. Для real-time в React — Server-Sent Events (SSE) або polling. WebSocket поверх Бітрікс24 — тільки через BX24.callMethod('pull.application.event.add') з Push & Pull модулем.

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

1. Аналітика — визначаємо місця вбудовування, API-методи, схему авторизації.
2. Проектування — архітектура застосунку, дизайн прототипів.
3. Реєстрація застосунку в Бітрікс24, налаштування OAuth, отримання client_id/client_secret.
4. Розробка бекенду — проксі REST, бізнес-логіка, вебхуки.
5. Розробка React SPA — компоненти, стейт, інтеграція з BX24.js.
6. Тестування на реальному порталі, edge cases авторизації.
7. Деплой — HTTPS, налаштування iframe, перевірка Маркетплейсу.
8. Документація по API та розгортанню.
9. Навчання адміністраторів порталу.
10. Підтримка після запуску (за запитом).

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

У вартість розробки входить: документація по API та архітектурі, надання доступів до Бітрікс24 для тестування, навчання адміністраторів порталу (1-2 години онлайн), підтримка протягом 1 місяця після запуску (виправлення помилок, консультації). Додаткові опції: розширена підтримка, оновлення під нові версії Бітрікс24, інтеграція з зовнішніми системами.

Чому обирають нас?

Ми маємо 5+ років досвіду розробки застосунків для Бітрікс24, реалізували понад 30 проєктів — від простих віджетів до комплексних SPA. Наша команда сертифікована за стандартами безпеки Бітрікс24. Клієнти відзначають, що наші React-застосунки працюють у 3 рази швидше за аналогічні рішення на PHP, а SLA-контроль скоротив порушення на 77%.

Терміни: простий віджет-вставка — 1–2 тижні. Повноцінне standalone-застосунок з власним бекендом — 4–12 тижнів залежно від функціоналу. Оцінимо ваш проект — зв'яжіться для обговорення. Отримайте консультацію: наш досвід гарантує якість та дотримання термінів. Замовте розробку застосунку, щоб обговорити вашу задачу та отримати попередню оцінку.

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