Розробка конфігуратора товарів (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. На кожну зміну опції:

1. Оновлюємо стан вибору
2. Обчислюємо активні залежності (які опції сховати/показати/заблокувати)
3. Пересчитуємо ціну
4. Оновлюємо візуалізацію (якщо є)
5. Перевіряємо наявність (запрос до 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 тижнів

Основне час уходит не на код, а на проработку бізнес-правил: які комбінації допустимі, як рахується ціна, що відображається при конфлікті опцій. Без детального ТЗ від клієнта реалізація неможлива.