前端项目文件组织与组件命名
缘由
在开发项目的过程中，大家多多少少会对自己项目的目录结构产生疑惑，如何合理地划分模块以及如何合理的命名，这些如果在项目前期的时候没有好好规范好的话，那么后面新进来的人便会按照自己的逻辑又重新在划分自己的目录，这样日复一日项目体积不但会增加而且目录结构会越来越混乱，因此非常有必要聚焦项目的文件目录，本文也是出于这样的一个出发点来写的，先来看看几个优秀项目的目录。
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
相对于SPA应用，MPA应用特别是同构应用来说，目录结构也是很清晰的。
那么如何组织文件才合理呢？
答案便是组件化，一切以组件为核心来建立相应的文件目录，这里有几种划分组件的方式：
1、公共组件与业务组件：
一般比较常用的划分方式便是有公共用到的组件便往上提升一级，遇到部分页面用到的组件的话有可能放到跟页面同级也有可能直接放到最上面的一级，例如：
├── common
│ ├── Footer
│ ├── Header
│ └── Slider
└── pages
├── _common
│ └── banner
├── index
└── info
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
这种优点的话比较灵活，但是局部的公共部分你很难去界定。
2、BEM组件划分
这种的话组件划分的比较清晰。
├── Blocks
│ ├── Avatar
│ │ ├── index.js
│ ├── Button
│ │ ├── index.js
│ ├── Header
│ │ ├── index.js
│ │ └── style.scss
├── Elements
│ ├── DownloadBtn.js
│ ├── Logo.js
└── Icons
├── Audience.js
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
将组件强势得分为3类，这种结构上虽然非常清晰，但是在项目开发的过程中你不得不频繁地将组件在Block跟Elemens之间移来移去，降低了开发体验。
3、容器组件与展示型组件
├── components
│ ├── Banner
│ ├── Footer
│ └── Header
├── containers
│ ├── ArticleDetail
│ └── CommentList
└── screens
└── home
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
这里就要看你怎么定义什么是容器组件跟展示型组件了，对于日常的开发来说，这2者是没有强制的边界的，两者之间可以随意切换，也并不是说展示组件一定非得是纯组件，也不一定是说容器组件一定非得有状态跟生命周期，而对于本人来说，一个很好的准则就是展示组件是为了解耦，容器组件是为了内聚。
4、样式组件与逻辑组件
如果项目中有用到css-in-js之类的工具，如styled-component，想必会想到样式放在哪里这个问题，于是便会出现如下情况：
./
└── Avatar
├── index.js
└── styles
└── styleWrapper.js
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
这就会多出来一种逻辑出来。
那么有没有统一的一种方式来规范好组件的文件目录呢？
答案是有的，这种是基于以上几种划分方式来的，通常开发一个组件的时候有可能被认定为样式组件或者容器组件，那么我们这时就不把它们分开，而是所有的组件都放在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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
例如在用户模块这个目录下，有头像、信息卡以及登陆框的情景，我们限定image、js、scss分别在每个组件目录下，这样做的话，单个组件如果要迁移的话就可以非常方便的移动了，这里再说明下LoginBox下面的AreaList，如果再LoginBox要添加功能的话，那么直接就在这个组件添加，也非常方便地扩展了。
最后至于文件如何命名
这个要看项目组如何规定，但有个通用原则是如果是类的话必须是首字母大写，我上面的例子，由于组件也可以看成是一个类，因此大写是比较清晰的，至于组件的命名，有个比较流行的方式叫path-base-naming,就是基于文件路径来命名，例如在home/index.js 里面命名AreaList的话就可以这样：
import LoginBoxAreaList from '../../components/LoginBox/AreaList';
- 1
- 2
- 3
- 4
但如果在LoginBox目录下命名就不再需要这么长了.
import AreaList from './AreaList';
- 1
- 2
- 3
- 4
总结
最后基于这种分模块的方式，开发者可以自由的将容器组件或者展示组件分布在各个独立的组件文件夹之中，可以说规范和灵活性都得到了保障。
参考
https://medium.com/@dan_abram...
https://hackernoon.com/struct...