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

การย้ายจาก v2.0 ไป v2.1

การเปลี่ยนแปลงหลักใน v2.1 คือ Mental model ใหม่สำหรับการแยกส่วน Interface (Decomposition) — โดยเริ่มจาก Pages

ใน v2.0, FSD แนะนำให้ระบุ Entities และ Features ใน Interface ของคุณ โดยพิจารณาแม้กระทั่งชิ้นส่วนเล็กๆ ของการแสดงผล Entity และ Interactivity สำหรับการ Decomposition จากนั้นคุณจะสร้าง Widgets และ Pages จาก Entities และ Features ในโมเดลการ Decomposition นี้ Logic ส่วนใหญ่อยู่ใน Entities และ Features และ Pages เป็นเพียง Compositional layers ที่ไม่ได้มีความสำคัญอะไรในตัวเอง

ใน v2.1, เราแนะนำให้เริ่มจาก Pages และอาจจะหยุดแค่นั้นเลยก็ได้ คนส่วนใหญ่รู้วิธีแยกแอปเป็นหน้าๆ อยู่แล้ว และ Pages ก็เป็นจุดเริ่มต้นทั่วไปเมื่อพยายามหา Component ใน Codebase ในโมเดลการ Decomposition ใหม่นี้ คุณเก็บ UI และ Logic ส่วนใหญ่ไว้ในแต่ละหน้า โดยรักษา Foundation ที่ Reusable ไว้ใน Shared ถ้ามีความจำเป็นต้อง Reuse Business logic ข้ามหลายๆ หน้า คุณค่อยย้ายมันลงไป Layer ข้างล่าง

อีกส่วนเพิ่มเติมของ Feature-Sliced Design คือการทำให้ Cross-imports ระหว่าง Entities เป็นมาตรฐานด้วย @x-notation

วิธีการย้าย (How to migrate)​

ไม่มี Breaking changes ใน v2.1 ซึ่งหมายความว่าโปรเจกต์ที่เขียนด้วย FSD v2.0 ก็ยังเป็นโปรเจกต์ที่ถูกต้องใน FSD v2.1 อย่างไรก็ตาม เราเชื่อว่า Mental model ใหม่มีประโยชน์ต่อทีมและโดยเฉพาะการ Onboarding developer ใหม่มากกว่า ดังนั้นเราแนะนำให้ปรับ Decomposition ของคุณเล็กน้อย

Merge slices​

วิธีง่ายๆ ในการเริ่มคือรัน Linter ของเรา Steiger บนโปรเจกต์ Steiger ถูกสร้างด้วย Mental model ใหม่ และกฎที่มีประโยชน์ที่สุดจะเป็น:

  • insignificant-slice — ถ้า Entity หรือ Feature ถูกใช้ในหน้าเดียว กฎนี้จะแนะนำให้ Merge entity หรือ Feature นั้นเข้าไปในหน้านั้นทั้งก้อน
  • excessive-slicing — ถ้า Layer มี Slices มากเกินไป มักจะเป็นสัญญาณว่า Decomposition ละเอียดเกินไป (Too fine-grained) กฎนี้จะแนะนำให้ Merge หรือจัดกลุ่มบาง Slices เพื่อช่วยการนำทางในโปรเจกต์
npx steiger src

สิ่งนี้จะช่วยคุณระบุว่า Slices ไหนถูกใช้แค่ครั้งเดียว เพื่อที่คุณจะได้พิจารณาใหม่ว่ามันจำเป็นจริงๆ หรือเปล่า ในการพิจารณา ให้จำไว้ว่า Layer สร้าง Global namespace บางอย่างสำหรับ Slices ทั้งหมดข้างใน เหมือนที่คุณจะไม่ทำให้ Global namespace สกปรกด้วยตัวแปรที่ใช้แค่ครั้งเดียว คุณควรปฏิบัติกับพื้นที่ใน Namespace ของ Layer อย่างมีค่า และใช้อย่างประหยัด

ทำให้ Cross-imports เป็นมาตรฐาน​

ถ้าคุณมี Cross-imports ในโปรเจกต์ของคุณมาก่อน (เราไม่ตัดสินกัน!), ตอนนี้คุณสามารถใช้ประโยชน์จาก Notation ใหม่สำหรับการ Cross-importing ใน Feature-Sliced Design — @x-notation มันหน้าตาแบบนี้:

entities/B/some/file.ts
import type { EntityA } from "entities/A/@x/B";

สำหรับรายละเอียดเพิ่มเติม ตรวจสอบส่วน Public API for cross-imports ใน Reference