ข้ามไปยังเนื้อหาหลัก

คำถามที่พบบ่อย (FAQ)

info

ถ้ามีคำถามเพิ่มเติม แวะไปคุยกันได้ที่ Telegram chat, Discord community, และ GitHub Discussions

มี Toolkit หรือ Linter ให้ใช้ไหม?​

มีสิ! เรามี Linter ชื่อว่า Steiger เอาไว้ช่วยเช็ค Architecture ของโปรเจกต์ และยังมี Folder Generators ที่ใช้งานผ่าน CLI หรือ IDEs ได้ด้วย

เอาพวก Layout/Template ของหน้าเว็บไว้ที่ไหนดี?​

ถ้าต้องการแค่ Layout ที่เป็น Markup ธรรมดาๆ ก็เอาไว้ที่ shared/ui ได้เลย แต่ถ้าจำเป็นต้องใช้ Layer ที่สูงกว่านั้น ก็มีทางเลือกอยู่บ้าง:

  • ลองเช็คดูว่าจำเป็นต้องมี Layout จริงๆ ไหม? ถ้า Layout มันมีแค่ไม่กี่บรรทัด บางทีการเขียนซ้ำในแต่ละหน้าอาจจะสมเหตุสมผลกว่าการพยายามไป Abstract มันออกมา
  • ถ้าจำเป็นต้องใช้ Layout จริงๆ ก็สร้างเป็น Widgets หรือ Pages แยกออกมา แล้วค่อยเอามาประกอบกันใน Router Configuration ที่ App หรือจะใช้ Nested Routing ก็เป็นอีกทางเลือกที่น่าสนใจ

Feature กับ Entity ต่างกันยังไง?​

Entity คือคอนเซปต์ในโลกความเป็นจริงที่แอปของเราต้องทำงานด้วย ส่วน Feature คือการโต้ตอบ (Interaction) ที่สร้าง Value จริงๆ ให้กับผู้ใช้ พูดง่ายๆ คือสิ่งที่คนอยากจะทำกับ Entity ของเรานั่นเอง

ดูข้อมูลเพิ่มเติมพร้อมตัวอย่างได้ที่หน้า Reference เกี่ยวกับ Slices

เอา Pages/Features/Entities มาซ้อนกันเองได้ไหม?​

ทำได้ แต่การซ้อนกันนี้ควรเกิดขึ้นใน Layer ที่อยู่สูงกว่า เช่น ภายใน Widget เราสามารถ import Features สองตัวเข้ามา แล้วเอา Feature ตัวหนึ่งส่งเป็น props หรือ children ให้กับอีกตัวหนึ่งได้

แต่คุณไม่สามารถ import Feature ตัวหนึ่งเข้าไปใน Feature อีกตัวหนึ่งได้โดยตรง อันนี้ผิดกฎ Import rule on layers เต็มๆ

แล้ว Atomic Design ล่ะ?​

เวอร์ชันปัจจุบันของ Methodology นี้ไม่ได้บังคับว่าต้องใช้ หรือห้ามใช้ Atomic Design ร่วมกับ Feature-Sliced Design

ยกตัวอย่างเช่น Atomic Design สามารถนำมาปรับใช้ได้ดี กับ ui segment ของ modules ต่างๆ

มีแหล่งข้อมูล/บทความเกี่ยวกับ FSD ให้อ่านเพิ่มไหม?​

จัดไป! ลองดูที่นี่ได้เลย https://github.com/feature-sliced/awesome

ทำไมถึงต้องใช้ Feature-Sliced Design?​

มันช่วยให้คุณและทีมมองเห็นภาพรวมของโปรเจกต์ได้เร็วขึ้น โดยเฉพาะในมุมของส่วนประกอบหลักที่สร้าง Value ให้กับระบบ การมี Architecture ที่เป็นมาตรฐานเดียวกันช่วยให้ Onboarding คนใหม่ได้ไวขึ้น แถมยังจบดราม่าเรื่องเถียงกันว่าจะวางโค้ดตรงไหนดีได้ด้วย ลองไปดูหน้า Motivation เพื่อทำความเข้าใจเพิ่มเดิมว่าทำไม FSD ถึงถูกสร้างขึ้นมา

มือใหม่ต้องแคร์เรื่อง Architecture/Methodology ด้วยเหรอ?​

ค่อนไปทาง "ต้อง" มากกว่า "ไม่"

ปกติแล้ว ถ้าเราออกแบบและทำโปรเจกต์คนเดียว ทุกอย่างก็มักจะราบรื่นดี แต่พอหยุดทำไปสักพัก หรือมี Dev คนใหม่เข้ามาในทีม นั่นแหละปัญหาจะเริ่มพาลมาเยือน

จะจัดการ Authorization Context ยังไง?​

มีคำตอบไว้ให้แล้วที่ หน้านี้