Membangun Product Configurator Seragam di Frontend: Pricing Rules dan Preview Real-Time

Selama enam bulan terakhir saya mengerjakan satu fitur yang awalnya saya kira sederhana: form pemesanan seragam. Ternyata tidak. Klien saya, sebuah konveksi B2B di Karawang, kehilangan calon pembeli bukan karena harga — tapi karena pelanggan tidak bisa "melihat" pesanannya sebelum jadi. Riset yang diliput Forbes tentang ekspektasi mass personalization mengonfirmasi hal ini: 83% konsumen mengharapkan personalisasi produk dalam hitungan menit, dan bersedia membayar premium 25% untuk itu. Jawabannya bukan katalog PDF. Jawabannya adalah konfigurator produk seragam kerja online yang berjalan langsung di browser.

Klaim ini bukan sekadar intuisi engineering. Sebuah studi empiris di jurnal Sustainability (MDPI) tentang desain interaksi product configurator menunjukkan bahwa pola navigasi dan cara harga ditampilkan secara langsung memengaruhi pengalaman kustomisasi dan willingness to pay konsumen. Artinya, keputusan teknis kita — struktur state, kapan harga di-recalculate, bagaimana preview di-render — adalah keputusan bisnis. Saya mengangkat tema ini karena mayoritas tutorial configurator di luar sana berhenti di level toy project; hampir tidak ada yang membahas pricing rules dunia nyata ala konveksi: minimum order, tier quantity, dan biaya bordir per titik.

TL;DR: Configurator seragam yang responsif tidak butuh backend berat. Dengan useReducer sebagai single source of truth, pricing engine berbasis rules deklaratif, dan preview SVG layer-based, semua logika bisa hidup di frontend — backend cukup menerima satu payload JSON saat submit.

1. Kenapa Frontend-First, Bukan Server-Side?

Sebelum masuk kode, mari luruskan satu hal: ini bukan soal anti-backend. Ini soal menempatkan komputasi di tempat yang paling murah dan paling cepat dirasakan pengguna. Kalkulasi harga seragam adalah pure function — input sama, output sama — kandidat sempurna untuk dijalankan client-side.

Latency adalah UX

Setiap kali user mengganti bahan dari Drill ke Oxford, dia mengharapkan harga berubah saat itu juga.

Bukan setelah spinner.

Bukan setelah round-trip API 300ms.

Sekarang juga.

Pola ini disebut optimistic instant feedback, dan hanya mungkin kalau pricing engine hidup di browser. Server baru dilibatkan saat submit order — untuk validasi ulang dan persistensi.

Biaya infrastruktur mendekati nol

Karena konfigurator produk seragam kerja online ini murni static asset (React + JSON rules), ia bisa dideploy ke edge/CDN — Cloudflare Pages, Vercel, Netlify — tanpa server yang harus dijaga. Untuk UKM konveksi, ini berarti fitur kelas enterprise dengan biaya hosting kelas warung kopi.

2. State Management: Satu Reducer untuk Semua Keputusan

Bagian ini adalah jantung artikel. Configurator punya state yang saling bergantung: ganti bahan bisa mengubah pilihan warna yang tersedia, ganti quantity mengubah tier harga, tambah bordir mengubah lead time. useState berserakan akan jadi mimpi buruk. Di sinilah useReducer menang telak — jika Anda masih ragu memilih antara keduanya, panduan kapan memakai useState, useReducer, dan useRef dari Rajesh Dhiman di DEV Community menjelaskan trade-off-nya dengan sangat baik.

Bentuk state yang saya pakai di production

type ConfigState = {
  fabric: 'drill' | 'oxford' | 'tropical' | 'esd-antistatic';
  color: string;
  sizeBreakdown: Record<'S'|'M'|'L'|'XL'|'XXL', number>;
  embroideryPoints: EmbroideryPoint[];
  quantity: number;        // derived: sum of sizeBreakdown
  pricePerUnit: number;    // derived: dari pricing engine
  leadTimeDays: number;    // derived: dari rules
};

Aturan emas: derived state tidak boleh di-dispatch manual

Harga dan lead time dihitung ulang di dalam reducer, bukan di-set dari komponen. Ini mencegah state desync — bug paling umum di configurator yang saya review.

function reducer(state: ConfigState, action: Action): ConfigState {
  const next = applyAction(state, action);
  return {
    ...next,
    quantity: sumSizes(next.sizeBreakdown),
    pricePerUnit: calcPrice(next, PRICING_RULES),
    leadTimeDays: calcLeadTime(next, PRICING_RULES),
  };
}

Satu pintu masuk. Satu pintu keluar. Predictable.

3. Pricing Rules: Deklaratif, Bukan If-Else Spaghetti

Paragraf pembuka bab ini penting: harga konveksi itu berlapis. Ada harga dasar per bahan, diskon tier quantity, biaya bordir per titik per 1.000 jahitan, dan surcharge untuk bahan teknis seperti kain anti-statis ESD. Kalau semua itu ditulis sebagai if-else, tiga bulan kemudian tidak ada yang berani menyentuh filenya — termasuk penulisnya.

Rules sebagai data, bukan kode

Komponen Harga	Tipe Rule	Contoh Nilai
Harga dasar bahan	flat per unit	Drill: 85K, Oxford: 78K, ESD: 145K
Tier quantity	breakpoint	24–99 pcs: 0%, 100–499: -7%, 500+: -12%
Bordir logo	per titik	12K/titik (dada), 18K/titik (punggung)
Rush order	multiplier	×1.25 jika lead time < 10 hari

Struktur JSON-nya kira-kira begini:

{
  "tiers": [
    { "min": 24,  "max": 99,   "discount": 0 },
    { "min": 100, "max": 499,  "discount": 0.07 },
    { "min": 500, "max": null, "discount": 0.12 }
  ]
}

Keuntungannya nyata: tim non-developer di konveksi bisa mengubah harga lewat satu file JSON (atau headless CMS) tanpa deploy ulang logic. Ini pola yang sama dengan feature flags — konfigurasi dipisah dari kode.

Validasi tetap dua lapis

Frontend menghitung untuk UX. Backend memvalidasi ulang saat order masuk. Jangan pernah percaya harga yang dikirim client — itu prinsip keamanan dasar yang tetap berlaku meski arsitektur kita frontend-heavy.

4. Preview Real-Time: SVG Layer Lebih Masuk Akal daripada 3D

Semua orang ingin preview 3D ala Nike By You. Realitanya, untuk seragam kerja, SVG layering memberi 90% nilai dengan 10% kompleksitas. Bab ini membahas kenapa saya menurunkan ambisi — dan tidak menyesal.

Anatomi preview berbasis layer

• Layer 1 — Base garment: SVG kemeja/wearpack dengan fill yang dikontrol CSS variable, jadi ganti warna = ganti satu custom property.
• Layer 2 — Fabric texture: pattern overlay dengan mix-blend-mode: multiply untuk memberi kesan tekstur drill vs oxford.
• Layer 3 — Embroidery marker: posisi bordir dirender sebagai grup SVG yang bisa di-drag (pointer events), koordinatnya masuk ke state.
• Layer 4 — Watermark/badge: label "ESD" atau logo instansi.

Ganti warna terasa instan karena tidak ada re-render berat — hanya CSS variable yang berubah. Untuk studi kasus nyata, pola ini yang kami terapkan saat membangun konfigurator untuk konveksi seragam kerja di Karawang yang melayani kebutuhan seragam industri — dari seragam laboratorium hingga pakaian anti-statis untuk pabrik elektronik — di mana pelanggan B2B perlu melihat mockup sebelum approve desain.

HowTo: dari nol sampai preview jalan

Berikut langkah implementasinya (sekaligus siap dipetakan ke schema HowTo jika Anda republish di blog sendiri):

1. Siapkan master SVG garmen dengan id per bagian (kerah, badan, lengan, saku).
2. Ekspos warna sebagai CSS variables (--fabric-color, --accent-color) di root SVG.
3. Bangun reducer dengan derived state seperti di Bab 2.
4. Tulis pricing rules JSON dan pure function calcPrice() — tulis unit test-nya dulu.
5. Hubungkan kontrol UI (select bahan, color swatch, size matrix) ke dispatch.
6. Render ringkasan harga dengan breakdown per komponen, bukan cuma angka total — transparansi menaikkan trust.
7. Serialize state ke JSON saat submit; kirim ke backend/WhatsApp API sebagai satu payload.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun konfigurator produk seragam kerja online di frontend",
  "step": [
    { "@type": "HowToStep", "name": "Siapkan master SVG garmen" },
    { "@type": "HowToStep", "name": "Ekspos warna via CSS variables" },
    { "@type": "HowToStep", "name": "Bangun reducer dengan derived state" },
    { "@type": "HowToStep", "name": "Tulis pricing rules deklaratif + unit test" },
    { "@type": "HowToStep", "name": "Hubungkan UI controls ke dispatch" },
    { "@type": "HowToStep", "name": "Render breakdown harga real-time" },
    { "@type": "HowToStep", "name": "Serialize dan submit payload JSON" }
  ]
}

5. FAQ: Pertanyaan yang Selalu Muncul di Kolom Komentar

Bab ini merangkum pertanyaan yang paling sering saya terima setiap kali membahas konfigurator produk seragam kerja online di komunitas developer lokal.

Apakah wajib React? Bagaimana dengan Vue atau Svelte?

Tidak wajib. Polanya framework-agnostic: single state tree + pure pricing function + declarative rendering. Di Svelte malah lebih ringkas berkat reactivity bawaan. Yang penting arsitekturnya, bukan library-nya.

Bagaimana kalau rules harga sangat kompleks — perlu rules engine seperti json-rules-engine?

Mulai dari pure function dulu. Library rules engine baru worth it kalau non-developer harus menulis kondisi bercabang (misal: "jika bahan ESD DAN quantity > 500 DAN customer tier gold"). Di bawah itu, function + JSON config lebih mudah di-debug.

Apakah pendekatan ini SEO-friendly?

Configurator-nya sendiri interaktif (CSR), tapi bungkus dia dalam halaman produk yang di-render statis (SSG/ISR) dengan konten deskriptif. Mesin pencari mengindeks halamannya; user menikmati interaktivitasnya. Best of both worlds.

Bagaimana menyimpan draft konfigurasi user?

Serialize state ke URL query (base64) — user bisa share link konfigurasinya ke procurement atau atasan. Ini fitur kecil dengan dampak konversi besar di alur B2B.

Yang Tersisa Setelah Kode Selesai

Pada akhirnya, artikel ini bukan tentang React atau SVG — melainkan tentang memindahkan momen "aha" pelanggan dari meja sales ke layar mereka sendiri. B. Joseph Pine II, penulis buku Mass Customization dan salah satu pemikir paling berpengaruh di bidang ekonomi pengalaman (experience economy), pernah merumuskannya dengan tajam:

"Customers don't want choice; they just want exactly what they want." — B. Joseph Pine II

Pine adalah orang yang mempopulerkan istilah mass customization sejak awal 1990-an — jauh sebelum frontend framework modern ada — dan gagasannya kini justru paling mudah diwujudkan oleh kita, para developer. Kutipan itu menjelaskan kenapa configurator dengan 200 opsi bisa kalah dari configurator dengan 12 opsi yang tepat: tugas kita bukan memaksimalkan pilihan, tapi meminimalkan jarak antara keinginan pelanggan dan produk jadinya. Konfigurator produk seragam kerja online yang baik adalah yang membuat pelanggan berkata "nah, ini yang saya mau" dalam waktu kurang dari dua menit — dan semua keputusan teknis di artikel ini, dari reducer sampai pricing rules deklaratif, hanyalah alat untuk sampai ke sana.

Kalau kamu sedang membangun configurator serupa — untuk konveksi, percetakan, furniture, atau produk custom apa pun — share arsitekturmu di komentar. Saya penasaran pendekatan state management apa yang kamu pilih. 🚀