簡介

前端開發(fā)人員經(jīng)常面臨與應用程序架構(gòu)相關(guān)的問題。它需要使用一種能夠輕松擴展并在應用程序模塊之間提供松耦合和高內(nèi)聚性的架構(gòu)。

本文討論功能切片設(shè)計架構(gòu)，在我看來，它是可用選項中最好的。它還探討了 FSD 的思想以及該架構(gòu)方法解決的問題。我們將 FSD 與經(jīng)典和模塊化架構(gòu)進行比較，并檢查它們的優(yōu)缺點。

首先，讓我們區(qū)分三個概念：層、切片和段。

層數(shù)

層是頂級目錄和應用程序分解的第一層。它們的數(shù)量有限 - 最多 7 層，并且是標準化的，盡管其中一些是可選的。目前，分為以下幾層：

每層都有自己的職責范圍，并且以業(yè)務(wù)為導向。
讓我們分別考慮每一層。

• app：這是應用程序邏輯初始化的地方。提供者、路由器、全局樣式、全局類型聲明等都在這里定義。它充當應用程序的入口點。

• 進程：該層處理跨多個頁面的進程，例如多步驟注冊。該層已被視為已棄用，但仍然偶爾會遇到。它是一個可選層。

• 頁面：該層包括應用程序的頁面。

• 小部件：這些是頁面上使用的獨立 UI 組件。

• 特點：這一層處理用戶場景和承載業(yè)務(wù)價值的功能。比如點贊、寫評論、給產(chǎn)品評分等。它是一個可選層。

• 實體：該層代表業(yè)務(wù)實體。這些實體可以包括用戶、評論、評論等。它是一個可選層。

• 共享：該層包含不依賴于特定業(yè)務(wù)邏輯的可重用組件和實用程序。它包括UI套件、axios配置、應用程序配置以及不與業(yè)務(wù)邏輯綁定的helpers等。

這些層有助于組織代碼庫并促進模塊化、可維護和可擴展的架構(gòu)。

特征切片設(shè)計的關(guān)鍵特征之一是其層次結(jié)構(gòu)。在此結(jié)構(gòu)中，實體無法使用特征中的功能，因為特征在層次結(jié)構(gòu)中處于較高位置。同樣，功能不能使用小部件或進程中的組件，因為上面的層只能使用下面的層。這樣做是為了維持僅沿一個方向引導的線性流動。 層在層次結(jié)構(gòu)中的位置越低，對其進行更改的風險就越大，因為它可能會在代碼中的更多位置使用。例如，共享層中的 UI-kit 用于功能層、小部件甚至頁面層。

切片

在每一層中，都有子目錄 - 切片，應用程序分解的第二層。在切片中，連接的不是抽象的事物，而是具體的業(yè)務(wù)實體。切片的主要目標是按代碼的值對代碼進行分組。

切片名稱并不標準化，因為它們直接由項目的業(yè)務(wù)領(lǐng)域決定。例如，在照片庫中，可能有照片、相冊、圖庫等部分。社交網(wǎng)絡(luò)需要像帖子、用戶、新聞源這樣的切片。

密切相關(guān)的片段可以在結(jié)構(gòu)上分組在一個目錄中，但它們必須遵守與其他片段相同的隔離規(guī)則 - 不應對該目錄中的代碼進行共享訪問。

段

每個切片由段組成。段有助于根據(jù)用途劃分切片內(nèi)的代碼。根據(jù)團隊的協(xié)議，段的組成和命名可能會發(fā)生變化。以下幾段比較常用：

• api - 必要的服務(wù)器請求

• UI - 切片的 UI 組件

• 模型 - 業(yè)務(wù)邏輯，即與狀態(tài)的交互。例如，操作和選擇器

• lib - 切片內(nèi)使用的輔助功能

• config - 切片的必要配置，但config段很少遇到

• consts - 必要的常量

公共API

每個切片和段都有一個公共 API。公共API由index.js或index.ts文件表示，它允許僅從切片或段中提取必要的功能到外部，并隔離不必要的功能。索引文件充當入口點。

公共 API 規(guī)則：

• 應用程序切片和段僅使用公共 API 索引文件中定義的切片的功能和組件。

• 公共 API 中未定義的切片或段的內(nèi)部部分被認為是隔離的，并且僅在切片或段本身內(nèi)開放供訪問。

公共 API 簡化了導入和導出的工作，因此在更改應用程序時，無需更改代碼中各處的導入。

更深入地了解如何構(gòu)建

抽象和業(yè)務(wù)邏輯

層越高，與特定業(yè)務(wù)節(jié)點的聯(lián)系越多，包含的業(yè)務(wù)邏輯也越多。層越低，層中的抽象性、可重用性和缺乏自治性就越多。

FSD如何解決這個問題？

特征切片設(shè)計的任務(wù)之一是實現(xiàn)松耦合和高內(nèi)聚。了解 FSD 如何實現(xiàn)這一結(jié)果非常重要。

在OOP中，這些問題早已通過多態(tài)、封裝、繼承、抽象等概念來解決。這些概念確保了代碼的隔離性、可重用性和多功能性，其中根據(jù)組件或功能的使用方式獲得不同的結(jié)果。

功能切片設(shè)計有助于在前端應用這些原則。

抽象和多態(tài)性是通過層來實現(xiàn)的。由于較低層是抽象的，因此它們可以在較高層中重用，并且根據(jù)條件，組件或功能可以根據(jù)指定的參數(shù)或?qū)傩砸圆煌姆绞焦ぷ鳌?/p>

封裝是通過Public API實現(xiàn)的，將不需要的東西以切片和段的方式與外部隔離。對切片內(nèi)部段的訪問受到限制，并且公共 API 是從切片或段訪問功能和組件的唯一方法。

繼承也是通過層實現(xiàn)的，因為較高層可以重用較低層。

與經(jīng)典架構(gòu)的比較

相信您已經(jīng)多次接觸過經(jīng)典構(gòu)建。由于其簡單性，大多數(shù)作者在教育文章和 YouTube 視頻中使用它。古典結(jié)構(gòu)沒有具體的標準。但是，經(jīng)常可以看到以下格式：

經(jīng)典架構(gòu)有明顯的缺點。最大的一個問題是，由于組件之間的隱式連接和模塊混亂，項目變得難以維護。隨著時間的推移，經(jīng)典架構(gòu)的缺點變得更加明顯。項目發(fā)展的時間越長，應用程序架構(gòu)就越變得難以理清。

經(jīng)典架構(gòu)適用于無需持續(xù)維護的小型項目或?qū)櫸镯椖俊?/p>

功能切片設(shè)計憑借其概念和標準，可以防止經(jīng)典架構(gòu)的問題。然而，使用 FSD 的開發(fā)人員的理解和技能水平應該比使用經(jīng)典架構(gòu)時更高。通常，經(jīng)驗不足 2 年的開發(fā)人員沒有聽說過 FSD。
然而，在使用功能切片設(shè)計時，需要“現(xiàn)在”而不是“以后”解決問題。代碼中的問題和與概念的偏差立即變得顯而易見

與簡單模塊化架構(gòu)的比較

簡單的模塊化架構(gòu)有幾個缺點：

• 有時不清楚將功能放入模塊或組件的何處。

• 在另一個模塊中使用模塊時遇到困難。

• 存儲業(yè)務(wù)實體的問題。

• 全局函數(shù)中的隱式依賴關(guān)系，導致結(jié)構(gòu)錯綜復雜。

似乎在任何復雜或中等復雜的項目中，功能切片設(shè)計應該優(yōu)先于簡單的模塊化架構(gòu)。FSD 解決了許多基本的架構(gòu)問題，并且?guī)缀鯖]有缺點。

在簡單性和開發(fā)速度方面，簡單的模塊化架構(gòu)可能比 FSD 有優(yōu)勢。如果需要 MVP 或正在開發(fā)一個短期項目，簡單的模塊化架構(gòu)可能比 FSD 更合適。但在任何其他情況下，功能切片設(shè)計看起來更可取。

Next.js 和 FSD 之間的沖突

最近，將 Next.js 與功能切片設(shè)計結(jié)合使用的趨勢越來越明顯。Next.js 與 FSD 配合良好，但在兩個方面存在沖突：頁面中的文件路由和缺少應用程序。

頁數(shù)

對于 Next.js 來說，pages 是一個帶有文件路由的目錄，其中每個組件代表一個路由。對于 FSD，頁面是具有平面頁面列表的層。這就產(chǎn)生了一個沖突：如何將 Next.js 頁面與 FSD 頁面結(jié)合起來。

當 Next.js 和 FSD 一起使用時，您可以將 Next.js 頁面存儲在應用程序的根目錄中：[root]/pages/，并將 FSD 頁面存儲在 src 文件夾中：[root]/src/pages/。

解決沖突的另一個解決方案是維護兩個目錄：來自 FSD 的重命名的平面頁面列表（例如 Pages-Flat）和 Next.js 中的嵌套路由 - Pages。頁面代碼存儲在pages-flat中并導出到pages。

您可以使用任何一種方法，但我更喜歡第一種。

應用程序

Next.js 處理應用層的所有基本功能。但是，如果您仍然需要獨立于頁面為整個應用程序運行某些內(nèi)容，則可以使用布局模式為整個應用程序創(chuàng)建布局。

關(guān)于布局模式的 Next.js 文檔：路由：頁面和布局 | Next.js（https://nextjs.org/docs/pages/building-your-application/routing/pages-and-layouts#layout-pattern）

特征切片設(shè)計的潛力

FSD 是一種年輕的建筑方法論。然而，它已經(jīng)被許多銀行、金融科技、B2B、電子商務(wù)公司等所使用。以下是包含公司列表的 Github 問題的鏈接：Github Issue（https://github.com/feature-sliced/documentation/issues/131）。

截至本文發(fā)布時，包含 FSD 官方文檔的 Github 存儲庫已獲得 858 顆星。該文檔正在積極擴展，F(xiàn)SD 開發(fā)團隊以及 Telegram 和 Discord 社區(qū)可以 24/7 全天候幫助人們解決與架構(gòu)相關(guān)的問題。

這種架構(gòu)的潛力受到高度重視，并且在全球大公司中廣泛使用。如果采用得當，F(xiàn)SD 有潛力成為前端開發(fā)領(lǐng)域的主導架構(gòu)解決方案。

架構(gòu)的優(yōu)點和缺點

優(yōu)點

• 架構(gòu)組件可以輕松替換、添加或刪除

• 架構(gòu)標準化

• 可擴展性

• 方法論獨立于開發(fā)堆棧

• 模塊之間受控且顯式的連接，不會產(chǎn)生意外的副作用

• 面向業(yè)務(wù)的架構(gòu)方法論

缺點

• 與許多其他建筑解決方案相比，進入門檻更高

• 需要意識、團隊文化和對理念的堅持

• 挑戰(zhàn)和問題需要立即解決，而不是稍后解決。代碼問題和概念偏差立即可見。不過，這也可以看作是一個優(yōu)點

總結(jié)

功能切片設(shè)計是前端開發(fā)人員應該了解并能夠使用的一個有趣且有價值的發(fā)現(xiàn)。FSD 可以為團隊提供靈活、標準化、可擴展的架構(gòu)和開發(fā)文化。然而，利用該方法的積極方面需要團隊內(nèi)的知識、意識和紀律。

FSD 因其清晰的業(yè)務(wù)導向、實體定義、應用程序的功能和組件組成而在其他架構(gòu)中脫穎而出。

您還可以獨立探索項目中 FSD 使用示例和官方功能切片設(shè)計文檔：

• 文檔（https://feature-sliced.design/）

• 示例。Github 客戶端（https://github.com/ani-team/github-client）

• 示例。耐克運動鞋和鞋類商店（https://github.com/noveogroup-amorgunov/nukeapp）

• 示例。數(shù)獨（https://github.com/Shiyan7/sudoku-effector）

這篇文章可能會很長，但我希望你學到了一些新東西。感謝您閱讀完這篇文章。??

文章來源地址http://www.zghlxwxcb.cn/article/398.html

到此這篇關(guān)于功能切片設(shè)計：最佳前端架構(gòu)的文章就介紹到這了,更多相關(guān)內(nèi)容可以在右上角搜索或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！