前端項目文件組織與組件命名

原因

在開發項目的過程當中，你們多多少少會對本身項目的目錄結構產生疑惑，如何合理地劃分模塊以及如何合理的命名，這些若是在項目前期的時候沒有好好規範好的話，那麼後面新進來的人便會按照本身的邏輯又從新在劃分本身的目錄，這樣日復一日項目體積不但會增長並且目錄結構會愈來愈混亂，所以很是有必要聚焦項目的文件目錄，本文也是出於這樣的一個出發點來寫的，先來看看幾個優秀項目的目錄。

crate-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應用特別是同構應用來講，目錄結構也是很清晰的。

那麼如何組織文件才合理呢？

答案即是組件化，一切以組件爲核心來創建相應的文件目錄，這裏有幾種劃分組件的方式：

一、公共組件與業務組件：

通常比較經常使用的劃分方式即是有公共用到的組件便往上提高一級，遇到部分頁面用到的組件的話有可能放到跟頁面同級也有可能直接放到最上面的一級，例如：

├── common
│   ├── Footer
│   ├── Header
│   └── Slider
└── pages
    ├── _common
    │   └── banner
    ├── index
    └── info

這種優勢的話比較靈活，可是局部的公共部分你很難去界定。

二、BEM組件劃分

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

├── Blocks
│   ├── Avatar
│   │   ├── index.js
│   ├── Button
│   │   ├── index.js
│   ├── Header
│   │   ├── index.js
│   │   └── style.scss
├── Elements
│   ├── DownloadBtn.js
│   ├── Logo.js
└── Icons
    ├── Audience.js

將組件強勢得分爲3類，這種結構上雖然很是清晰，可是在項目開發的過程當中你不得不頻繁地將組件在Block跟Elemens之間移來移去，下降了開發體驗。

三、容器組件與展現型組件

├── components
│   ├── Banner
│   ├── Footer
│   └── Header
├── containers
│   ├── ArticleDetail
│   └── CommentList
└── screens
    └── home

這裏就要看你怎麼定義什麼是容器組件跟展現型組件了，對於平常的開發來講，這2者是沒有強制的邊界的，二者之間能夠隨意切換，也並非說展現組件必定非得是純組件，也不必定是說容器組件必定非得有狀態跟生命週期，而對於本人來講，一個很好的準則就是展現組件是爲了解耦，容器組件是爲了內聚。

四、樣式組件與邏輯組件

若是項目中有用到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';

總結

最後基於這種分模塊的方式，開發者能夠自由的將容器組件或者展現組件分佈在各個獨立的組件文件夾之中，能夠說規範和靈活性都獲得了保障。

參考

https://medium.com/@dan_abram...
https://hackernoon.com/struct...