我的前端项目目录约定和基础规范建议。一个5年前端接触者的推荐

甘雨镇楼

废话

其实我以前觉得这个文章没必要写。但是干前端三年多（15年底接触前端开发），我发现后端做前端的时候，前端新手入学的时候对于这个基础的约定规范，都是东拼西凑，慢慢的把自己的风格习惯搭建起来。而很多没有追求的就是穷举写法。写到哪里是哪里。

我这里会对于我个人这些年逐步沉淀的习惯分享给大家。有react的见解也有vue的见解。大家互相促进

文后有阿里前端九部规范文档

一、我的目录结构

1、目录结构

项目是vue项目，但是react其实也差不多。

 

 

 

config                        项目所有的在运行前的配置中心
    index.js                  项目公共前缀，路由前缀，项目名称等等
dist                          打包后目录（前端这些年约定俗成了）
public                        不会被打包的目录，一个是webpack默认路径，另一个是大家都这么干
    config(项目如果是外部js全局变量控制环境)
    img（不被打包的静态图片）
    js（不被打包的静态js）
    index.html            webpack入口html文件
src                       源码目录
    assets                静态文件目录，一般放图片
        img
        js（不需要被打包的不要放这里，放在外层的public下面）
    businessComponents    业务组件
        Menu(菜单组件)
            list.js（菜单组合路由）
        layout            页面上全局布局组件，比如路由嵌套的部分
            One.vue（组件）        
            Two(文件夹)
                index.vue
        index.js           需要全局注册的统一出口
        README.md（组件太多需要说明文件）
    components            和业务无关的组件
        AntDesgin.js(组件库入口)       
        Element.js（组件库入口）
        index.js           需要全局导入和注册的统一出口
        README.md（组件太多需要说明文件）
    mixin                 全局mixin部分，非全局部分的mixin不建议使用。容易引起代码混乱
    pages                 路由相关页面部分，原本大家用的是views
        Home              首页
            index.vue
        Page2
            ComTwo            页面组件更加复杂了
                ComThree.vue  子组件的组件
                index.vue     页面组件入口
            ComOne.vue        页面组件
            index.vue         页面组件入口
        404.vue
    power                 项目业务上的权限管理中心
    router                路由部分（不建议把菜单管理也放这里）
        before.js(路由守卫js，名称随意，清晰明确即可)
        index.js
    service               接口管理中心
        index.js
    store                 数据中心,不在和业务有关，主要是为了配置缓存使用
        index.js
    theme                 主题样式中心，所有全局的css都在这里
        index.css(scss,less)    保证你的输出是一个出口
    tool（utils）                  工具函数中心
    App.vue               初始模板
    CreateApp.js           main.js里面会存在很多业务上的逻辑，那么这里封装下
    main.js                
.browserslistrc
.eslintrc.js            eslint配置
.gitignore    
babel.config.js        babel配置
package.json
prettier.config.js       prettier配置
README.md               项目初始约定，规范书写中心
vue.config.js           vue打包配置中心，webpack等修改也在这里

 

2、代码和目录结构上的个人习惯

遵循原则，能直接复制的最好。也要遵循历史规范

1、css嵌套不超过三层，性能方面的考虑

2、可以直接在div上面写css，也可以使用父子选择器等等

3、css名称多个字符使用“-”隔开，比如：name-title

4、class类文件首字母大写（行业上的基本习惯了），类函数名称首字母大写

5、组件名称首字母大写，采用大驼峰命名：NameTile

6、组件文件目录则采用组件名称命名，并且采用大驼峰命名

 

 

 

NameTile
    index.vue

7、组件如果是单标签的则必须用目录名称或者组件名称进行命名

比如：组件名称为Test.vue 则使用为<Test />

8、非单标签组件多字符则为<test-name></test-name>方式使用

以上组件命名原则基于复制直接能用原则，和遵循html规范和一般框架规范。不采用eslint强制约定。但是习惯之后大家会发现写代码效率会高很多。因为组件名称你直接复制黏贴基本能用了。

9、pages页面下的文件不要根据业务组件进行划分，一个路由一个文件夹。命名比如为目录加index文件方式。

10、pages下路由页面文件如下方式使用

    pages                 路由相关页面部分，原本大家用的是views
        Home              首页
            index.vue
        Page2
            ComTwo            页面组件更加复杂了
                ComThree.vue  子组件的组件
                index.vue     页面组件入口
            ComOne.vue        页面组件
            index.vue         页面组件入口

11、不要再main.js中写任何业务相关代码，main.js里面最好能保证只有相关导入信息

12、个人会使用prettier规范约定代码习惯，我其实很喜欢这个工具。这样就能把大家的代码风格统一成一个

13、代码不要想着所有人都和你一样，要跟着项目走。并不是每一个项目都可以完整的工具链。比如小程序。

14、关于函数和变量命名大小驼峰都可以，保证字母之间清晰可见就行。比如常量用大写字符，我个人是不习惯的。习惯上哪怕同一个字母，我见到的时候也不一定能看懂。

15、能写注释最好都写注释

16、觉得文件有需要增加额外说明的时候添加一个README.md文件，愿意写最好啦

二、目录的组件形成和各个约定规范为什么这样定义

其实都知道大家不喜欢说教，说自己喜欢什么样子的就什么样子。更有甚至说不写注释是为了自己不可取代，如果是玩笑那最好。我喜欢我的项目我走了也能一目了然。而不是因为哪些莫须有的竞争力让代码很糟糕。所以我有代码洁癖。目前为止，每一个和我接触的同事都说我的项目是让人心情舒畅的，除非功能非常的复杂，不然有经验能力的都能很快上手。

1、assets，也可以是static

这个文件其实随着慢慢的发展没有什么特殊的存储了。老时代的人应该会划分下面三个文件夹：js，css，img。

分别存放三个静态资源。但是现在其实随着项目的开发似乎只有img可以存放了。但是依旧建议大家根据业务情况划分文件夹。css就不必要了，因为业务需要被独立出来了。

2、businessComponents和components

为什么这么划分其实是因为随着业务开发久了，我们的组件其实应该分为组件库组件和业务混合的组件。业务混合的比如支付组件弹窗，一些全局级联组件，这些是和业务相关的，你无法拆分到其他项目中使用。如果和非业务组件混合在一起，虽然可以，但是不好找。并且一个有想法的人应该会想着这些非业务组件其实慢慢积累就形成了类似ElementUI之类的组件库。

3、mixin

虽然都不提倡使用mixin，毕竟这玩意是全局污染的，如果编辑器不给力，你真不好找定义在哪。但是如果有的话请放在这里。

4、pages（views）

1、为什么不用view文件了呢？主要是小程序的影响，这样看着更加直观。

2、然后为什么不采用业务模块划分路由文件呢？

是因为你的页面实际上和业务关系确实很大，但是路由实际上是业务无关的是可以随意组合成为一个新的业务组合，那如果你早期根据业务严格划分了路由文件。后期又要拆怎么办呢？那不就乱套了。所以感觉一个路由一个文件。不要层层嵌套了

3、关于文件和组件的划分主要是为了让结构更加清晰。所有东西堆在一起页面小还好，多了就很麻烦了

5、power

这个文件没有严格的划分，你也可以放在业务组件中或者其他。我提出来的原因是因为这个是全局影响的，必定是处于业务最上层的。

6、router

大家应该都差不多这么干，但是我看很多开源的组件库之类的会把router和菜单配置结合在一起。然后把路由守卫等提取到另一个文件下面去。

这里最大的问题是你的路由和页面严重耦合，有些甚至为了路由的简化书写，采用上层名称和下层名称相互结合形成一个新的路由。但是你们要想想后端一般怎么权限配置的，是不是就一个路径就行了。然后后端返回的时候是全路径，那么你就很痛苦了。因为你无法清晰的把控页面路径是什么。并且路由冲突的可能性会加剧。所以我这个文件夹只是做路由在代码层面的注册就行了。别和业务严重耦合了，后端可不会说迁就前端来做东西。小公司前端岂不是更加！

7、store

个人做法：作为前端的数据库（就像以前后台会在数据库写存储过程书写业务逻辑，但是现在不需要了），只做数据缓存，并且结合插件融合storege缓存。只做数据缓存，并且统一全局的缓存操作。不允许其他页面独立api操作缓存函数。

这个就有的说到了，需要讲讲历史了。

A、先说说大家都怎么干的

1、umi.js（react框架）：redux等等

2、vue：vuex

一般都采用这个文件夹作为一个全局的数据共享中心。其实说一句vue做的不是很好的地方在于大家一开始就用错方式了。react实际上是每个业务文件都会有一个store.js文件。这是为了提取公共的部分，为了避免react一些性能问题和数据聚合共享方面的方式所以每个文件下面一个。

到了vue的时候大家觉得放在全局很好。但是把和业务严重耦合部分放在全局真的很不优雅。层次这么高，容易让人觉得这个数据是可以大范围共享的。实际上仅仅是为了一个业务需要而做的。

B、新的api和数据共享方式让store的职能越来越无用

1、react：hooks的出现，provide使用

2、vue：vue.observable，provide，hooks

3、js文件内存缓存机制

这里每一种都可以让store这种方式被取代，并且让数据共享和缓存更好的和业务相互嵌合。更加优雅，并且不会增加首屏的加载速度

所以我把store定义成了一个前端数据库，一个只做数据全局缓存的地方。并且统一缓存操作，把混乱的localStorge等等缓存操作统一化。那么结构就更加清晰了

8、theme（主题）

这里其实最早是从assets的css文件夹提出来的。因为我们会有很多公共的css样式需要全局使用。或者需要scss等的函数，还有存在全局换肤等等。那么提出来，会更加直观。

9、tool（utils）

工具函数集合，没啥好讲的

10、App.vue，CreateApp.js，main.js

主要是讲下main.js和CreateApp.js

不管新手老手，都喜欢把指令啊，工具函数啊都放在main.js但是入口文件很有必要保持一个清晰的结构。入口文件就像package.json一样，应该让人一眼可以清晰的知道这个项目的依赖情况还有基本入口的。搞那么多业务工具职责就乱了。

三、原则总结

1、这样划分的原因是为了项目更加直观简单，不让让接手的人耗费在无意义的项目结构熟悉上

2、做到复制的是什么，你用的时候就是什么，代码效率提升很大

3、规范跟着项目走，一刀切容易让人反感。

个人比较推荐使用webstorm开发，这恐怕是老时代的人更加喜欢一些。要不是这货收费，vscode就没有什么事情了。不管是性能，开发效率上webstorm上完爆。仅仅是定义跳转这件事上就完爆。

推荐：

阿里前端九部文档：https://www.yuque.com/fe9/basic

我的掘金文章地址：https://juejin.cn/post/6967537686571647013/