Разработка конфигуратора товаров (Product Configurator)
Конфигуратор — это интерфейс, в котором покупатель собирает товар под себя: выбирает комплектацию, цвет, размер, дополнительные опции, и видит результат в реальном времени. Технически это сложнее обычной карточки товара: нужно управлять зависимостями между опциями, пересчитывать цену, обновлять визуал и проверять доступность на складе — всё синхронно.
Типы конфигураторов
Перед проектированием важно определить класс задачи:
Вариантный конфигуратор — конечный набор комбинаций. Пример: футболка (3 цвета × 5 размеров = 15 SKU). Каждая комбинация — отдельный вариант в БД. Проще в реализации, но не масштабируется при сотнях атрибутов.
Параметрический конфигуратор — пользователь задаёт параметры, цена и характеристики вычисляются по формулам. Пример: окна, мебель на заказ, металлоконструкции. Здесь комбинаций может быть миллионы, хранить их все бессмысленно.
CPQ-конфигуратор (Configure–Price–Quote) — B2B сценарий: сложные правила совместимости, индивидуальные цены, выгрузка в коммерческое предложение. Требует интеграции с CRM и ERP.
Модель данных
Для параметрического конфигуратора:
configurator_options (id, product_id, name, type, required, sort_order)
-- type: select | radio | checkbox | range | text
option_values (id, option_id, label, value, price_delta, image_url, in_stock)
option_dependencies (id, if_option_id, if_value, then_option_id, action)
-- action: show | hide | require | disable | set_value
price_rules (id, product_id, conditions JSONB, price_formula)
Зависимости между опциями — ключевая часть. Пример: выбрали «Тип корпуса = Алюминий» → опция «Цвет» показывает только 4 из 12 цветов, а опция «Гравировка» становится обязательной. Это дерево условий, которое вычисляется на клиенте при каждом изменении.
Логика на клиенте
Конфигуратор — это по сути реактивный state machine. На каждое изменение опции:
- Обновляем состояние выбора
- Вычисляем активные зависимости (какие опции скрыть/показать/заблокировать)
- Пересчитываем цену
- Обновляем визуализацию (если есть)
- Проверяем наличие (запрос к API или по локальному кешу)
Реализация на React + Zustand:
const useConfigurator = create((set, get) => ({
selections: {},
select: (optionId, value) => {
const next = { ...get().selections, [optionId]: value };
set({
selections: next,
visibleOptions: computeVisibility(next, rules),
price: computePrice(next, basePrice, pricingRules),
});
},
}));
Правила зависимостей загружаются один раз при монтировании конфигуратора и кешируются локально. Запросы к серверу — только для проверки актуального наличия при добавлении в корзину.
Визуализация
Уровни визуализации по сложности:
Смена изображения — самый простой вариант: для каждой комбинации опций заготовлен набор изображений. При выборе опции меняем src. Подходит для одежды, простой мебели.
Layered композиция — изображение собирается из слоёв (PNG с прозрачностью). Каждая опция добавляет/убирает слой. Реализация через Canvas API или CSS-наложение. Пример: конфигуратор велосипеда — рама, колёса, руль, цвет — каждый слой независим.
function renderConfiguration(canvas, layers) {
const ctx = canvas.getContext('2d');
ctx.clearRect(0, 0, canvas.width, canvas.height);
for (const layer of layers.filter(l => l.visible)) {
const img = imageCache[layer.src];
ctx.drawImage(img, 0, 0);
}
}
3D-визуализация — Three.js или Babylon.js с GLTF-моделью. Материалы меняются через MeshStandardMaterial. Ресурсоёмко по подготовке контента (нужны 3D-модели и текстуры), но даёт максимальный эффект. Подробно разобрано в разделе про 3D-просмотр товара.
Пересчёт цены
Ценообразование может быть простым (сумма дельт опций) или сложным (матрица, формулы, скидки за объём). Для формульного подхода используем expression evaluator — библиотеку, которая безопасно вычисляет строковые выражения:
base_price = 15000
formula = "base * (1 + material_coeff) * area + hardware_cost"
Для B2B: цена зависит от объёма заказа, региона, группы клиента. Эту логику выносим на сервер — клиент получает итоговую цену через API, а не вычисляет сам.
Добавление в корзину
При добавлении конфигурированного товара в корзину сохраняем не просто product_id, а полный snapshot конфигурации:
{
"product_id": 42,
"configuration": {
"material": "oak",
"color": "natural",
"width": 1200,
"handles": "chrome"
},
"computed_price": 38500,
"computed_sku": "DESK-OAK-NAT-1200-CH"
}
Это важно для производства: заказ должен содержать все параметры, не ссылку на «вариант».
Сохранение и шаринг конфигурации
Пользователи часто хотят сохранить свою конфигурацию, вернуться позже или поделиться с коллегой. Решение: сериализуем configuration в JSON, кодируем в base64 или сохраняем в БД с коротким кодом.
URL: /configurator?config=eyJtYXRlcmlhbCI6Im9hayJ9 — состояние десериализуется при загрузке страницы.
Постоянные ссылки: POST /api/configurator/save → {code: "DESK-ABC123"} → URL /configurator/DESK-ABC123. Хранить в Redis с TTL 30 дней или в БД без ограничений.
Сроки
- Вариантный конфигуратор (смена фото, базовый пересчёт цены): 2–3 недели
- Параметрический с зависимостями и layered-визуализацией: 4–7 недель
- CPQ с интеграцией CRM/ERP и формульным ценообразованием: 8–14 недель
Основное время уходит не на код, а на проработку бизнес-правил: какие комбинации допустимы, как считается цена, что отображается при конфликте опций. Без детального ТЗ от клиента реализация невозможна.