Разработка кастомной корзины 1С-Битрикс
Стандартный компонент bitrix:sale.basket.basket закрывает базовые задачи, но ломается под нестандартные требования бизнеса: нет сохранения корзины между сессиями без авторизации, невозможно добавить кастомные поля к позиции (например, гравировку или цвет упаковки), а вёрстка компонента — это сложный шаблон с устаревшей структурой. В таких случаях корзину разрабатывают с нуля либо глубоко переделывают стандартный компонент.
Как устроена корзина в Битрикс
Корзина хранится в таблице b_sale_basket. Каждая позиция — строка с полями: FUSER_ID (идентификатор анонимного пользователя из сессии), PRODUCT_ID, QUANTITY, PRICE, CUSTOM_PRICE (флаг ручной цены), NOTES, PRODUCT_XML_ID и набор полей PROPS — это сериализованные свойства позиции из b_sale_basket_props.
Работа с корзиной через API:
// Добавление товара
$basket = \Bitrix\Sale\Basket::loadItemsForFUser(
\Bitrix\Sale\Fuser::getId(),
\Bitrix\Main\Context::getCurrent()->getSite()
);
$item = $basket->createItem('catalog', $productId);
$item->setFields([
'QUANTITY' => 2,
'CURRENCY' => 'RUB',
'LID' => 's1',
'PRODUCT_PROVIDER_CLASS' => '\Bitrix\Catalog\Product\CatalogProvider',
]);
$basket->save();
Для AJAX-операций с корзиной (добавить, изменить количество, удалить) используется контроллер \Bitrix\Sale\Compatible\DiscountCompatibility или собственный Ajax-обработчик через \Bitrix\Main\Engine\Controller.
Что реально требует кастомной разработки
Кастомные свойства позиции. Стандартная корзина не позволяет добавить произвольные поля к позиции — например, текст для гравировки, выбранный размер упаковки или дату доставки конкретного товара. Под капотом это таблица b_sale_basket_props с полями NAME, VALUE, CODE. Для кастомных свойств нужно:
- Добавить UI в шаблон страницы товара (модальное окно, поля формы)
- При добавлении в корзину передать свойства в AJAX-запросе
- В обработчике добавить их через
$item->getPropertyCollection()->createItem() - Отобразить в шаблоне корзины
Сохранение корзины без авторизации. По умолчанию FUSER_ID — это сессионный ID, и при смене браузера или устройства корзина пропадает. Для сохранения нужно хранить FUSER_ID в cookie с длинным TTL (30–90 дней) и при первом посещении создавать запись в b_sale_fuser, привязанную к этой cookie. При авторизации — слияние анонимной корзины с корзиной пользователя через \Bitrix\Sale\Basket::mergeBasket.
Мини-корзина в хедере с AJAX-обновлением. Стандартный компонент bitrix:sale.basket.small при каждом запросе дёргает БД. На высоконагруженных магазинах это заметно: 200 RPS × N запросов к b_sale_basket. Решение — хранить счётчик корзины в Redis (через \Bitrix\Main\Data\Cache с тегированием) и обновлять только при изменениях, а не при каждом рендере страницы.
Мультивалютная корзина. При продаже в нескольких валютах необходимо корректно пересчитывать цены через CCurrencyRates::ConvertCurrency и хранить как исходную цену в валюте, так и эквивалент в базовой. Стандартный компонент это делает, но без возможности показать «цену в вашей валюте» рядом с ценой в USD.
Кейс: корзина с конфигуратором для строительного магазина
Клиент — интернет-магазин строительных материалов. Проблема: покупатель выбирает плитку, и ему нужно указать площадь укладки, процент боя и способ укладки (прямо/диагональ). Итоговое количество пачек и цена должны рассчитываться на лету прямо в корзине.
Решение: разработан компонент корзины на Vue.js, который общается с бекендом через REST API (собственный контроллер). Конфигуратор — отдельный компонент, встроенный в строку позиции корзины. Данные конфигурации хранятся в b_sale_basket_props с кодами AREA, BREAKAGE_PCT, LAYOUT_TYPE. При изменении параметров — пересчёт через AJAX без перезагрузки страницы. Сложность: цены в каталоге хранятся за единицу, а закупка идёт пачками — пришлось реализовать конвертацию в обоих направлениях.
Результат: конверсия корзины выросла, потому что клиент видит финальную сумму ещё до оформления заказа, а не получает уточнение по телефону.
Архитектурные решения при разработке
Выбор подхода зависит от требований:
| Подход | Когда применять | Трудоёмкость |
|---|---|---|
| Кастомный шаблон компонента | Только визуальные изменения | 1–2 дня |
| Переопределение компонента | Изменение логики без сторонних данных | 3–5 дней |
| Собственный компонент + REST API | Сложная логика, Vue/React-фронтенд | 2–4 недели |
| Headless (Next.js + Битрикс API) | Полный контроль над фронтом | от 4 недель |
При разработке кастомной корзины обязательно учитываем:
- Сохранение совместимости с модулем
sale— скидки, купоны, правила корзины должны продолжать работать - Корректный пересчёт при изменении количества через
OnSaleBasketBeforeSaved - Валидацию на сервере: нельзя доверять цене, пришедшей с клиента
- Обработку ситуации «товар закончился, пока лежал в корзине»
Сроки и этапы
Разработка кастомной корзины от анализа до сдачи занимает от 5 рабочих дней до 6 недель в зависимости от сложности:
- Аудит текущей корзины и ТЗ — 1–2 дня
- Разработка серверной части (API, обработчики событий) — 3–10 дней
- Разработка фронтенда — 2–15 дней
- Интеграция с модулями
sale,catalog,currency— 1–5 дней - Тестирование (юнит, интеграционное, нагрузочное) — 1–3 дня