如何設計簡潔、直觀的前端架構？

作者 | Aman Agarwal

譯者 | 核子可樂

編輯 | 張之棟、Yonie

時至今日，對項目架構的設計判斷仍是一項極為複雜的難題。每個人在啟動項目之初，都會參考一系列不同的文章與部落格，希望借此確定項目架構的具體開發方法。

給設計質量低下的項目“擦屁股”，可能要比設計好項目更加困難。

你的項目架構應該簡潔且直觀，這樣當有新的開發人員接手管理時，才能夠在理解數據跟蹤及其背後體現的 UI 路徑時不致遇上太多無法理解的問題。

人們使用的是架構而非一個個獨立組件，因此架構中的各個組件應該只是獨立的文件。

為什麽我們的項目架構應該盡量強調簡潔與直觀？

易於管理。

易於理解。

編碼經過優化。

組件更新更簡單。

文件或者組件越小，調試起來越輕鬆。

下圖所示，就是本文想要表達的基本觀點。

項目的架構

下面，我們將通過一系列明確的流程幫助大家了解項目的結構設計方式：

組件劃分

組件越小，就越易於處理。將 UI 拆分成一個個小型組件。代碼行（LOC）越少，我們對代碼的掌控能力就越強，調試與必要時的更新也就越簡單。大家可以嘗試通過以下方式增強項目的架構：

將公共組件移動到不同的目錄當中。

將每個文件的組件容納量限定為 2 到 3 個，且確保其中不包含公共代碼組件。

嘗試對組件進行概括，以便在不同的用例中反覆使用。

將彼此相關的組件劃分到同一個目錄當中，且保證這些目錄不會在目錄之外的組件中使用。

輔助函數

輔助函數應該強大且中立。輔助函數應該與渲染邏輯區分開來。僅在組件需要時使用輔助函數，且一般應該進行聲明。輔助函數的作用在於：

處理從伺服器處接收到的數據以適應 UI 邏輯。

特定於組件邏輯。

與瀏覽器規範相關。

與開發人員實施的邏輯相關，其通過不同的標準以達成目標。

將彼此相關的組件劃分到同一個文件當中，將公共函數劃分至utils文件當中 。

API 服務

服務是數據間的鏈接。API 服務是指負責在參數特定的情況下，調用伺服器以獲取數據的代碼。我們不應直接從 UI 邏輯當中調用服務。因為如果我們需要在多個位置實現相同的 API 調用，且端點、標題等會發生變更，那麽對不同位置進行服務修改將變得非常困難。下面來看如何進行服務聲明：

服務聲明應作為 API 調用的基本實現。

應接受配置（變量等）以作為 API 調用的必要參數進行傳遞。

應將從伺服器處接收到的數據原樣傳遞給調用組件。

如果使用 React 以及 Apollo，請利用 Render Props 方法構建服務組件。

Config

Config 是接入伺服器的關鍵。Config 當中包含關於應用程序運行所在環境的具體配置。請確保將配置與實際代碼庫拆分開來。配置應當：

使用不同的文件對應不同的環境類型。

根據需要獲取的不同資源類型（包括資產域、伺服器 API URL 等）而有所不同。

路 由

路由是保障 UI 使用體驗的主要方式。路由決定著我們在 Web 應用程序當中需要實現的不同頁面的 URL 格式或模式。在定義路由時，需要注意以下幾點：

盡可能保持路由的正確順序，以保證 UI 路徑不致丟失。

路由的命名應該盡可能簡短。

Static

Static 文件是指未包含在邏輯當中的文件。Static 文件不同於 CSS、圖像、js（很少變更）以及字體等文件。Static 文件（靜態文件）應該：

根據其類型進行分組。

盡可能降低其體積。

頁 面

頁面代表著 Web 應用程序當中的不同目標。作為來自 NextJS 中的概念，頁面目錄中的目錄或文件，代表著路由路徑的目的地。如此一來，當我們在破譯路由並拆分出組件時，就能夠輕鬆將路由與目的地關聯起來。頁面應該：

僅包含路由及其它組件之間的接觸點。

包含引用初始條件以引導頁面的各個文件。

不包含完整邏輯，我們應該將邏輯根據功能移動至不同的組件當中。

認真進行命名，因為該文件的名稱代表著 build 文件與路由組件（在使用 NextJS 的情況下）。

Graphql 查詢

Graphql 是從伺服器當中獲取數據的數據查詢語言。Graphql要求查詢格式利用特定鍵獲取數據。這種查詢語言的文件就好根據不同的查詢與不同的文件保存在不同的目錄當中。具體要求包括：

各查詢應根據特定類型進行分組，且不同類型在組內對應不同的目錄。

以同樣的方式對變異與訂閱進行分組。

應將部分查詢片段從查詢當中剔除，例如不同目錄中的公共代碼片段。

盡可能為各個查詢、變異等名稱保留前綴，用以區分請求不同伺服器的不同 Web 應用，例如 abcPost 查詢與 xyzPost 查詢等。這樣能夠更輕鬆地區分指向不同 Web 應用程序的相同查詢。

當組件當中包含或者需要文件時，請盡量將名稱保留為大寫形式，以確保開發人員能夠輕鬆判斷組件與查詢之間的區別。

其它注意事項

其它能夠為 Web 應用程序提供助力的工具與技巧。這部分內容包括可用於啟動應用程序、管理 build、管理電子表格以及管理所使用文件語法的不同工具。這些工具應包括：

用於啟動前端伺服器的Cookr 文件。

用於指定項目中所使用包或模塊的包清單文件。

用於描述項目規範、項目發布與使用方式、理由以及內容等不同要素的 Readme.md 文件。

如果使用 babel 進行腳本編譯，則應包含.babelrc 文件。

在使用 webpack 作為捆綁工具時的 Webpack 配置。

如果使用任何其它工具或套裝軟體（例如 apollo-client），則應為該套裝軟體的配置創建新的目錄，因為該文件當中可能包含多個彼此相關的文件。

https://medium.com/gradeup/project-architecture-for-front-end-applications-5db31abb63c2

點個在看少個 bug