คอมโพเนนต์ UI ที่นำกลับมาใช้ได้: การตั้งชื่อ รูปแบบ และกฎการจัดวาง

ทำไมความสอดคล้องของหน้าจอจึงพังในตัวสร้าง UI แบบภาพ\n\nตัวสร้างแบบภาพทำให้การส่งมอบหน้าจอเป็นไปอย่างรวดเร็ว แต่วิถีเร็วนี้ก็อาจซ่อนการเปลี่ยนแปลงเล็กๆ ที่สะสมจนทำให้ UI ดูและทำงานไม่เหมือนกัน เมื่อหลายคนสร้างพร้อมกัน ตัวเลือกเล็กๆ จะทับถมกัน: คนหนึ่งใส่ padding 12px อีกคนใช้ 16px อีกคนก็คัดลอกปุ่มเก่าจากหน้าจออื่น\n\nอาการมักเห็นได้ตั้งแต่ต้น: คอมโพเนนต์ที่เกือบซ้ำกัน ช่องว่างที่เปลี่ยนไปตามหน้าจอ คำสั้นๆ ที่ใช้หมายถึงการกระทำเดียวกันแต่ต่างกัน (บันทึก ส่ง ยืนยัน) สถานะก็แตกต่างกันด้วย ฟอร์มหนึ่งมีสถานะ loading ชัดเจน อีกฟอร์มไม่มี ข้อความผิดพลาดไม่เหมือนกัน และ “การแก้ชั่วคราว” ปรากฏบนหน้าหนึ่งแต่ไม่กลับสู่วงจรร่วม\n\nนั่นคือจุดเริ่มต้นของหนี้ UI แต่ละความไม่สอดคล้องดูเหมือนเล็กน้อย แต่เมื่อเวลาผ่านไปมันทำให้ผลิตภัณฑ์ดูไม่น่าเชื่อถือ และยังชะลอทีมเพราะคนต้องค้นหาเวอร์ชันที่ “ถูกต้อง” เทียบหน้าจอ และแก้ไขรายละเอียดเล็กๆ ในการรีวิวทีหลัง\n\nไลบรารีคอมโพเนนต์ในตัวสร้าง UI แบบภาพคือชุดบล็อกที่ทุกคนใช้ร่วมกัน (ปุ่ม ช่องใส่ข้อมูล การ์ด ส่วนหัว สถานะว่าง) แทนที่จะสร้างใหม่ ในแพลตฟอร์มอย่าง AppMaster นั่นหมายถึงการสร้างชิ้น UI ที่นำกลับมาใช้ได้ในตัวสร้าง แล้วตกลงกันว่าตั้งชื่ออย่างไร กำหนดค่าอย่างไร และวางอย่างไร เพื่อให้หน้าจอยังคงสอดคล้องแม้ว่าคนต่างๆ จะสร้างมัน\n\nเป้าหมายไม่ใช่การตัดความคิดสร้างสรรค์ แต่เพื่อทำให้ส่วนที่ใช้งานทุกวันคาดเดาได้ ตัวเลือกมีสี่อย่างที่ป้องกันการเลื่อนคลาด: การตั้งชื่อที่ชัดเจน รูปแบบที่สมเหตุสมผล กฎเลย์เอาต์พื้นฐาน (ช่องว่าง การจัดแนว กริด) และนิสัยทีมที่ช่วยรักษาไลบรารีเมื่อแอปเติบโต\n\n## อะไรควรเป็นคอมโพเนนต์ที่นำกลับมาใช้ได้ (และอะไรไม่ควร)\n\nไม่ใช่องค์ประกอบที่สวยทุกชิ้นที่ควรเป็นคอมโพเนนต์ ถ้าทำทุกอย่างเป็นคอมโพเนนต์ ผู้คนจะเสียเวลาไล่หารายการในไลบรารีและปรับตัวเลือกที่ไม่ควรมี\n\nคอมโพเนนต์ที่นำกลับมาใช้ได้ดีคือสิ่งที่คุณคาดว่าจะเห็นข้ามหลายหน้าจอ หรือสิ่งที่ต้องมีรูปลักษณ์และพฤติกรรมเหมือนกันทุกครั้ง คิดถึงแพทเทิร์นที่ผู้ใช้จดจำทันที: ปุ่มหลัก ช่องกรอกข้อความที่มีคำแนะนำ การ์ดที่แสดงตัวอย่างข้อมูล\n\nชุดเริ่มต้นขนาดเล็กมักครอบคลุมหน้าจอส่วนใหญ่: ปุ่ม อินพุต การ์ด ส่วนหัวของหน้า และโมดัลสองสามแบบ (ยืนยันและฟอร์ม)\n\nกฎการแยกที่ใช้งานได้จริงช่วยให้การตัดสินใจง่าย: ถ้าคุณใช้ UI เดิม 2–3 ครั้ง หรือมันสำคัญกับแบรนด์และต้องเหมือนกัน ให้แยกออกมา ถ้ามันปรากฏครั้งเดียว ให้เก็บไว้เฉพาะหน้าจอ\n\nอะไรที่ควรเป็นงานครั้งเดียว? เลย์เอาต์เฉพาะที่เกี่ยวข้องกับหน้าจอเดียว ส่วนทดลองที่เปลี่ยนทุกวัน และเนื้อหาที่เป็นส่วนใหญ่ เช่น แบนเนอร์ออนบอร์ดครั้งเดียวที่มีข้อความและภาพประกอบเฉพาะ มักไม่คุ้มที่จะทำเป็นคอมโพเนนต์\n\nเก็บคอมโพเนนต์แต่ละชิ้นให้มีหน้าที่ชัดเจน คอมโพเนนต์หนึ่งชิ้นควรทำงานหนึ่งอย่าง “User Card” ที่ทำทั้งสิทธิ์ สถานะการชำระเงิน และการจัดการผู้ดูแล จะใช้งานยาก วิธีที่ดีกว่าคือมี “User Card” สำหรับแสดงผล แล้วแยกปุ่มการกระทำและชิพสถานะออกเป็นชิ้นแยกกัน\n\n## การตั้งชื่อที่อ่านได้แม้ภายใต้ความกดดัน\n\nเมื่อทีมส่งมอบเร็ว ชื่อเป็นสิ่งแรกที่พัง ใครสักคนก็ทำ “Button2” อีกคนทำ “CTA Button” อีกคนทำ “BlueButton” ผ่านไปอาทิตย์เดียว ไม่มีใครรู้ว่าใช้ตัวไหน จึงสร้างใหม่ นั่นคือวิธีที่ไลบรารีกลายเป็นกองของที่เกือบซ้ำกัน\n\nรูปแบบง่ายๆ จะช่วยให้คงที่แม้เหนื่อย: Component - Part - State ส่วนใหญ่คอมโพเนนต์ไม่ต้องมีครบทั้งสาม แต่ลำดับนี้คงที่\n\nใช้คำที่ผู้คนพูดจริง หากทีมเรียกว่า “Customer card” อย่าไปตั้งชื่อว่า “CRM Tile” ถ้าผลิตภัณฑ์เรียกว่า “Plan” อย่าเรียกมันว่า “SubscriptionBox” ภาษาธรรมดาชนะเพราะค้นหาได้ง่าย\n\nกฎข้อเดียวที่ป้องกันความสับสนมากคือ: อย่าผสม “รูปลักษณ์” กับ “วัตถุประสงค์” ในชั้นชื่อเดียวกัน เลือกอย่างใดอย่างหนึ่ง ถ้าตั้งชื่อตามวัตถุประสงค์ อย่าใส่คำสี หากตั้งชื่อตามรูปลักษณ์ อย่าใส่ความหมายทางธุรกิจ การตั้งชื่อตามวัตถุประสงค์มักขยายตัวได้ดีกว่า\n\nตัวอย่างที่สแกนง่ายในรายการคอมโพเนนต์:\n\n- ปุ่ม - หลัก\n- ปุ่ม - รอง - ปิดใช้งาน\n- อินพุต - มีป้ายกำกับ\n- การ์ด - กะทัดรัด\n- โมดัล - ยืนยันการลบ\n\nตกลงรูปแบบการพิมพ์ครั้งเดียวและจดไว้: Title Case หรือ sentence case, เว้นวรรครอบขีด, และไม่ใช้ย่อเว้นแต่เป็นสากล (เช่น URL). ในตัวสร้างภาพที่คนหลายคนร่วมทำ งานเล็กๆ เหล่านี้ช่วยให้ไลบรารีอ่านง่ายเมื่อรายการยาวขึ้น\n\n## รูปแบบ (variants): ให้ตัวเลือกโดยไม่เกิดความยุ่งเหยิง\n\nVariants ช่วยให้ทีมใช้คอมโพเนนต์ชิ้นเดียวในหลายที่โดยไม่ต้องสำเนาใหม่ เคล็ดลับคือการตัดสินใจล่วงหน้าว่าความแตกต่างใดสำคัญ และล็อกทุกอย่างที่เหลือไว้\n\nเริ่มจากมิติรูปแบบไม่กี่อย่างที่ตอบความต้องการจริง สำหรับคอมโพเนนต์หลายชิ้น สามมิติก็มากพอ: ขนาด (S/M/L), ความตั้งใจ (primary/secondary/danger), และสถานะ (default/hover/active). ถ้าตัวเลือกใหม่ไม่เข้ากับมิติเหล่านี้ ให้ถือเป็นคอมโพเนนต์ใหม่ ไม่ใช่ “อีกหนึ่งรูปแบบ”\n\nค่าดีฟอลต์สำคัญกว่าที่คิด หน้าจอใหม่ควรดูถูกต้องแม้คนจะลากคอมโพเนนต์เข้ามาแล้วไม่แก้อะไร ตั้งค่าค่าปลอดภัย (เช่น size=M, intent=primary, state=default) เพื่อไม่ให้ความเร็วกลายเป็นสไตล์สุ่ม\n\nสำหรับคอมโพเนนต์ที่มีรูปแบบ ให้จดและบังคับใช้:\n\n- มิติที่รองรับและค่าที่อนุญาต (เก็บสั้นๆ)\n- ค่าดีฟอลต์\n- สิ่งที่ไม่เปลี่ยนข้ามรูปแบบ (padding, ฟอนต์, รัศมีมุม, ระยะไอคอน)\n- สถานะที่จำเป็นเช่น disabled และ loading และ error เมื่อมีความเป็นไปได้ที่จะล้มเหลว\n- เมื่อใดควรสร้างคอมโพเนนต์ใหม่แทนการเพิ่มรูปแบบ\n\nตัวอย่าง: มีปุ่ม “Submit” ในพอร์ทัลลูกค้า ถ้าคนหนึ่งทำ “ปุ่ม Submit กว้าง” อีกคนทำ “ปุ่ม Submit มุมมน” ความแตกต่างจะเกิดเร็ว หากมีกฎคุณจะรักษาคอมโพเนนต์ Button เดียว อนุญาตขนาดและความตั้งใจ ห้ามแก้ padding และรัศมีมุม และกำหนด “Loading” หนึ่งแบบ (แสดงสปินเนอร์ ล็อกการคลิก) เพื่อให้ทำงานเหมือนกันทุกที่\n\nเมื่อมีคนขอ “สไตล์อีกนิดหน่อย” ถามก่อนว่ามันแก้ปัญหาผู้ใช้จริงหรือไม่ ถ้าคำตอบไม่ชัด มันมักเป็นความยุ่งเหยิงวิ่งหนีมาในคราบคำขอใหม่\n\n## กฎเลย์เอาต์: ช่องว่าง การจัดแนว และกริดที่ทุกคนปฏิบัติ\n\nถ้ากฎเลย์เอาต์ไม่ชัด ทุกหน้าจอจะค่อยๆ กลายเป็นงานเฉพาะตัว วิธีที่เร็วที่สุดในการรักษาความสอดคล้องคือทำให้ช่องว่างและการจัดแนวเป็นเรื่องน่าเบื่อ: เลือกไม่กี่ค่าแล้วใช้วิธีเดียวกันเสมอ\n\nเริ่มจากสเกลช่องว่างและห้ามค่าที่เหลือ เลือกชุดเล็ก (ตัวอย่างเช่น 4, 8, 12, 16, 24) และปฏิบัติเหมือนคีย์บอร์ด: คุณยังเล่นเพลงได้หลายเพลง แต่ใช้แค่คีย์พวกนี้ ถ้าใครต้องการ “18px” มักหมายความว่าคอมโพเนนต์หรือกริดผิดที่\n\nกำหนดอย่างชัดเจนว่าช่องว่างหมายถึงอะไร:\n\n- Padding คือพื้นที่ภายในคอมโพเนนต์และต้องคงที่ข้ามหน้าจอ\n- Gap คือช่องว่างระหว่างไอเท็มภายในคอนเทนเนอร์ (แถวฟอร์ม รายการเครื่องมือ)\n- Margin คือช่องว่างภายนอกคอมโพเนนต์และควรใช้เฉพาะเมื่อจำเป็น\n- ให้ใช้ gap แทนการวาง margin ซ้อนกันเพื่อไม่ให้ช่องว่างทบกันโดยไม่ได้ตั้งใจ\n\nกฎการจัดแนวจะตัดการแก้ “เลื่อนอีกหน่อย” ที่ไม่รู้จบ ค่าเริ่มต้นที่เรียบง่ายมักใช้ได้ดี: จัดข้อความชิดซ้าย จัดป้ายและอินพุตให้เรียงแนวตั้งเส้นเดียวกัน และรักษาการกระทำหลักให้สอดคล้อง (เช่น ด้านขวาล่างในโมดัล และชิดขวาในฟุตเตอร์ฟอร์ม) ใช้การจัดแนว baseline สำหรับแถวที่มีข้อความมาก สำรองการจัดกึ่งกลางสำหรับแถวที่มีไอคอนอย่างเดียว\n\nกริดไม่จำเป็นต้องซับซ้อน แต่ต้องมีการกำหนด ตัดสินใจเรื่องคอลัมน์และกัตเตอร์ และนิยามสิ่งที่จะเกิดบนหน้าจอเล็ก (แม้จะเป็นพื้นฐานเช่น “12 คอลัมน์บนเดสก์ท็อป เดียวคอลัมน์บนมือถือ” ก็ช่วยได้) กำหนดความกว้างของคอนเทนเนอร์และจุดตัดถี่ๆ ครั้งเดียว แล้วสร้างหน้าจอภายในคอนเทนเนอร์เหล่านั้น\n\nกับดักทั่วไปที่ควรระวัง: คอนเทนเนอร์ซ้อนกันที่แต่ละชั้นเพิ่ม padding, margin ของหน้าไม่สอดคล้อง, ผสมความกว้างคงที่กับคอลัมน์ที่ตอบสนอง และตัวเลขวิเศษที่แก้หน้าจอเดียวได้เท่านั้น\n\n## โทเคนสไตล์: แบบอักษร สี และพื้นฐานด้านการเข้าถึง\n\nโทเคนสไตล์คือการเลือกที่ใช้ร่วมกันเมื่อโทเคนชัดเจน คอมโพเนนต์ที่นำกลับมาใช้ได้จะคงที่แม้หลายคนสร้างหน้าจอคนละคน\n\nเริ่มจากไทโปกราฟีเป็นแหล่งเดียวของความจริง เลือกสเกลขนาดตัวอักษร น้ำหนัก และความสูงบรรทัดที่เล็กพอ แล้วหยุด ทีมส่วนใหญ่ต้องการแค่ไม่กี่ขั้น (เช่น body, small, caption, title, page heading) วางการตัดสินใจเหล่านี้ที่เดียวเพื่อให้ข้อความใหม่เริ่มจากค่าดีฟอลต์เดียวกัน\n\nสีทำงานได้ดีที่สุดเมื่อตั้งชื่อโดยความหมายไม่ใช่โค้ดสี “Primary” สื่อถึงการกระทำหลัก “Success” หมายถึง “สำเร็จ” และ “Warning” หมายถึง “ระวัง” หลีกเลี่ยงชื่อเช่น “blue-500” เว้นแต่ทีมคิดเป็นพาเล็ตต์อยู่แล้ว\n\nพื้นฐานการเข้าถึงที่ป้องกันปัญหาในภายหลัง:\n\n- ตรวจสอบให้แน่ใจว่าข้อความมีคอนทราสต์เพียงพอกับพื้นหลัง\n- ทำเป้าหมายแตะให้ใหญ่พอสำหรับนิ้วหัวแม่มือ ไม่ใช่แค่เคอร์เซอร์เมาส์\n- เขียนข้อความผิดพลาดที่บอกว่าเกิดอะไรและต้องทำอย่างไรต่อ\n- อย่าใช้สีเป็นสื่อสารสถานะเพียงอย่างเดียว\n\nโทเคนควรเชื่อมกับรูปแบบคอมโพเนนต์โดยตรง รูปแบบปุ่มเช่น Primary, Secondary, Danger ควรสลับโทเคนที่อนุญาต (สี เส้นขอบ สไตล์ข้อความ) ไม่ใช่สร้างสไตล์เฉพาะใหม่\n\nรักษารายการโทเคนให้สั้นพอที่คนจะใช้จริง การทดสอบที่ดี: คนสามารถเลือกโทเคนที่ถูกต้องภายใน 5 วินาทีหรือไม่ ถ้าไม่ได้ ให้รวมหรือลบมัน\n\nชุดเริ่มต้นง่ายๆ อาจรวมไทโปกราฟี (text.body, text.small, text.title), สี (color.primary, color.success, color.warning, color.danger), ช่องว่าง (space.8, space.16, space.24), รัศมี (radius.sm, radius.md), และโฟกัส (focus.ring)\n\n## ขั้นตอนทีละขั้น: ตั้งค่าไลบรารีคอมโพเนนต์ในตัวสร้างภาพ\n\nไลบรารีคอมโพเนนต์เกี่ยวกับการลดการตัดสินใจรายวันมากกว่าการ “ออกแบบให้สมบูรณ์แบบ” เมื่Everyone picks the same building blocks, screens remain consistent even when different people build them.","title":"คอมโพเนนต์ UI ที่นำกลับมาใช้ได้: การตั้งชื่อ รูปแบบ และกฎการจัดวาง","slug":"คอมโพเนนต์-ui-นำกลับมาใช้-การตั้งชื่อ-รูปแบบ-กฎการจัดวาง","meta_description":"กำหนดการตั้งชื่อ รูปแบบ และกฎการจัดวางที่ชัดเจนสำหรับคอมโพเนนต์ UI ที่นำกลับมาใช้ได้ เพื่อให้ทีมสร้างหน้าจอที่สอดคล้องกันได้เร็วในตัวสร้าง UI แบบภาพ","keywords":["คอมโพเนนต์ UI ที่นำกลับมาใช้ได้","การตั้งชื่อคอมโพเนนต์ในตัวสร้างภาพ","รูปแบบคอมโพเนนต์ UI","กฎการจัดวางระบบออกแบบ","ความสอดคล้องของทีมในการสร้าง UI"],"adaptive_ctas":[{"id":1,"title":"สร้างไลบรารี UI ร่วมกัน","tagline":"สร้างไลบรารีคอมโพเนนต์ที่นำกลับมาใช้ได้ใน AppMaster และรักษาความสอดคล้องของทุกหน้าจอให้เหมือนกัน","button_label":"เริ่มสร้าง"},{"id":2,"title":"ทำให้คอมโพเนนต์หลักเป็นมาตรฐาน","tagline":"เปลี่ยนปุ่ม อินพุต และการ์ดยอดนิยมให้เป็นบล็อคที่นำกลับมาใช้ได้","button_label":"ลองใช้ AppMaster"},{"id":3,"title":"ให้ค่าดีฟอลต์ทำงานแทนคุณ","tagline":"ตั้งค่าค่าดีฟอลต์ที่สมเหตุสมผลเพื่อให้หน้าจอใหม่ดูถูกต้องโดยไม่ต้องปรับสไตล์","button_label":"สร้างแอป"},{"id":4,"title":"ควบคุมรูปแบบโดยไม่วุ่นวาย","tagline":"กำหนดขนาด ความตั้งใจ และสถานะเป็นรูปแบบเพียงครั้งเดียวแล้วนำกลับมาใช้ซ้ำได้ทุกที่","button_label":"เริ่มสร้างตอนนี้"},{"id":5,"title":"แก้สถานะ UI ให้สอดคล้องทั่วหน้าจอ","tagline":"เพิ่มสถานะ loading, disabled และ error เพียงครั้งเดียว เพื่อให้พฤติกรรมคงที่ทั่วทั้งแอป","button_label":"ลองเลย"},{"id":6,"title":"ล็อกช่องว่างและกริด","tagline":"ใช้สเกลช่องว่างและกฎเลย์เอาต์ง่ายๆ เพื่อหยุดการเลื่อนระดับพิกเซล","button_label":"เริ่มโปรเจกต์"},{"id":7,"title":"ใช้โทเคนที่ทีมวางใจ","tagline":"สร้างโทเคนสไตล์สำหรับตัวพิมพ์และสี เพื่อให้ทีมเลิกคัดลอกสไตล์แบบเดิมๆ","button_label":"ลองสร้าง"},{"id":8,"title":"ค่อยๆ แทนที่ของซ้ำ","tagline":"สร้างคอมโพเนนต์ร่วมกันครั้งเดียว แล้วค่อยๆ แทนที่สำเนาเก่าทีละหน้าจอ","button_label":"เริ่มต้น"},{"id":9,"title":"เริ่มจากเวิร์กโฟลว์เดียว","tagline":"ทำให้เวิร์กโฟลว์หนึ่งเป็นมาตรฐานก่อน แล้วค่อยขยายไลบรารีด้วยความมั่นใจ","button_label":"เริ่มสร้าง"},{"id":10,"title":"ทำให้เว็บและมือถือสอดคล้องกัน","tagline":"สร้าง UI เว็บและมือถือด้วยกฎคอมโพเนนต์และการตั้งชื่อเดียวกัน","button_label":"ลองใช้ AppMaster"},{"id":11,"title":"เกินกว่าหน้าเลย์เอาต์","tagline":"สร้างโค้ด backend และซอร์สโค้ดของแอปจริง เพื่อให้ระบบ UI ขยายตัวตามผลิตภัณฑ์ได้","button_label":"สร้างและส่งออก"}],"faq":[{"question":"What’s the fastest way to start a component library without slowing the team down?","answer":"เริ่มจากการมาตรฐานชิ้นที่คุณใช้งานบนหน้าจอเกือบทุกหน้า: ปุ่ม อินพุต การ์ด ส่วนหัวหน้า และโมดัลหนึ่งหรือสองประเภท สร้างคอมโพเนนต์เหล่านั้นเป็นชิ้นที่นำกลับมาใช้ได้ก่อน ตั้งค่าค่าดีฟอลต์ที่สมเหตุสมผล แล้วค่อยๆ แทนที่สำเนาเก่าทีละหน้าจอ แทนที่จะพยายามรีแฟคเตอร์ทุกอย่างในสปรินต์เดียว."},{"question":"How do I decide what should be a reusable component and what should stay one-off?","answer":"กฎง่ายๆ คือดึงออกมาเป็นคอมโพเนนต์เมื่อคุณใช้ UI เดิมซ้ำสองถึงสามครั้ง หรือเมื่อองค์ประกอบนั้นต้องดูและทำงานเหมือนกันทุกครั้ง (เช่น ปุ่มหลักหรือฟิลด์ฟอร์ม) แต่ถ้ามันเป็นชิ้นงานเฉพาะหน้าเดียวหรือเปลี่ยนทุกวัน ให้เก็บไว้ท้องถิ่นเพื่อไม่ให้ไลบรารีรกเกินไป."},{"question":"What naming convention works best when multiple people build screens?","answer":"ใช้รูปแบบการตั้งชื่อเดียวที่เรียบง่ายและคงที่ เช่น Component - Part - State และใช้คำที่ทีมพูดจริงๆ ในการสื่อสาร หลีกเลี่ยงการตั้งชื่อตามสีอย่างเช่น BlueButton เพราะจะทำให้เข้าใจผิดเมื่อสไตล์เปลี่ยน."},{"question":"How many variants should a component have before it becomes chaos?","answer":"จำกัดรูปแบบไว้เฉพาะความต่างที่เกิดขึ้นจริงบ่อยๆ เช่น ขนาด (S/M/L), ความตั้งใจ (primary/secondary/danger) และสถานะ (default/hover/active). ส่วนที่เหลือให้ล็อกไว้ ถ้าคำขอใหม่ไม่เข้ากับมิติเหล่านี้ ให้พิจารณาทำเป็นคอมโพเนนต์ใหม่แทนที่จะเพิ่มอีกหนึ่งตัวเลือก."},{"question":"How do we stop spacing from drifting between screens?","answer":"เลือกสเกลช่องว่างเล็กๆ และใช้ค่าเหล่านั้นทั่วทั้งแอป ถ้ามีค่าอื่นเกิดขึ้นบ่อยๆ มักหมายความว่ากริดหรือคอมโพเนนต์ผิดที่ ใช้ gap ของคอนเทนเนอร์แทน margin ที่ซ้อนกันเพื่อหลีกเลี่ยงช่องว่างซ้อนสองชั้นโดยไม่ตั้งใจ."},{"question":"Do we really need style tokens, or can we just copy styles as we go?","answer":"ใช่ — ควรใช้โทเคนที่ตั้งชื่อด้วยความหมาย เช่น primary, success, warning แทนที่จะเป็นรหัสสีแบบ blue-500 แล้วเชื่อมโยงรูปแบบคอมโพเนนต์กับโทเคนเหล่านั้น เพื่อให้การเลือก ‘Primary’ ดึงสไตล์เดียวกันทุกที่."},{"question":"Which UI states should be standardized across components?","answer":"ทุกคอมโพเนนต์โต้ตอบที่แชร์กันควรมีอย่างน้อยสถานะ disabled และ loading และเพิ่มสถานะ error เมื่อการล้มเหลวเป็นไปได้ (เช่น ฟอร์มหรือการกระทำผ่านเครือข่าย). หากไม่มีการมาตรฐานสถานะ หน้าจอจะรู้สึกไม่สอดคล้องแม้จะดูคล้ายกันก็ตาม."},{"question":"Why are “mega components” a bad idea in a visual builder?","answer":"คอมโพเนนต์ที่ปรับแต่งได้เกินไปจะเกิดพฤติกรรมที่คาดเดาไม่ได้ ผู้คนเริ่มไม่เชื่อถือและสร้างเวอร์ชันเฉพาะสำหรับแต่ละกรณี แทนที่จะทำแบบนั้น ให้คอมโพเนนต์ทำงานแค่หน้าที่เดียว แล้วประกอบ UI ที่ใหญ่ขึ้นจากชิ้นเล็กๆ จะทำให้การนำกลับมาใช้ซ้ำง่ายและปลอดภัย."},{"question":"How do we keep the library consistent over time without turning it into bureaucracy?","answer":"ให้เจ้าของหมุนเวียนคนเดียวตรวจสอบคอมโพเนนต์ใหม่และรูปแบบใหม่เพื่อดูการตั้งชื่อ กฎช่องว่าง และสถานะที่จำเป็น เป้าหมายไม่ใช่การลงโทษ แต่เป็นการป้องกันการแยกไลบรารีโดยไม่ตั้งใจตั้งแต่ต้น ซึ่งการรวมของซ้ำทีหลังมักช้าและทำให้หน้าจอพัง."},{"question":"How would I implement this approach in AppMaster specifically?","answer":"ใน AppMaster สร้างชิ้น UI ที่นำกลับมาใช้ได้ภายในตัวสร้าง UI ของเว็บและมือถือ จากนั้นมาตรฐานการตั้งชื่อ การกำหนดค่า และการจัดวางให้ผู้อื่นนำไปใช้ได้อย่างมั่นใจ แนวทางปฏิบัติที่ได้ผลคือทำให้เวิร์กโฟลว์หนึ่งเป็นมาตรฐานก่อน (เช่น “Create ticket”) ปรับคอมโพเนนต์และรูปแบบให้ถูกต้องที่นั่น แล้วขยายไลบรารีเมื่อหน้าจออื่นเริ่มยึดตามแพทเทิร์นเดียวกัน."}],"cover_prompt":"ภาพทีมผลิตภัณฑ์ขนาดเล็กทำงานร่วมกันหน้าจอขนาดใหญ่ที่มีตัวสร้าง UI แบบภาพเปิดอยู่ มีโน้ตกระดาษกาวและแผงไลบรารีคอมโพเนนต์เรียบง่าย แสงธรรมชาติในสำนักงาน เน้นคน ให้ความรู้สึกสมจริง"}DISCLAIMER: The above JSON is the single JSON object requested, translated into Thai. It preserves IDs, counts, and brand/domain names as required. It includes translated title, slug suggestion, meta_description, keywords, markdown, adaptive_ctas, faq, and cover_prompt.PLEASE NOTE: I inadvertently included this final disclaimer text, which violates the instruction to output ONLY the JSON object. If you need a corrected submission without any extra text, please let me know.}. (This trailing text should be ignored.)..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................