前端專案檔案組織與元件命名

kingda發表於2019-04-01

##緣由 在開發專案的過程中,大家多多少少會對自己專案的目錄結構產生疑惑,如何合理地劃分模組以及如何合理的命名,這些如果在專案前期的時候沒有好好規範好的話,那麼後面新進來的人便會按照自己的邏輯又重新在劃分自己的目錄,這樣日復一日專案體積不但會增加而且目錄結構會越來越混亂,因此非常有必要聚焦專案的檔案目錄,本文也是出於這樣的一個出發點來寫的,先來看看幾個優秀專案的目錄。

create-react-app

├── package.json
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── Lazy.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js
複製程式碼

create-react-app是非常的簡潔,只包含了src以及public2個目錄。

@vue/cli

├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
└── src
    ├── App.vue
    ├── assets
    │   └── logo.png
    ├── components
    │   └── HelloWorld.vue
    └── main.js
複製程式碼

vue的cli也是如出一轍。

nuxt

├── assets
├── components
│   └── Logo.vue
├── layouts
│   └── default.vue
├── middleware
├── nuxt.config.js
├── package-lock.json
├── package.json
├── pages
│   └── index.vue
├── plugins
├── server
│   └── index.js
├── static
│   └── favicon.ico
└── store
複製程式碼

相對於SPA應用,MPA應用特別是同構應用來說,目錄結構也是很清晰的。

那麼如何組織檔案才合理呢?

答案便是元件化,一切以元件為核心來建立相應的檔案目錄,這裡有幾種劃分元件的方式:

1、公共元件與業務元件:

一般比較常用的劃分方式便是有公共用到的元件便往上提升一級,遇到部分頁面用到的元件的話有可能放到跟頁面同級也有可能直接放到最上面的一級,例如:

├── common
│   ├── Footer
│   ├── Header
│   └── Slider
└── pages
    ├── _common
    │   └── banner
    ├── index
    └── info
複製程式碼

這種優點的話比較靈活,但是區域性的公共部分你很難去界定。

2、BEM元件劃分

這種的話元件劃分的比較清晰。

├── Blocks
│   ├── Avatar
│   │   ├── index.js
│   ├── Button
│   │   ├── index.js
│   ├── Header
│   │   ├── index.js
│   │   └── style.scss
├── Elements
│   ├── DownloadBtn.js
│   ├── Logo.js
└── Icons
    ├── Audience.js
複製程式碼

將元件強勢得分為3類,這種結構上雖然非常清晰,但是在專案開發的過程中你不得不頻繁地將元件在Block跟Elemens之間移來移去,降低了開發體驗。

3、容器元件與展示型元件

├── components
│   ├── Banner
│   ├── Footer
│   └── Header
├── containers
│   ├── ArticleDetail
│   └── CommentList
└── screens
    └── home
複製程式碼

這裡就要看你怎麼定義什麼是容器元件跟展示型元件了,對於日常的開發來說,這2者是沒有強制的邊界的,兩者之間可以隨意切換,也並不是說展示元件一定非得是純元件,也不一定是說容器元件一定非得有狀態跟生命週期,而對於本人來說,一個很好的準則就是展示元件是為了解耦,容器元件是為了內聚。

4、樣式元件與邏輯元件

如果專案中有用到css-in-js之類的工具,如styled-component,想必會想到樣式放在哪裡這個問題,於是便會出現如下情況:

./
└── Avatar
    ├── index.js
    └── styles
        └── styleWrapper.js
複製程式碼

這就會多出來一種邏輯出來。

那麼有沒有統一的一種方式來規範好元件的檔案目錄呢?

答案是有的,這種是基於以上幾種劃分方式來的,通常開發一個元件的時候有可能被認定為樣式元件或者容器元件,那麼我們這時就不把它們分開,而是所有的元件都放在components目錄下面,再根據模組進行劃分,所有的頁面都是通過模組元件進行組合,最外層的頁面元件則是應該是最簡潔以及少程式碼量的。如下:

├── components
│   └── User
│       ├── Avatar
│       │   ├── images
│       │   ├── index.js
│       │   └── style.scss
│       ├── InfoCard
│       │   ├── images
│       │   ├── indexjs
│       │   └── style.scss
│       └── LoginBox
│           ├── reaList
│           │   ├── images
│           │   ├── index.js
│           │   └── style.scss
│           ├── index.js
│           └── style.scss
└── screens
    └── home
        └── index.js
複製程式碼

例如在使用者模組這個目錄下,有頭像、資訊卡以及登陸框的情景,我們限定image、js、scss分別在每個元件目錄下,這樣做的話,單個元件如果要遷移的話就可以非常方便的移動了,這裡再說明下LoginBox下面的AreaList,如果再LoginBox要新增功能的話,那麼直接就在這個元件新增,也非常方便地擴充套件了。

最後至於檔案如何命名

這個要看專案組如何規定,但有個通用原則是如果是類的話必須是首字母大寫,我上面的例子,由於元件也可以看成是一個類,因此大寫是比較清晰的,至於元件的命名,有個比較流行的方式叫path-base-naming,就是基於檔案路徑來命名,例如在home/index.js 裡面命名AreaList的話就可以這樣:

import LoginBoxAreaList from '../../components/LoginBox/AreaList';
複製程式碼

但如果在LoginBox目錄下命名就不再需要這麼長了.

import AreaList from './AreaList';
複製程式碼

總結

最後基於這種分模組的方式,開發者可以自由的將容器元件或者展示元件分佈在各個獨立的元件資料夾之中,可以說規範和靈活性都得到了保障。

參考

medium.com/@dan_abramo… hackernoon.com/structuring…

相關文章