Vì cấu trúc được tiêu chuẩn hóa, các dự án trở nên thống nhất hơn, điều này làm cho việc onboard thành viên mới dễ dàng hơn cho nhóm. * **Ổn định trước các thay đổi và refactoring**
Một module trên một layer không thể sử dụng các module khác trên cùng layer, hoặc các layer ở trên.
Điều này cho phép bạn thực hiện các sửa đổi độc lập mà không có hậu quả không lường trước đối với phần còn lại của ứng dụng. * **Kiểm soát việc tái sử dụng logic**
Tùy thuộc vào layer, bạn có thể làm cho code rất có thể tái sử dụng hoặc rất cục bộ.
Điều này giữ sự cân bằng giữa việc tuân theo nguyên tắc **DRY** và tính thực tế. * **Định hướng vào nhu cầu kinh doanh và người dùng**
Ứng dụng được chia theo các domain kinh doanh và việc sử dụng ngôn ngữ kinh doanh được khuyến khích trong việc đặt tên, để bạn có thể thực hiện công việc sản phẩm hữu ích mà không cần hiểu đầy đủ tất cả các phần không liên quan khác của dự án. ## Áp dụng từng bước[](#incremental-adoption "Link trực tiếp đến heading") Nếu bạn có một codebase hiện có mà bạn muốn migrate sang FSD, chúng tôi đề xuất chiến lược sau. Chúng tôi thấy nó hữu ích trong kinh nghiệm migrate của chính mình. 1. Bắt đầu bằng cách từ từ định hình các layer App và Shared từng module một để tạo nền tảng. 2. Phân phối tất cả UI hiện có trên Widget và Page bằng cách sơ bộ, ngay cả khi chúng có dependency vi phạm các quy tắc của FSD. 3. Bắt đầu từ từ giải quyết các vi phạm import và cũng trích xuất Entity và có thể cả Feature. Nên tránh thêm các entity lớn mới trong khi refactor hoặc chỉ refactor một số phần nhất định của dự án. ## Bước tiếp theo[](#next-steps "Link trực tiếp đến heading") * **Muốn nắm bắt tốt cách tư duy trong FSD?** Xem [Tutorial](/documentation/vi/docs/get-started/tutorial.md). * **Bạn thích học từ ví dụ?** Chúng tôi có rất nhiều trong phần [Examples](/documentation/vi/examples.md). * **Bạn có câu hỏi?** Ghé thăm [Telegram chat](https://t.me/feature_sliced) của chúng tôi và nhận trợ giúp từ cộng đồng. --- # Tutorial ## Phần 1. Trên giấy[](#phần-1-trên-giấy "Link trực tiếp đến heading") Tutorial này sẽ xem xét một app thực tế, còn được biết đến với tên Conduit. Conduit là một bản clone cơ bản của [Medium](https://medium.com/) — nó cho phép bạn đọc và viết bài, cũng như bình luận trên các bài viết của người khác.  Đây là một ứng dụng khá nhỏ, vì vậy chúng ta sẽ giữ nó đơn giản và tránh phân tách quá mức. Rất có thể toàn bộ ứng dụng sẽ chỉ cần ba layer: **App**, **Pages**, và **Shared**. Nếu không, chúng ta sẽ giới thiệu thêm các layer khi cần. Sẵn sàng chưa? ### Bắt đầu bằng việc liệt kê các trang[](#bắt-đầu-bằng-việc-liệt-kê-các-trang "Link trực tiếp đến heading") Nếu nhìn vào ảnh chụp màn hình ở trên, chúng ta có thể giả định ít nhất những trang sau: * Trang chủ (article feed) * Đăng nhập và đăng ký * Đọc article * Chỉnh sửa article * Xem profile người dùng * Chỉnh sửa profile người dùng (user settings) Mỗi trang này sẽ trở thành một *slice* riêng trên *layer* Pages. Hãy nhớ lại từ phần tổng quan rằng slice chỉ đơn giản là các folder bên trong layer, và layer chỉ đơn giản là các folder có tên định sẵn như `pages`. Như vậy, folder Pages của chúng ta sẽ trông như thế này: ``` 📂 pages/ 📁 feed/ 📁 sign-in/ 📁 article-read/ 📁 article-edit/ 📁 profile/ 📁 settings/ ``` Sự khác biệt chính của Feature-Sliced Design so với cấu trúc code không được quy định là các pages không thể tham chiếu lẫn nhau. Nghĩa là, một page không thể import code từ trang khác. Điều này là do **quy tắc import trên các layer**: *Một module (file) trong một slice chỉ có thể import các slice khác khi chúng nằm trên các layer ở bên dưới.* Trong trường hợp này, một trang là một slice, vì vậy các module (file) bên trong trang này chỉ có thể tham chiếu code từ các layer bên dưới, không phải từ cùng layer Pages. ### Nhìn kỹ hơn vào feed[](#nhìn-kỹ-hơn-vào-feed "Link trực tiếp đến heading")  *Từ góc nhìn của người dùng ẩn danh*  *Từ góc nhìn của người dùng đã xác thực* Có ba khu vực động trên trang feed: 1. Các link đăng nhập với thông báo nếu bạn đã đăng nhập 2. Danh sách các tag kích hoạt việc lọc trong feed 3. Một/hai feed của các article, mỗi article có nút like Các link đăng nhập là một phần của header chung cho tất cả các trang, chúng ta sẽ xem xét nó riêng. #### Danh sách các tag[](#danh-sách-các-tag "Link trực tiếp đến heading") Để xây dựng danh sách các tag, chúng ta cần lấy các tag có sẵn, render mỗi tag dưới dạng chip, và lưu trữ các tag đã chọn trong client-side storage. Những thao tác này thuộc các danh mục "tương tác API", "giao diện người dùng", và "lưu trữ". Trong Feature-Sliced Design, code được phân tách theo mục đích sử dụng *segment*. Segment là các folder trong slice, và chúng có thể có tên tùy ý để mô tả mục đích, nhưng một số mục đích rất phổ biến nên có quy ước cho một số tên segment nhất định: * 📂 `api/` cho các tương tác backend * 📂 `ui/` cho code xử lý rendering và giao diện * 📂 `model/` cho storage và business logic * 📂 `config/` cho feature flag, biến môi trường và các hình thức cấu hình khác Chúng ta sẽ đặt code lấy tag vào `api`, component tag vào `ui`, và tương tác storage vào `model`. #### Các article[](#các-article "Link trực tiếp đến heading") Sử dụng cùng nguyên tắc nhóm, chúng ta có thể phân tách feed của các article thành ba segment tương tự: * 📂 `api/`: lấy các article được phân trang với số lượng like; thích một article * 📂 `ui/`: * danh sách tab có thể render thêm tab nếu có tag được chọn * article riêng lẻ * phân trang chức năng * 📂 `model/`: client-side storage của các article hiện tại được tải và trang hiện tại (nếu cần) ### Tái sử dụng code chung[](#tái-sử-dụng-code-chung "Link trực tiếp đến heading") Hầu hết các trang có ý định rất khác nhau, nhưng một số thứ nhất định vẫn giữ nguyên trong toàn bộ app — ví dụ, UI kit tuân thủ design language, hoặc quy ước trên backend rằng mọi thứ được thực hiện bằng REST API với cùng phương thức xác thực. Vì các slice được thiết kế để tách biệt, việc tái sử dụng code được hỗ trợ bởi một layer thấp hơn, **Shared**. Shared khác với các layer khác ở chỗ nó chứa các segment, không phải slice. Theo cách này, layer Shared có thể được coi là sự kết hợp giữa một layer và một slice. Thông thường, code trong Shared không được lên kế hoạch trước, mà được trích xuất trong quá trình phát triển, vì chỉ trong quá trình phát triển mới rõ phần nào của code thực sự được chia sẻ. Tuy nhiên, vẫn hữu ích khi ghi nhớ loại code nào thuộc về Shared: * 📂 `ui/` — UI kit, giao diện thuần túy, không có business logic. Ví dụ, button, modal dialog, form input. * 📂 `api/` — wrapper tiện lợi xung quanh các primitive tạo request (như `fetch()` trên Web) và, tùy chọn, các function để kích hoạt request cụ thể theo đặc tả backend. * 📂 `config/` — phân tích biến môi trường * 📂 `i18n/` — cấu hình hỗ trợ ngôn ngữ * 📂 `router/` — routing primitive và route constant Đó chỉ là một vài ví dụ về tên segment trong Shared, nhưng bạn có thể bỏ qua bất kỳ segment nào hoặc tạo segment của riêng bạn. Điều quan trọng duy nhất cần nhớ khi tạo segment mới là tên segment nên mô tả **mục đích (tại sao), không phải bản chất (cái gì)**. Các tên như "components", "hooks", "modals" *không nên* được sử dụng vì chúng mô tả những file này là gì, nhưng không giúp điều hướng code bên trong. Điều này yêu cầu mọi người trong team phải đào sâu vào từng file trong những folder như vậy và cũng giữ code không liên quan gần nhau, dẫn đến việc refactoring ảnh hưởng đến các khu vực rộng lớn của code và do đó làm cho việc review code và testing khó khăn hơn. ### Định nghĩa public API nghiêm ngặt[](#định-nghĩa-public-api-nghiêm-ngặt "Link trực tiếp đến heading") Trong ngữ cảnh của Feature-Sliced Design, thuật ngữ *public API* đề cập đến một slice hoặc segment khai báo những gì có thể được import từ nó bởi các module khác trong dự án. Ví dụ, trong JavaScript đó có thể là file `index.js` re-export các object từ các file khác trong slice. Điều này cho phép tự do refactoring code bên trong slice miễn là hợp đồng với thế giới bên ngoài (tức là public API) vẫn giữ nguyên. Đối với layer Shared không có slice, thường thuận tiện hơn khi định nghĩa public API riêng cho mỗi segment thay vì định nghĩa một index duy nhất cho mọi thứ trong Shared. Điều này giữ các import từ Shared được tổ chức tự nhiên theo ý định. Đối với các layer khác có slice, ngược lại — thường thực tế hơn khi định nghĩa một index cho mỗi slice và để slice quyết định tập hợp segment riêng của nó mà thế giới bên ngoài không biết vì các layer khác thường có ít export hơn nhiều. Các slice/segment của chúng ta sẽ xuất hiện với nhau như sau: ``` 📂 pages/ 📂 feed/ 📄 index 📂 sign-in/ 📄 index 📂 article-read/ 📄 index 📁 … 📂 shared/ 📂 ui/ 📄 index 📂 api/ 📄 index 📁 … ``` Bất cứ thứ gì bên trong các folder như `pages/feed` hoặc `shared/ui` chỉ được biết đến bởi những folder đó, và các file khác không nên dựa vào cấu trúc nội bộ của những folder này. ### Khối UI lớn được tái sử dụng[](#khối-ui-lớn-được-tái-sử-dụng "Link trực tiếp đến heading") Trước đó chúng ta đã ghi chú để xem lại header xuất hiện trên mỗi trang. Xây dựng lại từ đầu trên mỗi trang sẽ không thực tế, vì vậy việc muốn tái sử dụng nó là điều tự nhiên. Chúng ta đã có Shared để hỗ trợ tái sử dụng code, tuy nhiên, có một lưu ý khi đặt các khối UI lớn trong Shared — layer Shared không được biết về bất kỳ layer nào ở trên. Giữa Shared và Pages có ba layer khác: Entities, Features, và Widgets. Một số dự án có thể có thứ gì đó trong những layer đó mà họ cần trong một khối có thể tái sử dụng lớn, và điều đó có nghĩa là chúng ta không thể đặt khối có thể tái sử dụng đó trong Shared, nếu không nó sẽ import từ các layer trên, điều này bị cấm. Đó là lúc layer Widgets xuất hiện. Nó được đặt phía trên Shared, Entities, và Features, vì vậy nó có thể sử dụng tất cả chúng. Trong trường hợp của chúng ta, header rất đơn giản — đó là logo tĩnh và điều hướng cấp cao nhất. Điều hướng cần thực hiện request đến API để xác định người dùng hiện tại có đăng nhập hay không, nhưng điều đó có thể được xử lý bằng một import đơn giản từ segment `api`. Do đó, chúng ta sẽ giữ header của mình trong Shared. ### Nhìn kỹ vào trang có form[](#nhìn-kỹ-vào-trang-có-form "Link trực tiếp đến heading") Hãy cũng kiểm tra một trang được thiết kế để chỉnh sửa, không phải đọc. Ví dụ, trình soạn thảo article:  Nó trông đơn giản, nhưng chứa một số khía cạnh của phát triển ứng dụng mà chúng ta chưa khám phá — validation form, trạng thái lỗi, và data persistence. Nếu chúng ta xây dựng trang này, chúng ta sẽ lấy một số input và button từ Shared và ghép thành một form trong segment `ui` của trang này. Sau đó, trong segment `api`, chúng ta sẽ định nghĩa một mutation request để tạo article trên backend. Để validate request trước khi gửi, chúng ta cần một validation schema, và vị trí tốt cho nó là segment `model`, vì nó là data model. Ở đó chúng ta sẽ tạo ra các thông báo lỗi và hiển thị chúng bằng một component khác trong segment `ui`. Để cải thiện trải nghiệm người dùng, chúng ta cũng có thể persist các input để ngăn mất dữ liệu vô tình. Đây cũng là công việc của segment `model`. ### Tóm tắt[](#tóm-tắt "Link trực tiếp đến heading") Chúng ta đã kiểm tra một số trang và phác thảo cấu trúc sơ bộ cho ứng dụng của mình: 1. Layer Shared 1. `ui` sẽ chứa UI kit có thể tái sử dụng của chúng ta 2. `api` sẽ chứa các tương tác primitive với backend 3. Phần còn lại sẽ được sắp xếp theo yêu cầu 2. Layer Pages — mỗi trang là một slice riêng biệt 1. `ui` sẽ chứa chính trang đó và tất cả các phần của nó 2. `api` sẽ chứa data fetching chuyên biệt hơn, sử dụng `shared/api` 3. `model` có thể chứa client-side storage của dữ liệu mà chúng ta sẽ hiển thị Hãy bắt đầu xây dựng! ## Phần 2. Trong code[](#phần-2-trong-code "Link trực tiếp đến heading") Bây giờ chúng ta đã có kế hoạch, hãy đưa nó vào thực hành. Chúng ta sẽ sử dụng React và [Remix](https://remix.run). Có một template sẵn sàng cho dự án này, clone nó từ GitHub để có được khởi đầu:
conduit
A place to share your knowledge.
{article.author.username}
{new Date(article.createdAt).toLocaleDateString(undefined, {
dateStyle: "long",
})}
{article.title}
{article.description}
Read more...-
{article.tagList.map((tag) => (
- {tag} ))}
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
Popular Tags
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
Popular Tags
Sign up
Have an account?
{registerData?.error && (-
{registerData.error.errors.body.map((error) => (
- {error} ))}
Sign in
Need an account?
{signInData?.error && (-
{signInData.error.errors.body.map((error) => (
- {error} ))}
Popular Tags
conduit
A place to share your knowledge.
{article.author.username}
{new Date(article.createdAt).toLocaleDateString(undefined, {
dateStyle: "long",
})}
{article.title}
{article.description}
Read more...-
{article.tagList.map((tag) => (
- {tag} ))}
{article.article.title}
{article.article.body}
-
{article.article.tagList.map((tag) => (
- {tag} ))}
{currentUser !== null ? (
) : (
)}
{comments.comments.map((comment) => (
{comment.author.username}
{comment.createdAt}
{comment.author.username === currentUser?.username && (
)}
))}
);
}
```
Và với điều đó, trình đọc article của chúng ta cũng hoàn thành! Các button theo dõi tác giả, thích bài viết, và để lại comment giờ đây sẽ hoạt động như mong đợi.
Trình đọc article với các button hoạt động để thích và theo dõi
### Trình chỉnh sửa article[](#trình-chỉnh-sửa-article "Link trực tiếp đến heading")
Đây là trang cuối cùng mà chúng ta sẽ đề cập trong tutorial này, và phần thú vị nhất ở đây là cách chúng ta sẽ validate dữ liệu form.
Chính trang, `article-edit/ui/ArticleEditPage.tsx`, sẽ khá đơn giản, độ phức tạp bổ sung được cất giấu trong hai component khác:
pages/article-edit/ui/ArticleEditPage.tsx
```
import { Form, useLoaderData } from "@remix-run/react";
import type { loader } from "../api/loader";
import { TagsInput } from "./TagsInput";
import { FormErrors } from "./FormErrors";
export function ArticleEditPage() {
const article = useLoaderDataSign in or Sign up to add comments on this article.
{comment.body}
-
{actionData.errors.map((error) => (
- {error} ))}
{tagListState.map((tag) => (
[" ", "Enter"].includes(e.key) && removeTag(tag)
}
onClick={() => removeTag(tag)}
>{" "}
{tag}
))}
);
}
```
Bây giờ, cho phần API. Loader nên nhìn vào URL, và nếu nó chứa article slug, có nghĩa là chúng ta đang chỉnh sửa article hiện có, và dữ liệu của nó nên được tải. Nếu không, trả về không có gì. Hãy tạo loader đó:
pages/article-edit/api/loader.ts
```
import { json, type LoaderFunctionArgs } from "@remix-run/node";
import type { FetchResponse } from "openapi-fetch";
import { GET, requireUser } from "shared/api";
async function throwAnyErrorsĐây là giải pháp đơn giản nhất, nhưng nó nhanh chóng trở nên cồng kềnh, và nếu bạn không có type safety, dễ quên. Nó cũng không tương thích với middlewares pattern cho API client trong Shared. 2. **Expose token cho toàn bộ app với context hoặc global store như `localStorage`**
Key để retrieve token sẽ được giữ trong `shared/api` để API client có thể truy cập nó. Reactive store của token sẽ được export từ User entity, và context provider (nếu cần) sẽ được thiết lập trên layer App. Điều này cho nhiều tự do hơn để thiết kế API client, tuy nhiên, nó tạo ra implicit dependency trên các layers cao hơn để cung cấp context. Khi theo cách tiếp cận này, hãy cân nhắc cung cấp các error messages hữu ích nếu context hoặc `localStorage` không được thiết lập chính xác. 3. **Inject token vào API client mỗi khi nó thay đổi**
Nếu store của bạn là reactive, bạn có thể tạo subscription sẽ cập nhật token store của API client mỗi khi store trong entity thay đổi. Điều này tương tự như giải pháp trước ở chỗ chúng đều tạo implicit dependency trên các layers cao hơn, nhưng cái này imperative hơn ("push"), trong khi cái trước declarative hơn ("pull"). Khi bạn vượt qua thách thức expose token được lưu trữ trong model của entity, bạn có thể encode nhiều business logic liên quan đến token management. Ví dụ, segment `model` có thể chứa logic để invalidate token sau một khoảng thời gian nhất định, hoặc refresh token khi nó expires. Để thực sự thực hiện requests đến backend, sử dụng segment `api` của User entity hoặc `shared/api`. ### Trong Pages/Widgets (không được khuyến nghị)[](#trong-pageswidgets-không-được-khuyến-nghị "Link trực tiếp đến heading") Không được khuyến khích lưu trữ app-wide state như access token trong pages hoặc widgets. Tránh đặt token store của bạn trong segment `model` của login page, thay vào đó hãy chọn từ hai giải pháp đầu tiên, Shared hoặc Entities. ## Logout và token invalidation[](#logout-và-token-invalidation "Link trực tiếp đến heading") Thông thường, các apps không có một page hoàn chỉnh cho logging out, nhưng logout functionality vẫn rất quan trọng. Nó bao gồm authenticated request đến backend và cập nhật token store. Nếu bạn lưu trữ tất cả requests trong `shared/api`, hãy giữ logout request function ở đó, gần login function. Nếu không, hãy cân nhắc giữ logout request function gần button kích hoạt nó. Ví dụ, nếu bạn có header widget xuất hiện trên mỗi page và chứa logout link, hãy đặt request đó trong segment `api` của widget đó. Cập nhật token store sẽ phải được trigger từ vị trí của logout button, như header widget. Bạn có thể kết hợp request và store update trong segment `model` của widget đó. ### Automatic logout[](#automatic-logout "Link trực tiếp đến heading") Đừng quên xây dựng các failsafes cho khi request log out thất bại, hoặc request refresh login token thất bại. Trong cả hai trường hợp này, bạn nên clear token store. Nếu bạn giữ token trong Entities, code này có thể được đặt trong segment `model` vì nó là pure business logic. Nếu bạn giữ token trong Shared, đặt logic này trong `shared/api` có thể làm segment phình to và pha loãng mục đích của nó. Nếu bạn nhận thấy rằng API segment của mình chứa nhiều thứ không liên quan, hãy cân nhắc tách logic token management thành segment khác, ví dụ, `shared/auth`. --- # Autocomplete WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/170) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > Về decomposition theo layers ## Xem thêm[](#xem-thêm "Link trực tiếp đến heading") * [(Discussion) Về việc áp dụng phương pháp luận cho việc lựa chọn với loaded dictionaries](https://github.com/feature-sliced/documentation/discussions/65#discussioncomment-480807) --- # Browser API WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/197) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > Về việc làm việc với Browser API: localStorage, audio Api, bluetooth API, v.v. > > Bạn có thể hỏi về ý tưởng chi tiết hơn [@alex\_novi](https://t.me/alex_novich) --- # CMS WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/172) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* ## Features có thể khác nhau[](#features-có-thể-khác-nhau "Link trực tiếp đến heading") Trong một số dự án, tất cả functionality được tập trung trong data từ server >
*🍰 Stay tuned!* > Errors, Alerts, Notifications, ... --- # i18n WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/171) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* ## Đặt ở đâu? Làm thế nào để làm việc với điều này?[](#đặt-ở-đâu-làm-thế-nào-để-làm-việc-với-điều-này "Link trực tiếp đến heading") *
*🍰 Stay tuned!* > About ways to initialize metrics in the application --- # Monorepositories WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/221) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > About applicability for mono repositories, about bff, about microapps ## See also[](#see-also "Link trực tiếp đến heading") * [(Discussion) About mono repositories and plug-ins-packages](https://github.com/feature-sliced/documentation/discussions/50) * [(Thread) About the application for a mono repository](https://t.me/feature_sliced/2412) --- # Page layouts Hướng dẫn này xem xét abstraction của một *page layout* — khi nhiều pages chia sẻ cùng một cấu trúc tổng thể, và chỉ khác nhau ở main content. thông tin Câu hỏi của bạn không được đề cập trong hướng dẫn này? Đăng câu hỏi của bạn bằng cách để lại feedback trên bài viết này (nút xanh ở bên phải) và chúng tôi sẽ cân nhắc mở rộng hướng dẫn này! ## Simple layout[](#simple-layout "Link trực tiếp đến heading") Layout đơn giản nhất có thể được nhìn thấy trên trang bạn đang xem đây. Nó có header với site navigation, hai sidebars, và footer với external links. Không có business logic phức tạp, và các phần dynamic duy nhất là sidebars và switchers ở phía bên phải của header. Layout như vậy có thể được đặt hoàn toàn trong `shared/ui` hoặc trong `app/layouts`, với props điền vào content cho các sidebars: shared/ui/layout/Layout.tsx ``` import { Link, Outlet } from "react-router-dom"; import { useThemeSwitcher } from "./useThemeSwitcher"; export function Layout({ siblingPages, headings }) { const [theme, toggleTheme] = useThemeSwitcher(); return (
Điều này rất tốt cho các routers hỗ trợ nesting, vì bạn có thể nhóm các routes nhất định và chỉ áp dụng layout cho chúng. 2. **Chỉ cần copy-paste nó**
Xu hướng abstract code thường bị đánh giá quá cao. Điều này đặc biệt đúng cho các layouts, hiếm khi thay đổi. Tại một thời điểm nào đó, nếu một trong những pages này cần thay đổi, bạn có thể đơn giản thực hiện thay đổi mà không cần thiết ảnh hưởng đến các pages khác. Nếu bạn lo lắng rằng ai đó có thể quên cập nhật các pages khác, bạn luôn có thể để lại comment mô tả mối quan hệ giữa các pages. Nếu không có điều nào ở trên áp dụng được, có hai giải pháp để bao gồm widget trong layout: 1. **Sử dụng render props hoặc slots**
Hầu hết các frameworks cho phép bạn pass một phần UI từ bên ngoài. Trong React, được gọi là [render props](https://www.patterns.dev/react/render-props-pattern/), trong Vue được gọi là [slots](https://vuejs.org/guide/components/slots). 2. **Chuyển layout đến layer App**
Bạn cũng có thể lưu trữ layout của mình trên layer App, ví dụ, trong `app/layouts`, và compose bất kỳ widgets nào bạn muốn. ## Đọc thêm[](#đọc-thêm "Link trực tiếp đến heading") * Có một ví dụ về cách xây dựng layout với authentication sử dụng React và Remix (tương đương với React Router) trong [tutorial](/documentation/vi/docs/get-started/tutorial.md). --- # Desktop/Touch platforms WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/198) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > About the application of the methodology for desktop/touch --- # SSR WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/173) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > About the implementation of SSR using the methodology --- # Theme WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/207) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* ## Where should I put my work with the theme and palette?[](#where-should-i-put-my-work-with-the-theme-and-palette "Link trực tiếp đến heading") >
Bạn có thể làm cho types của mình chấp nhận type arguments làm slots cho các kết nối với entities khác, và thậm chí áp dụng constraints trên những slots đó. Ví dụ: entities/song/model/song.ts ``` interface Song
Để thực hiện cross-imports giữa các entities trong FSD, bạn có thể sử dụng public API đặc biệt dành riêng cho mỗi slice sẽ cross-importing. Ví dụ, nếu chúng ta có entities `song`, `artist`, và `playlist`, và hai cái sau cần tham chiếu `song`, chúng ta có thể tạo hai public APIs đặc biệt cho cả hai trong entity `song` với ký hiệu `@x`: * 📂 entities * 📂 song * 📂 @x * 📄 artist.ts (public API cho entity `artist` để import) * 📄 playlist.ts (public API cho entity `playlist` để import) * 📄 index.ts (public API thông thường) Nội dung của file `📄 entities/song/@x/artist.ts` tương tự như `📄 entities/song/index.ts`: entities/song/@x/artist.ts ``` export type { Song } from "../model/song.ts"; ``` Sau đó `📄 entities/artist/model/artist.ts` có thể import `Song` như thế này: entities/artist/model/artist.ts ``` import type { Song } from "entities/song/@x/artist"; export interface Artist { name: string; songs: Array
*🍰 Stay tuned!* > Figma, brand uikit, templates, adaptability to brands ## See also[](#see-also "Link trực tiếp đến heading") * [(Thread) About the application for white-labels (branded) projects](https://t.me/feature_sliced/1543) * [(Presentation) About white-labels apps and design](http://yadi.sk/i/5IdhzsWrpO3v4Q) --- # Cross-imports WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/220) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* > Cross-imports xuất hiện khi layer hoặc abstraction bắt đầu đảm nhận quá nhiều trách nhiệm hơn nó nên. Đó là lý do tại sao phương pháp luận xác định các layers mới cho phép bạn tách rời những cross-imports này ## Xem thêm[](#xem-thêm "Link trực tiếp đến heading") * [(Thread) Về tính không thể tránh khỏi của cross-ports](https://t.me/feature_sliced/4515) * [(Thread) Về việc giải quyết cross-ports trong entities](https://t.me/feature_sliced/3678) * [(Thread) Về cross-imports và responsibility](https://t.me/feature_sliced/3287) * [(Thread) Về imports giữa các segments](https://t.me/feature_sliced/4021) * [(Thread) Về cross-imports bên trong shared](https://t.me/feature_sliced/3618) --- # Desegmented WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/148) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* ## Tình huống[](#tình-huống "Link trực tiếp đến heading") Rất thường xuyên xảy ra tình huống trên các project khi các module liên quan đến một domain cụ thể từ lĩnh vực chủ đề bị phân tách không cần thiết và nằm rải rác khắp project ``` ├── components/ | ├── DeliveryCard | ├── DeliveryChoice | ├── RegionSelect | ├── UserAvatar ├── actions/ | ├── delivery.js | ├── region.js | ├── user.js ├── epics/ | ├── delivery.js | ├── region.js | ├── user.js ├── constants/ | ├── delivery.js | ├── region.js | ├── user.js ├── helpers/ | ├── delivery.js | ├── region.js | ├── user.js ├── entities/ | ├── delivery/ | | ├── getters.js | | ├── selectors.js | ├── region/ | ├── user/ ``` ## Vấn đề[](#vấn-đề "Link trực tiếp đến heading") Vấn đề thể hiện ít nhất là vi phạm nguyên tắc **High Cohesion** và kéo dài quá mức **trục thay đổi** ## Nếu bỏ qua[](#nếu-bỏ-qua "Link trực tiếp đến heading") * Nếu cần chạm vào logic, ví dụ delivery - chúng ta sẽ phải nhớ rằng nó nằm ở nhiều nơi và phải chạm vào nhiều chỗ trong code - điều này kéo dài không cần thiết **Trục thay đổi** của chúng ta * Nếu cần nghiên cứu logic của user, chúng ta sẽ phải đi khắp project để tìm hiểu chi tiết **actions, epics, constants, entities, components** - thay vì để nó nằm ở một chỗ * Các liên kết ngầm và sự mất kiểm soát của domain area đang phát triển * Với cách tiếp cận này, mắt rất dễ bị mờ đi và bạn có thể không nhận ra khi chúng ta "tạo constants vì constants", tạo ra một đống rác trong thư mục tương ứng của project ## Giải pháp[](#giải-pháp "Link trực tiếp đến heading") Đặt tất cả các module liên quan đến một domain/use case cụ thể - ngay cạnh nhau Để khi nghiên cứu một module cụ thể, tất cả các thành phần của nó nằm cạnh nhau, không bị rải rác khắp project > Điều này cũng tăng khả năng khám phá và sự rõ ràng của code base và mối quan hệ giữa các module ``` - ├── components/ - | ├── DeliveryCard - | ├── DeliveryChoice - | ├── RegionSelect - | ├── UserAvatar - ├── actions/ - | ├── delivery.js - | ├── region.js - | ├── user.js - ├── epics/{...} - ├── constants/{...} - ├── helpers/{...} ├── entities/ | ├── delivery/ + | | ├── ui/ # ~ components/ + | | | ├── card.js + | | | ├── choice.js + | | ├── model/ + | | | ├── actions.js + | | | ├── constants.js + | | | ├── epics.js + | | | ├── getters.js + | | | ├── selectors.js + | | ├── lib/ # ~ helpers | ├── region/ | ├── user/ ``` ## Xem thêm[](#xem-thêm "Link trực tiếp đến heading") * [(Article) Về Low Coupling và High Cohesion một cách rõ ràng](https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/) * [(Article) Low Coupling và High Cohesion. Law of Demeter](https://medium.com/german-gorelkin/low-coupling-high-cohesion-d36369fb1be9) --- # Routing WIP Bài viết đang trong quá trình hoàn thiện Để đẩy nhanh việc phát hành bài viết, bạn có thể: * 📢 Chia sẻ phản hồi của bạn [tại bài viết (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/169) * 💬 Thu thập tài liệu liên quan [về chủ đề từ chat](https://t.me/feature_sliced) * ⚒️ Đóng góp [bằng bất kỳ cách nào khác](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*🍰 Stay tuned!* ## Tình huống[](#tình-huống "Link trực tiếp đến heading") URL đến các trang được hardcode trong các layer bên dưới pages entities/post/card ```
Nhấp vào mũi tên xanh để mở folder. 📁 src * 📁 actions * 📁 product * 📁 order * 📁 api * 📁 components * 📁 containers * 📁 constants * 📁 i18n * 📁 modules * 📁 helpers * 📁 routes * 📁 products.jsx * 📄 products.\[id].jsx * 📁 utils * 📁 reducers * 📁 selectors * 📁 styles * 📄 App.jsx * 📄 index.js ## Trước khi bạn bắt đầu[](#before-you-start "Link trực tiếp đến heading") Câu hỏi quan trọng nhất để hỏi team của bạn khi cân nhắc chuyển sang Feature-Sliced Design là — *bạn có thực sự cần nó không?* Chúng tôi yêu Feature-Sliced Design, nhưng thậm chí chúng tôi cũng nhận ra rằng một số dự án hoàn toàn ổn mà không cần nó. Đây là một số lý do để cân nhắc thực hiện sự chuyển đổi: 1. Thành viên mới trong team phàn nàn rằng khó đạt đến mức độ hiệu quả 2. Thực hiện modifications ở một phần của code **thường** gây ra phần khác không liên quan bị hỏng 3. Thêm functionality mới khó khăn do số lượng lớn các thứ bạn cần suy nghĩ **Tránh chuyển sang FSD trái với ý muốn của các đồng đội**, ngay cả khi bạn là lead.
Trước tiên, hãy thuyết phục các đồng đội rằng lợi ích vượt trội so với chi phí migration và chi phí học một architecture mới thay vì architecture đã được thiết lập. Cũng cần nhớ rằng bất kỳ loại thay đổi kiến trúc nào cũng không ngay lập tức có thể quan sát được đối với quản lý. Hãy đảm bảo họ đồng ý với việc chuyển đổi trước khi bắt đầu và giải thích cho họ tại sao điều này có thể có lợi cho dự án. mẹo Nếu bạn cần giúp để thuyết phục project manager rằng FSD có lợi, hãy cân nhắc một số điểm này: 1. Migration sang FSD có thể diễn ra dần dần, vì vậy nó sẽ không dừng việc phát triển các tính năng mới 2. Một architecture tốt có thể giảm đáng kể thời gian mà một developer mới cần để trở nên hiệu quả 3. FSD là một architecture được tài liệu hóa, vì vậy team không phải liên tục dành thời gian để duy trì documentation riêng của họ *** Nếu bạn đã quyết định bắt đầu migration, thì điều đầu tiên bạn muốn làm là thiết lập một alias cho `📁 src`. Điều này sẽ hữu ích sau này khi tham chiếu đến các folder tầng cao. Chúng tôi sẽ coi `@` là alias cho `./src` trong phần còn lại của hướng dẫn này. ## Bước 1. Chia code theo pages[](#divide-code-by-pages "Link trực tiếp đến heading") Hầu hết custom architectures đã có sự phân chia theo pages, dù logic nhỏ hay lớn. Nếu bạn đã có `📁 pages`, bạn có thể bỏ qua bước này. Nếu bạn chỉ có `📁 routes`, hãy tạo `📁 pages` và cố gắng di chuyển càng nhiều component code từ `📁 routes` càng tốt. Lý tưởng là bạn sẽ có một route nhỏ và một page lớn hơn. Khi đang di chuyển code, hãy tạo một folder cho mỗi page và thêm một index file: ghi chú Hiện tại, không sao nếu các page của bạn tham chiếu lẫn nhau. Bạn có thể giải quyết điều đó sau, nhưng hiện tại, hãy tập trung vào việc thiết lập một sự phân chia rõ ràng theo pages. Route file: src/routes/products.\[id].js ``` export { ProductPage as default } from "@/pages/product" ``` Page index file: src/pages/product/index.js ``` export { ProductPage } from "./ProductPage.jsx" ``` Page component file: src/pages/product/ProductPage.jsx ``` export function ProductPage(props) { return ; } ``` ## Bước 2. Tách mọi thứ khác ra khỏi pages[](#separate-everything-else-from-pages "Link trực tiếp đến heading") Tầo folder `📁 src/shared` và di chuyển mọi thứ không import từ `📁 pages` hoặc `📁 routes` vào đó. Tạo folder `📁 src/app` và di chuyển mọi thứ có import pages hoặc routes vào đó, bao gồm cả chính các routes. Hãy nhớ rằng Shared layer không có slices, vì vậy không sao nếu các segment import lẫn nhau. Cuối cùng bạn sẽ có được cấu trúc tệp như thế này: 📁 src * 📁 app * 📁 routes * 📄 products.jsx * 📄 products.\[id].jsx * 📄 App.jsx * 📄 index.js * 📁 pages * 📁 product * 📁 ui * 📄 ProductPage.jsx * 📄 index.js * 📁 catalog * 📁 shared * 📁 actions * 📁 api * 📁 components * 📁 containers * 📁 constants * 📁 i18n * 📁 modules * 📁 helpers * 📁 utils * 📁 reducers * 📁 selectors * 📁 styles ## Bước 3. Giải quyết cross-imports giữa các pages[](#tackle-cross-imports-between-pages "Link trực tiếp đến heading") Tìm tất cả các trường hợp mà một page đang import từ page khác và làm một trong hai điều sau: 1. Copy-paste code được import vào page phụ thuộc để loại bỏ dependency 2. Di chuyển code vào một segment thích hợp trong Shared: * nếu nó là một phần của UI kit, di chuyển vào `📁 shared/ui`; * nếu nó là một configuration constant, di chuyển vào `📁 shared/config`; * nếu nó là một backend interaction, di chuyển vào `📁 shared/api`. ghi chú **Copy-pasting không sai về mặt kiến trúc**, thực tế, đôi khi duplicate có thể chính xác hơn là abstract thành một reusable module mới. Lý do là đôi khi các phần shared của pages bắt đầu tách rời, và bạn không muốn các dependency cản trở bạn trong những trường hợp này. Tuy nhiên, vẫn còn ý nghĩa trong nguyên tắc DRY ("don't repeat yourself"), vì vậy hãy đảm bảo bạn không copy-paste business logic. Nếu không bạn sẽ cần phải nhớ sửa bug ở nhiều nơi cùng lúc. ## Bước 4. Giải nén Shared layer[](#unpack-shared-layer "Link trực tiếp đến heading") Bạn có thể có rất nhiều thứ trong Shared layer ở bước này, và nói chung bạn muốn tránh điều đó. Lý do là Shared layer có thể là dependency cho bất kỳ layer nào khác trong codebase của bạn, vì vậy việc thay đổi code đó tự động dễ gây ra các hậu quả ngoài ý muốn hơn. Tìm tất cả các object chỉ được sử dụng trên một page và di chuyển nó vào slice của page đó. Và đúng rồi, *điều đó cũng áp dụng cho actions, reducers, và selectors*. Không có lợi ích gì khi nhóm tất cả actions lại với nhau, nhưng có lợi ích khi đặt các relevant actions gần với nơi sử dụng chúng. Cuối cùng bạn sẽ có được cấu trúc tệp như thế này: 📁 src * 📁 app (unchanged) * 📁 pages * 📁 product * 📁 actions * 📁 reducers * 📁 selectors * 📁 ui * 📄 Component.jsx * 📄 Container.jsx * 📄 ProductPage.jsx * 📄 index.js * 📁 catalog * 📁 shared (only objects that are reused) * 📁 actions * 📁 api * 📁 components * 📁 containers * 📁 constants * 📁 i18n * 📁 modules * 📁 helpers * 📁 utils * 📁 reducers * 📁 selectors * 📁 styles ## Bước 5. Tổ chức code theo mục đích kỹ thuật[](#organize-by-technical-purpose "Link trực tiếp đến heading") Trong FSD, việc phân chia theo mục đích kỹ thuật được thực hiện với *segments*. Có một số loại phổ biến: * `ui` — mọi thứ liên quan đến hiển thị UI: UI components, date formatters, styles, v.v. * `api` — các tương tác backend: request functions, data types, mappers, v.v. * `model` — data model: schemas, interfaces, stores, và business logic. * `lib` — library code mà các module khác trên slice này cần. * `config` — các file cấu hình và feature flags. Bạn cũng có thể tạo các segment riêng của mình nếu cần. Hãy đảm bảo không tạo các segment nhóm code theo những gì nó là, như `components`, `actions`, `types`, `utils`. Thay vào đó, hãy nhóm code theo những gì nó dành cho. Tổ chức lại các pages của bạn để tách biệt code theo segments. Bạn nên đã có một `ui` segment, bây giờ là lúc tạo các segment khác, như `model` cho actions, reducers, và selectors của bạn, hoặc `api` cho thunks và mutations của bạn. Cũng tổ chức lại Shared layer để loại bỏ các folder này: * `📁 components`, `📁 containers` — phần lớn nó nên trở thành `📁 shared/ui`; * `📁 helpers`, `📁 utils` — nếu còn một số helpers được tái sử dụng, hãy nhóm chúng lại theo function, như dates hoặc type conversions, và di chuyển các nhóm này vào `📁 shared/lib`; * `📁 constants` — lại, nhóm theo function và di chuyển vào `📁 shared/config`. ## Các bước tùy chọn[](#optional-steps "Link trực tiếp đến heading") ### Bước 6. Tạo entities/features từ các Redux slice được sử dụng trên nhiều pages[](#form-entities-features-from-redux "Link trực tiếp đến heading") Thường thì các Redux slice được tái sử dụng này sẽ mô tả điều gì đó liên quan đến nghiệp vụ, ví dụ như products hoặc users, vì vậy chúng có thể được di chuyển vào Entities layer, một entity một folder. Nếu Redux slice liên quan đến một action mà người dùng của bạn muốn thực hiện trong app, như comments, thì bạn có thể di chuyển nó vào Features layer. Entities và features có ý định độc lập với nhau. Nếu business domain của bạn chứa các kết nối bẩm sinh giữa các entity, hãy tham khảo [hướng dẫn về business entities](/documentation/vi/docs/guides/examples/types.md#business-entities-and-their-cross-references) để có lời khuyên về cách tổ chức các kết nối này. Các API functions liên quan đến các slice này có thể giữ lại trong `📁 shared/api`. ### Bước 7. Refactor các modules của bạn[](#refactor-your-modules "Link trực tiếp đến heading") Folder `📁 modules` thường được sử dụng cho business logic, vì vậy nó đã khá tương tự về bản chất với Features layer từ FSD. Một số module cũng có thể mô tả những khối lớn của UI, như app header. Trong trường hợp đó, bạn nên migration chúng vào Widgets layer. ### Bước 8. Tạo một UI foundation sạch trong `shared/ui`[](#form-clean-ui-foundation "Link trực tiếp đến heading") `📁 shared/ui` lý tưởng nên chứa một tập hợp các UI elements không có business logic nào được encode trong chúng. Chúng cũng nên có tính tái sử dụng cao. Refactor các UI components đã từng nằm trong `📁 components` và `📁 containers` để tách riêng business logic. Di chuyển business logic đó lên các layer cao hơn. Nếu nó không được sử dụng ở quá nhiều nơi, bạn thậm chí có thể cân nhắc copy-paste. ## Xem thêm[](#see-also "Link trực tiếp đến heading") * [(Bài nói tiếng Nga) Ilya Klimov — Крысиные бега бесконечного рефакторинга: как не дать техническому долгу убить мотивацию и продукт](https://youtu.be/aOiJ3k2UvO4) --- # Migration từ v1 sang v2 ## Tại sao v2?[](#tại-sao-v2 "Link trực tiếp đến heading") Khái niệm gốc của **feature-slices** [đã được công bố](https://t.me/feature_slices) vào năm 2018. Kể từ đó, nhiều sự biến đổi của phương pháp luận đã diễn ra, nhưng đồng thời **[các nguyên tắc cơ bản đã được bảo tồn](https://feature-sliced.github.io/featureslices.dev/v1.0.html)**: * Sử dụng cấu trúc dự án frontend *được tiêu chuẩn hóa* * Chia nhỏ ứng dụng ngay từ đầu - theo *logic nghiệp vụ* * Sử dụng các *feature độc lập* để ngăn chặn side effects ngầm định và phụ thuộc vòng tròn * Sử dụng *Public API* với việc cấm "leo vào bên trong" của module Đồng thời, trong phiên bản trước của phương pháp luận, vẫn còn những **điểm yếu** mà: * Đôi khi dẫn đến boilerplate code * Đôi khi dẫn đến sự phức tạp quá mức của code base và các quy tắc không rõ ràng giữa các abstraction * Đôi khi dẫn đến các giải pháp kiến trúc ngầm định, ngăn cản việc kéo dự án lên và onboarding người mới Phiên bản mới của phương pháp luận ([v2](https://github.com/feature-sliced/documentation)) được thiết kế **để loại bỏ những thiếu sót này, đồng thời bảo tồn các ưu điểm hiện có** của cách tiếp cận này. Kể từ năm 2018, [cũng đã phát triển](https://github.com/kof/feature-driven-architecture/issues) một phương pháp luận tương tự khác - [**feature-driven**](https://github.com/feature-sliced/documentation/tree/rc/feature-driven), được công bố lần đầu bởi [Oleg Isonen](https://github.com/kof). Sau khi hợp nhất hai cách tiếp cận, chúng tôi đã **cải thiện và tinh chỉnh các thực tiễn hiện có** - hướng tới sự linh hoạt, rõ ràng và hiệu quả hơn trong ứng dụng. > Kết quả là, điều này thậm chí đã ảnh hưởng đến tên của phương pháp luận - *"feature-slice**d**"* ## Tại sao việc migration dự án sang v2 có ý nghĩa?[](#tại-sao-việc-migration-dự-án-sang-v2-có-ý-nghĩa "Link trực tiếp đến heading") > `WIP:` Phiên bản hiện tại của phương pháp luận đang được phát triển và một số chi tiết *có thể thay đổi* #### 🔍 Kiến trúc minh bạch và đơn giản hơn[](#-kiến-trúc-minh-bạch-và-đơn-giản-hơn "Link trực tiếp đến heading") Phương pháp luận (v2) cung cấp **các abstraction trực quan hơn và phổ biến hơn cũng như các cách phân tách logic giữa các developer.** Tất cả điều này có tác động cực kỳ tích cực đến việc thu hút người mới, cũng như nghiên cứu trạng thái hiện tại của dự án, và phân phối logic nghiệp vụ của ứng dụng. #### 📦 Tính modular linh hoạt và trung thực hơn[](#-tính-modular-linh-hoạt-và-trung-thực-hơn "Link trực tiếp đến heading") Phương pháp luận (v2) cho phép **phân phối logic theo cách linh hoạt hơn:** * Với khả năng refactor các phần riêng biệt từ đầu * Với khả năng dựa vào cùng các abstraction, nhưng không có sự đan xen phụ thuộc không cần thiết * Với các yêu cầu đơn giản hơn cho vị trí của module mới *(layer => slice => segment)* #### 🚀 Nhiều đặc tả, kế hoạch, cộng đồng hơn[](#-nhiều-đặc-tả-kế-hoạch-cộng-đồng-hơn "Link trực tiếp đến heading") Hiện tại, `core-team` đang tích cực làm việc trên phiên bản mới nhất (v2) của phương pháp luận Vì vậy đối với nó: * sẽ có nhiều case / vấn đề được mô tả hơn * sẽ có nhiều hướng dẫn về ứng dụng hơn * sẽ có nhiều ví dụ thực tế hơn * nói chung, sẽ có nhiều tài liệu hơn để onboarding người mới và nghiên cứu các khái niệm của phương pháp luận * toolkit sẽ được phát triển trong tương lai để tuân thủ các khái niệm và quy ước về kiến trúc > Tất nhiên, cũng sẽ có hỗ trợ người dùng cho phiên bản đầu tiên - nhưng phiên bản mới nhất vẫn là ưu tiên của chúng tôi > > Trong tương lai, với các bản cập nhật major tiếp theo, bạn vẫn sẽ có quyền truy cập vào phiên bản hiện tại (v2) của phương pháp luận, **không có rủi ro cho team và dự án của bạn** ## Changelog[](#changelog "Link trực tiếp đến heading") ### `BREAKING` Layers[](#breaking-layers "Link trực tiếp đến heading") Bây giờ phương pháp luận giả định việc phân bổ rõ ràng các layer ở tầng cao nhất * `/app` > `/processes` > **`/pages`** > **`/features`** > `/entities` > `/shared` * *Tức là, không phải mọi thứ bây giờ đều được coi là features/pages* * Cách tiếp cận này cho phép bạn [đặt quy tắc rõ ràng cho các layer](https://t.me/atomicdesign/18708): * **Càng cao layer** của module được đặt, càng nhiều **context** nó có *(nói cách khác - mỗi module của layer - chỉ có thể import các module của các layer bên dưới, nhưng không phải cao hơn)* * **Càng thấp layer** của module được đặt, càng nhiều **nguy hiểm và trách nhiệm** khi thực hiện thay đổi *(vì thường là các layer bên dưới được sử dụng nhiều hơn)* ### `BREAKING` Shared[](#breaking-shared "Link trực tiếp đến heading") Các infrastructure abstraction `/ui`, `/lib`, `/api`, trước đây nằm trong src root của dự án, bây giờ được tách biệt bởi thư mục riêng biệt `/src/shared` * `shared/ui` - Vẫn là uikit tổng quát giống như cũ của ứng dụng (tùy chọn) * *Đồng thời, không ai cấm sử dụng `Atomic Design` ở đây như trước* * `shared/lib` - Tập hợp các thư viện phụ trợ để triển khai logic * *Vẫn - không có dump của helpers* * `shared/api` - Điểm vào chung để truy cập API * *Cũng có thể đăng ký cục bộ trong mỗi feature / page - nhưng không được khuyến khích* * Như trước - không nên có ràng buộc rõ ràng với business logic trong `shared` * *Nếu cần thiết, bạn cần đưa mối quan hệ này lên tầng `entities` hoặc thậm chí cao hơn* ### `NEW` Entities, Processes[](#new-entities-processes "Link trực tiếp đến heading") Trong v2 **, các abstraction mới khác** đã được thêm vào để loại bỏ các vấn đề về độ phức tạp logic và coupling cao. * `/entities` - layer **business entities** chứa các slice có liên quan trực tiếp đến các business model hoặc synthetic entities chỉ cần thiết trên frontend * *Ví dụ: `user`, `i18n`, `order`, `blog`* * `/processes` - layer **business processes**, xuyên suốt app * **Layer này là tùy chọn**, thường được khuyến khích sử dụng khi *logic phát triển và bắt đầu mờ nhạt trong nhiều page* * *Ví dụ: `payment`, `auth`, `quick-tour`* ### `BREAKING` Abstractions & Naming[](#breaking-abstractions--naming "Link trực tiếp đến heading") Bây giờ các abstraction cụ thể và [khuyến nghị rõ ràng cho việc đặt tên chúng](/documentation/vi/docs/about/understanding/naming.md) đã được định nghĩa #### Layers[](#layers "Link trực tiếp đến heading") * `/app` — **layer khởi tạo ứng dụng** * *Các phiên bản trước: `app`, `core`,`init`, `src/index` (và điều này cũng xảy ra)* * `/processes` — [**layer business process**](https://github.com/feature-sliced/documentation/discussions/20) * *Các phiên bản trước: `processes`, `flows`, `workflows`* * `/pages` — **layer page ứng dụng** * *Các phiên bản trước: `pages`, `screens`, `views`, `layouts`, `components`, `containers`* * `/features` — [**layer các phần functionality**](https://github.com/feature-sliced/documentation/discussions/23) * *Các phiên bản trước: `features`, `components`, `containers`* * `/entities` — [**layer business entity**](https://github.com/feature-sliced/documentation/discussions/18#discussioncomment-422649) * *Các phiên bản trước: `entities`, `models`, `shared`* * `/shared` — [**layer của infrastructure code tái sử dụng**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-453020) 🔥 * *Các phiên bản trước: `shared`, `common`, `lib`* #### Segments[](#segments "Link trực tiếp đến heading") * `/ui` — [**UI segment**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-453132) 🔥 * *Các phiên bản trước: `ui`, `components`, `view`* * `/model` — [**BL-segment**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-472645) 🔥 * *Các phiên bản trước: `model`, `store`, `state`, `services`, `controller`* * `/lib` — segment **của auxiliary code** * *Các phiên bản trước: `lib`, `libs`, `utils`, `helpers`* * `/api` — [**API segment**](https://github.com/feature-sliced/documentation/discussions/66) * *Các phiên bản trước: `api`, `service`, `requests`, `queries`* * `/config` — **segment cấu hình ứng dụng** * *Các phiên bản trước: `config`, `env`, `get-env`* ### `REFINED` Low coupling[](#refined-low-coupling "Link trực tiếp đến heading") Bây giờ việc [tuân thủ nguyên tắc low coupling](/documentation/vi/docs/reference/slices-segments.md#zero-coupling-high-cohesion) giữa các module dễ dàng hơn nhiều, nhờ vào các layer mới. *Đồng thời, vẫn được khuyến khích tránh càng nhiều càng tốt các trường hợp khi cực kỳ khó để "uncouple" các module* ## Xem thêm[](#xem-thêm "Link trực tiếp đến heading") * [Ghi chú từ báo cáo "React SPB Meetup #1"](https://t.me/feature_slices) * [React Berlin Talk - Oleg Isonen "Feature Driven Architecture"](https://www.youtube.com/watch?v=BWAeYuWFHhs) * [So sánh với v1 (community-chat)](https://t.me/feature_sliced/493) * [Ý tưởng mới v2 với giải thích (atomicdesign-chat)](https://t.me/atomicdesign/18708) * [Thảo luận về các abstraction và naming cho phiên bản mới của phương pháp luận (v2)](https://github.com/feature-sliced/documentation/discussions/31) --- # Migration từ v2.0 sang v2.1 Thay đổi chính trong v2.1 là mental model mới để phân tách interface — pages first. Trong v2.0, FSD khuyến nghị xác định entities và features trong interface của bạn, cân nhắc thậm chí những bit nhỏ nhất của entity representation và tính tương tác để phân tách. Sau đó bạn sẽ xây dựng widgets và pages từ entities và features. Trong model phân tách này, phần lớn logic nằm trong entities và features, và pages chỉ là các compositional layer không có nhiều ý nghĩa riêng biệt. Trong v2.1, chúng tôi khuyến nghị bắt đầu với pages, và có thể thậm chí dừng lại ở đó. Hầu hết mọi người đã biết cách tách app thành các page riêng biệt, và pages cũng là điểm khởi đầu phổ biến khi cố gắng tìm một component trong codebase. Trong model phân tách mới này, bạn giữ phần lớn UI và logic trong mỗi page riêng biệt, duy trì một foundation có thể tái sử dụng trong Shared. Nếu phát sinh nhu cầu tái sử dụng business logic trên nhiều page, bạn có thể di chuyển nó xuống layer bên dưới. Một bổ sung khác cho Feature-Sliced Design là việc tiêu chuẩn hóa cross-imports giữa các entity với ký hiệu `@x`. ## Cách migration[](#how-to-migrate "Link trực tiếp đến heading") Không có breaking changes trong v2.1, điều này có nghĩa là một dự án được viết với FSD v2.0 cũng là một dự án hợp lệ trong FSD v2.1. Tuy nhiên, chúng tôi tin rằng mental model mới có lợi hơn cho các team và đặc biệt là onboarding các developer mới, vì vậy chúng tôi khuyến nghị thực hiện các điều chỉnh nhỏ đối với việc phân tách của bạn. ### Merge slices[](#merge-slices "Link trực tiếp đến heading") Một cách đơn giản để bắt đầu là chạy linter của chúng tôi, [Steiger](https://github.com/feature-sliced/steiger), trên dự án. Steiger được xây dựng với mental model mới, và các rule hữu ích nhất sẽ là: * [`insignificant-slice`](https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/insignificant-slice) — nếu một entity hoặc feature chỉ được sử dụng trong một page, rule này sẽ đề xuất merge entity hoặc feature đó hoàn toàn vào page. * [`excessive-slicing`](https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/excessive-slicing) — nếu một layer có quá nhiều slices, thường là dấu hiệu cho thấy việc phân tách quá chi tiết. Rule này sẽ đề xuất merge hoặc nhóm một số slices để hỗ trợ navigation dự án. ``` npx steiger src ``` Điều này sẽ giúp bạn xác định những slice chỉ được sử dụng một lần, để bạn có thể cân nhắc lại xem chúng có thực sự cần thiết không. Trong những cân nhắc như vậy, hãy nhớ rằng một layer tạo thành một loại global namespace cho tất cả các slice bên trong nó. Giống như bản sẽ không làm ô nhiễm global namespace với các biến chỉ được sử dụng một lần, bạn nên coi một vị trí trong namespace của layer là có giá trị, được sử dụng một cách tiết kiệm. ### Tiêu chuẩn hóa cross-imports[](#tiêu-chuẩn-hóa-cross-imports "Link trực tiếp đến heading") Nếu trước đây bạn đã có cross-imports giữa trong dự án của mình (chúng tôi không phán xét!), bây giờ bạn có thể tận dụng một ký hiệu mới cho cross-importing trong Feature-Sliced Design — ký hiệu `@x`. Nó trông như thế này: entities/B/some/file.ts ``` import type { EntityA } from "entities/A/@x/B"; ``` Để biết thêm chi tiết, hãy xem phần [Public API for cross-imports](/documentation/vi/docs/reference/public-api.md#public-api-for-cross-imports) trong reference. --- # Sử dụng với Electron Các ứng dụng Electron có kiến trúc đặc biệt gồm nhiều process với các trách nhiệm khác nhau. Việc áp dụng FSD trong bối cảnh như vậy yêu cầu phải thích nghi cấu trúc với các đặc điểm của Electron. ``` └── src ├── app # Common app layer │ ├── main # Main process │ │ └── index.ts # Main process entry point │ ├── preload # Preload script and Context Bridge │ │ └── index.ts # Preload entry point │ └── renderer # Renderer process │ └── index.html # Renderer process entry point ├── main │ ├── features │ │ └── user │ │ └── ipc │ │ ├── get-user.ts │ │ └── send-user.ts │ ├── entities │ └── shared ├── renderer │ ├── pages │ │ ├── settings │ │ │ ├── ipc │ │ │ │ ├── get-user.ts │ │ │ │ └── save-user.ts │ │ │ ├── ui │ │ │ │ └── user.tsx │ │ │ └── index.ts │ │ └── home │ │ ├── ui │ │ │ └── home.tsx │ │ └── index.ts │ ├── widgets │ ├── features │ ├── entities │ └── shared └── shared # Common code between main and renderer └── ipc # IPC description (event names, contracts) ``` ## Quy tắc Public API[](#quy-tắc-public-api "Link trực tiếp đến heading") Mỗi process phải có public API riêng của nó. Ví dụ, bạn không thể import các module từ `main` vào `renderer`. Chỉ có thư mục `src/shared` là public cho cả hai process. Nó cũng cần thiết để mô tả các hợp đồng cho tương tác giữa các process. ## Các thay đổi bổ sung cho cấu trúc chuẩn[](#các-thay-đổi-bổ-sung-cho-cấu-trúc-chuẩn "Link trực tiếp đến heading") Được đề xuất sử dụng segment `ipc` mới, nơi diễn ra tương tác giữa các process. Các layer `pages` và `widgets`, dựa trên tên gọi của chúng, không nên có mặt trong `src/main`. Bạn có thể sử dụng `features`, `entities` và `shared`. Layer `app` trong `src` chứa các điểm đầu vào cho `main` và `renderer`, cũng như IPC. Không mong muốn các segment trong layer `app` có điểm giao nhau ## Ví dụ về tương tác[](#ví-dụ-về-tương-tác "Link trực tiếp đến heading") src/shared/ipc/channels.ts ``` export const CHANNELS = { GET_USER_DATA: 'GET_USER_DATA', SAVE_USER: 'SAVE_USER', } as const; export type TChannelKeys = keyof typeof CHANNELS; ``` src/shared/ipc/events.ts ``` import { CHANNELS } from './channels'; export interface IEvents { [CHANNELS.GET_USER_DATA]: { args: void, response?: { name: string; email: string; }; }; [CHANNELS.SAVE_USER]: { args: { name: string; }; response: void; }; } ``` src/shared/ipc/preload.ts ``` import { CHANNELS } from './channels'; import type { IEvents } from './events'; type TOptionalArgs
My Custom App component
Loading...
;
}
if (isError || !post) {
return <>{error?.message};
}
return (
Post id: {post.id}
{post.title}
{post.body}
Owner: {post.userId}
Các component trên layer này không nên chứa business logic, nhưng có thể có chủ đề business. Ví dụ, bạn có thể đặt logo công ty và layout trang ở đây. Các component có UI logic cũng được cho phép (ví dụ: autocomplete hoặc search bar). * `📁 lib` — tập hợp các internal library.
Folder này không nên được coi như helper hoặc utility ([đọc ở đây tại sao những folder này thường trở thành bãi rác](https://dev.to/sergeysova/why-utils-helpers-is-a-dump-45fo)). Thay vào đó, mỗi library trong folder này nên có một lĩnh vực tập trung, ví dụ: date, color, text manipulation, v.v. Lĩnh vực tập trung đó nên được ghi lại trong file README. Các developer trong team của bạn nên biết có thể thêm gì và không thể thêm gì vào những library này. * `📁 config` — environment variable, global feature flag và các cấu hình global khác cho app của bạn. * `📁 routes` — route constant hoặc pattern để matching route. * `📁 i18n` — setup code cho translation, global translation string. Bạn được tự do thêm nhiều segment hơn, nhưng hãy đảm bảo rằng tên của những segment này mô tả mục đích của nội dung, không phải bản chất của nó. Ví dụ, `components`, `hooks`, và `types` là những tên segment tệ vì chúng không hữu ích khi bạn đang tìm kiếm code. ### Entities[](#entities "Link trực tiếp đến heading") Các slice trên layer này đại diện cho các khái niệm từ thế giới thực mà dự án đang làm việc. Thông thường, chúng là các thuật ngữ mà business sử dụng để mô tả sản phẩm. Ví dụ, một mạng xã hội có thể làm việc với các business entity như User, Post và Group. Một entity slice có thể chứa data storage (`📁 model`), data validation schema (`📁 model`), các function API request liên quan đến entity (`📁 api`), cũng như visual representation của entity này trong interface (`📁 ui`). Visual representation không cần phải tạo ra một UI block hoàn chỉnh — nó chủ yếu nhằm tái sử dụng cùng một appearance trên nhiều page trong app, và các business logic khác nhau có thể được gắn vào nó thông qua props hoặc slot. #### Mối quan hệ entity[](#mối-quan-hệ-entity "Link trực tiếp đến heading") Entity trong FSD là các slice, và mặc định, các slice không thể biết về nhau. Tuy nhiên, trong đời thực, các entity thường tương tác với nhau, và đôi khi một entity sở hữu hoặc chứa các entity khác. Vì vậy, business logic của những tương tác này tốt nhất nên được giữ ở các layer cao hơn, như Features hoặc Pages. Khi data object của một entity chứa các data object khác, thường là ý tưởng tốt để làm cho kết nối giữa các entity trở nên rõ ràng và bỏ qua slice isolation bằng cách tạo cross-reference API với ký hiệu `@x`. Lý do là các entity được kết nối cần được refactor cùng nhau, vì vậy tốt nhất là làm cho kết nối không thể bỏ sót. For example: entities/artist/model/artist.ts ``` import type { Song } from "entities/song/@x/artist"; export interface Artist { name: string; songs: Array
Ví dụ, nếu bạn có index cho feature "comments", `📄 features/comments/index.js`, thì không có lý do gì để có thêm index cho segment `ui` của feature đó, `📄 features/comments/ui/index.js`. 3. Nếu bạn có một dự án rất lớn, có khả năng cao là ứng dụng của bạn có thể được chia thành nhiều chunk lớn.
Ví dụ, Google Docs có trách nhiệm rất khác nhau cho document editor và file browser. Bạn có thể tạo monorepo setup nơi mỗi package là một FSD root riêng biệt, với bộ layer riêng. Một số package chỉ có thể có layer Shared và Entities, những package khác có thể chỉ có Pages và App, những package khác nữa có thể bao gồm Shared nhỏ của riêng mình, nhưng vẫn sử dụng cái lớn từ package khác. --- # Slice và segment ## Slice[](#slice "Link trực tiếp đến heading") Slice là cấp độ thứ hai trong hệ thống phân cấp tổ chức của Feature-Sliced Design. Mục đích chính của chúng là nhóm code theo ý nghĩa của nó đối với sản phẩm, business, hoặc chỉ đơn giản là application. Tên của các slice không được chuẩn hóa vì chúng được xác định trực tiếp bởi business domain của ứng dụng của bạn. Ví dụ, một photo gallery có thể có các slice `photo`, `effects`, `gallery-page`. Một mạng xã hội sẽ yêu cầu các slice khác nhau, ví dụ `post`, `comments`, `news-feed`. Các layer Shared và App không chứa slice. Đó là vì Shared không nên chứa business logic nào cả, do đó không có ý nghĩa gì đối với sản phẩm, và App chỉ nên chứa code liên quan đến toàn bộ ứng dụng, vì vậy không cần phải chia tách. ### Zero coupling và high cohesion[](#zero-coupling-high-cohesion "Link trực tiếp đến heading") Slice được thiết kế để là các nhóm file code độc lập và có tính gắn kết cao. Hình minh họa dưới đây có thể giúp hình dung các khái niệm khó hiểu về *cohesion* và *coupling*:  Image inspired by