PlusMagi's Blog By Pitt Phunsanit Backend,Database โครงสร้าง Dynamic Color และ Design Tokens สำหรับนักพัฒนา

โครงสร้าง Dynamic Color และ Design Tokens สำหรับนักพัฒนา

ในฐานะสถาปนิกระบบ (System Architect) การจัดการระบบสีและธีม (Theming) ที่ยืดหยุ่นสูงเป็นหัวใจสำคัญของแอปพลิเคชันสมัยใหม่ โดยเฉพาะการรองรับแนวคิด Dynamic Color (เช่น Material You) ที่สามารถปรับสีตามบริบทหรือรูปภาพได้ทันที

ในการนำแนวคิดนี้มาใช้ในระดับ Backend หรือการกำหนดค่าโครงสร้างข้อมูล (Schema) เราจำเป็นต้องใช้หลักการ **Design Tokens** ซึ่งคือการแยกความหมาย (Semantic) ของค่าสีออกจากค่าสีดิบ (Raw Value) การใช้ PostgreSQL ในการจัดการโครงสร้าง Token นี้ช่วยให้เราสามารถสร้างชั้นการสืบทอด (Inheritance Layer) ของค่าสีได้อย่างเป็นระบบและ Scalable

1. การสร้างโครงสร้าง Token 3 ระดับใน PostgreSQL

สถาปัตยกรรม Token ที่สมบูรณ์แบบจะแบ่งออกเป็น 3 ระดับ เพื่อให้เกิดการแยกชั้นของความหมาย (Layered Abstraction) อย่างชัดเจน:

SQL

-- ===================================================================
-- TIER 1: REFERENCE TOKENS (ค่าสีดิบตาม Palette/HCT Tonal Scale)
-- เก็บค่าสีพื้นฐานที่สุด (เช่น $0-100$ ของสีหลัก)
CREATE TABLE reference_tokens (
    token_name VARCHAR(50) PRIMARY KEY, -- เช่น 'blue-500', 'red-100'
    hex_value VARCHAR(7) NOT NULL,       -- เช่น '#123456'
    tone_level INTEGER NOT NULL          -- ระดับความเข้ม (0-100)
);

COMMENT ON TABLE reference_tokens IS 'ชั้นที่ 1: ค่าสีดิบที่ถูกกำหนดไว้ล่วงหน้า (Raw Palette Values)';

-- ===================================================================
-- TIER 2: SEMANTIC TOKENS (ความหมายและบทบาทตามบริบท UI & Mode)
-- กำหนดว่าค่าสีใดจะใช้แทนบทบาทใด (เช่น 'primary', 'background-surface')
CREATE TABLE semantic_tokens (
    context_key VARCHAR(50) PRIMARY KEY, -- เช่น 'primary', 'surface-background'
    light_mode_token_ref VARCHAR(50) REFERENCES reference_tokens(token_name),
    dark_mode_token_ref VARCHAR(50) REFERENCES reference_tokens(token_name)
);

COMMENT ON TABLE semantic_tokens IS 'ชั้นที่ 2: การแมปความหมายของสีตามโหมด (Light/Dark Mode)';

-- ===================================================================
-- TIER 3: COMPONENT TOKENS (การใช้งานเฉพาะจุด)
-- กำหนดการใช้งานสุดท้ายของส่วนประกอบ UI (เช่น ปุ่ม, แถบนำทาง)
CREATE TABLE component_tokens (
    component_name VARCHAR(50) PRIMARY KEY, -- เช่น 'button-primary', 'nav-active'
    semantic_token_ref VARCHAR(50) REFERENCES semantic_tokens(context_key), -- อ้างอิงจาก Tier 2
    fallback_hex VARCHAR(7)
);

COMMENT ON TABLE component_tokens IS 'ชั้นที่ 3: การกำหนดค่าสีสุดท้ายสำหรับส่วนประกอบ UI ที่เฉพาะเจาะจง';

2. การทำงานของ Dynamic Color ด้วย PostgreSQL Query

เมื่อระบบต้องการค่าสีสำหรับปุ่มหลัก (Primary Button) ในโหมด Dark Mode เราจะไม่ Query ค่าสีโดยตรง แต่จะ Query ผ่านชั้นความหมาย:

SQL

-- 1. ค้นหา Semantic Token สำหรับ 'primary' ใน Dark Mode
WITH primary_semantic AS (
    SELECT dark_mode_token_ref FROM semantic_tokens WHERE context_key = 'primary'
)
-- 2. ดึงค่าสีดิบ (Hex Value) จาก Token Reference
SELECT
    rt.hex_value AS final_color_hex
FROM
    reference_tokens rt
JOIN
    primary_semantic ps ON rt.token_name = ps.dark_mode_token_ref;

-- ตัวอย่างผลลัพธ์: '#B3E0FF' (ค่าสีที่ถูกต้องสำหรับ Primary Button ใน Dark Mode)

กระบวนการนี้ทำให้เราสามารถเปลี่ยน Seed Color (เช่น จากภาพถ่าย) ได้เพียงแค่การอัปเดตค่าใน `reference_tokens` โดยที่โค้ด UI ที่เรียกใช้ `component_tokens` ไม่จำเป็นต้องเปลี่ยนแปลงเลย นี่คือพลังของการแยกชั้นความหมาย (Semantic Separation) ที่ทำได้ด้วยโครงสร้างข้อมูลของ PostgreSQL

บทสรุป: การออกแบบที่ยืดหยุ่นและ Scalable

การใช้ PostgreSQL ในการจัดการ Design Tokens ไม่เพียงแต่ช่วยให้การจัดการค่าสีมีความเป็นระเบียบเท่านั้น แต่ยังช่วยให้เราสร้างระบบที่รองรับการเปลี่ยนแปลงครั้งใหญ่ (เช่น การเปลี่ยน Material Design เวอร์ชัน หรือการเพิ่มโหมด Contrast) ได้อย่างง่ายดายและมีประสิทธิภาพสูงสุด นักพัฒนาสามารถมั่นใจได้ว่าทุกส่วนประกอบ UI จะได้รับค่าสีที่ถูกต้องตามบริบทและโหมดที่กำหนด โดยไม่ต้องพึ่งพา Hardcoded Values อีกต่อไป