Розробка оформлення замовлення на React для 1С-Бітрікс

Кожне незавершене замовлення — втрачені гроші. Стандартний bitrix:sale.order.ajax на jQuery повільно відображає блоки: оновлення поля займає 1–2 секунди, а при 10 000+ товарах — до 3 секунд. Користувач іде, конверсія падає. Налаштувати багатокрокову форму, B2B-реквізити або вибір дати доставки на цьому компоненті практично неможливо — код перетворюється на локшину з PHP-вставок і JavaScript.

Ми пропонуємо заміну sale.order.ajax на React-чекаут Бітрікс. Наші інженери — сертифіковані розробники Бітрікс з 10+ роками досвіду. Після впровадження в одного з клієнтів конверсія зросла з 62% до 79% за 6 тижнів. Середній бюджет проєкту — 150 000–400 000 ₽, окупність настає через 4–5 місяців. Ми також гарантуємо якість коду та підтримку після здачі проєкту. Наш досвід — понад 50 успішних проєктів. Якщо ви хочете таких же результатів, зв'яжіться з нами — оцінимо ваш проєкт.

Чому React-чекаут швидший і гнучкіший за стандартний компонент?

React-чекаут вирішує проблему на рівні архітектури: UI в компонентах, логіка в хуках, спілкування з сервером через API. Зміна доставки обробляється за 200 мс, штатний компонент витрачає більше секунди — це в 5 разів швидше. Валідація полів виконується миттєво при втраті фокусу — користувач одразу бачить помилку, а не після натискання кнопки.

Як влаштована архітектура React-чекаута?

Оформлення замовлення ділиться на два незалежні рівні: UI-рівень (React) і бізнес-логіка (Бітрікс на сервері). На фронті — React-застосунок, який керує формою, показує/ховає кроки, розраховує підсумок у реальному часі. На сервері — Бітрікс обробляє замовлення через \Bitrix\Sale\Order, застосовує знижки, розраховує вартість доставки, перевіряє залишки. Докладніше про систему замовлень — у документації Bitrix Sale.

Ключовий API-метод для розрахунку замовлення без його створення:

// Расчёт итогов без сохранения заказа
$order = \Bitrix\Sale\Order::create(SITE_ID, $userId);
$basket = \Bitrix\Sale\Basket::loadSiteBasket(SITE_ID);
$order->setBasket($basket);

// Применяем параметры доставки
$shipment = $order->getShipmentCollection()->createItem(
    \Bitrix\Sale\Delivery\Services\Manager::getById($deliveryId)
);
$shipment->setFields(['DELIVERY_ID' => $deliveryId, 'CURRENCY' => 'RUB']);
$shipment->calculateDelivery();

// Применяем купон
$order->getDiscountSystem()->calculate();

// Возвращаем итог без сохранения (без вызова $order->save())
return [
    'subtotal'       => $basket->getPrice(),
    'delivery_price' => $shipment->getPrice(),
    'discount'       => $order->getDiscountPrice(),
    'total'          => $order->getPrice(),
];

Цей endpoint викликається при кожній зміні полів: вибір служби доставки, введення промокоду, зміна кількості. React отримує актуальні цифри без перезавантаження.

Як інтегрувати React-чекаут з Бітрікс?

Для складного чекаута (3+ кроки з валідацією) оптимальна бібліотека React Hook Form з Zod-схемами валідації:

const checkoutSchema = z.object({
  contact: z.object({
    name:  z.string().min(2, 'Укажите имя'),
    phone: z.string().regex(/^\+7\d{10}$/, 'Неверный формат'),
    email: z.string().email('Неверный email'),
  }),
  delivery: z.object({
    type:       z.enum(['courier', 'pickup', 'cdek']),
    address:    z.string().optional(),
    pickupId:   z.number().optional(),
  }),
  payment: z.object({
    method: z.enum(['online', 'cash', 'invoice']),
  }),
});

Стейт чекауту зберігається в Zustand: кроки, поточний крок, дані кожного кроку, результат розрахунку. При переході між кроками дані не губляться, користувач може повернутися назад.

Ми використовуємо React Hook Form для валідації, Zustand для стану та React Query для запитів.

Інтеграція з картами для кур'єрської доставки

Яндекс.Карти або DaData для автодоповнення адреси — стандартне завдання для React-чекаута.

// Хук для автодоповнення адреси через DaData
function useAddressSuggest(query: string) {
  return useQuery({
    queryKey: ['address-suggest', query],
    queryFn:  () => fetchDaDataSuggestions(query),
    enabled:  query.length > 3,
    staleTime: 60_000,
  });
}

При виборі адреси через DaData структуровані дані (місто, вулиця, індекс) передаються в Бітрікс окремими полями — це спрощує подальшу обробку замовлення та передачу у служби доставки.

Кейс: чекаут для меблевого рітейлера

Наш клієнт — інтернет-магазин меблів з 2000+ SKU. Специфіка: товари з різними термінами виготовлення (від 3 до 40 днів), можливість замовити доставку на конкретну дату, обов'язковий замір для ряду товарів, B2B-оформлення з реквізитами. Штатний sale.order.ajax не підтримував ні вибір дати доставки, ні умовне відображення блоку заміру, ні реквізити компанії в одному потоці.

Реалізація:

1. Крок 1 — контакти. Форма з телефоном та ім'ям. Телефон валідується через libphonenumber-js, підказка через SMS-верифікацію (опціонально).

2. Крок 2 — доставка. Динамічне відображення: якщо в замовленні є товари із заміром — з'являється блок «Запис на замір» з datepicker. Доступні дати завантажуються з сервера (з CRM Бітрікс, зайняті слоти закриті). Вибір дати доставки з урахуванням терміну виготовлення — мінімальна дата розраховується на сервері за max(PRODUCTION_DAYS) у корзині.

3. Крок 3 — оплата. Перемикач «Фізична особа / Юридична особа». При виборі юрособи розгортається блок реквізитів (ІПН → автозаповнення через DaData → підтягування КПП, назви, адреси). Безготівковий рахунок для B2B генерується автоматично після створення замовлення через \Bitrix\Sale\PaySystem\Manager.

4. Створення замовлення. Фінальний POST відправляє всі дані на сервер. Bitrix створює замовлення, прив'язує кастомні властивості (дата доставки, тип клієнта, реквізити), відправляє сповіщення. React отримує ID замовлення та переводить користувача на сторінку «Дякуємо».

Конверсія чекауту зросла з 62% до 79% за перші 6 тижнів після запуску. Середній час оформлення скоротився з 5 хвилин до 2 хвилин, а економія на розробці при повторному впровадженні досягає 40%.

Створення замовлення на сервері

public function createOrderAction(array $data): array
{
    $order = \Bitrix\Sale\Order::create(SITE_ID, $this->getCurrentUserId());
    $basket = \Bitrix\Sale\Basket::loadSiteBasket(SITE_ID);
    $order->setBasket($basket);

    // Контакт
    $order->setField('USER_DESCRIPTION', $data['comment'] ?? '');

    // Доставка
    $shipmentCollection = $order->getShipmentCollection();
    $shipment = $shipmentCollection->createItem(
        \Bitrix\Sale\Delivery\Services\Manager::getById($data['delivery_id'])
    );
    $shipment->setField('DELIVERY_ID', $data['delivery_id']);

    // Оплата
    $paymentCollection = $order->getPaymentCollection();
    $payment = $paymentCollection->createItem(
        \Bitrix\Sale\PaySystem\Manager::getObjectById($data['payment_id'])
    );
    $payment->setField('PAY_SYSTEM_ID', $data['payment_id']);
    $payment->setField('SUM', $order->getPrice());

    // Свойства заказа (адрес, телефон, ИНН и т.д.)
    $propertyCollection = $order->getPropertyCollection();
    foreach ($data['properties'] as $code => $value) {
        $prop = $propertyCollection->getItemByOrderPropertyCode($code);
        if ($prop) {
            $prop->setValue($value);
        }
    }

    $result = $order->save();
    if (!$result->isSuccess()) {
        throw new \Exception(implode(', ', $result->getErrorMessages()));
    }

    return ['order_id' => $order->getId()];
}

Обробка помилок та edge cases

Недостатній залишок товару при оформленні — обробляється на фінальному кроці збереження. React показує модальне вікно з переліком недоступних позицій, пропонує видалити їх або зберегти замовлення без них.

Втрата з'єднання під час оформлення — React Query з retry: 3 та повідомленням користувачеві. Дані форми зберігаються в sessionStorage і відновлюються при перезавантаженні.

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

• Проєктування кроків чекауту, умовної логіки, валідації
• Розробка API-контролерів: розрахунок замовлення, створення, отримання служб доставки та ПВЗ
• Створення React-застосунку: форма, стейт-менеджер, інтеграція з картами/DaData
• Прив'язка кастомних властивостей замовлення, налаштування платіжних систем
• Тестування edge cases: пуста корзина, нестача залишку, тайм-аут сесії
• Документація з 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-кабінети з важкою бізнес-логікою. Зв'яжіться з нами — обговоримо ваш проект і запропонуємо оптимальне рішення.