前端规范-目录结构命名规范

前端BA
237 阅读5分钟

前言

命名规范是为了提高代码的可读性和维护性

命名规则

一般用小写英文 、 数字、 - 这些字符，命名最好是通用英文，尽量不用或者少用拼音。

项目命名

全部采用小写方式， 以中划线分隔。

例：element-plus, ant-design, vue3-vite-admin

目录结构命名

目录结构的命名应语义清晰，一目了然。在常见的命名规范中，我建议采用短横线命名（Kebab Case），全部以小写的形式在目录中展示出来，更具有直观性。在团队中保持统一，提高一致性和可读性，不要几种命名方式混着用

  1. 全部采用小写方式
  2. 单词语义明确，严禁使用拼音与英文混合的方式
  3. 多个单词使用短横线分隔，建议不超过3个单词
  4. 目录结构层级，建议不超过4层
src                               源码目录
|-- api                              所有 API 接口
|-- assets                           静态资源，包括 images、icons、styles 等
|-- components                       公共组件
    |-- table                            table公用组件
        |-- index.vue                    table入口文件
        |-- base-search.vue              搜索组件
        |-- base-table.vue               table组件
        |-- base-pagination.vue      分页组件
|-- config                           配置信息
|-- router                           路由，统一管理
|-- views                            视图目录
    |-- role                             role 模块
        |-- components                       role 模块通用组件文件夹
            |-- role-list.vue                    role 列表页面
            |-- role-add.vue                     role 新建页面
            |-- role-update.vue                  role 更新页面
        |-- common                       role 模块通用工具方法
            |-- api.ts                           业务api
            |-- hooks.ts                         业务hooks
    |-- employee                         employee 模块
    ...

业务目录命名

首先在结构上要划分好，组件统一放在components文件下，此组件用到的公用的工具方法放在common或者shared下，不要全部放在一个目录下，导致混乱，打开目录，应一目了然

有时候不明确哪些工具方法需要提到全局的hook/utils/api，我的建议是在写的时候先放置在当前组件目录下，如果后续在其他组件再使用到这个方法，再考虑提到全局的公用目录，写一个不常用，且关联性不强的代码在公用目录，公用文件和方法多了之后，你就知道这是对公用代码的一种污染

 |- 组件目录
    |- components 组件
        |- xxx.vue 业务组件
    |- common  该组件下的工具方法
        |- hooks.ts   
        |- utils.ts
        |- config.ts
        |- types.ts
        |- constants.ts
        |- api.ts

Vue3技巧与编码规范-优雅永不过时

为什么api.ts业务接口请求不是放在公共api目录下,而是推荐放在业务代码目录下? 我们看大部分的前端开源管理系统项目的api接口请求都是放在公共的api目录下, 但是在业务越来越复杂的项目中，api目录可变得非常庞大，难以维护,出现以下情况:

  1. api目录下的业务api请求ts文件过于庞大,如果文件夹语意不明确,根本无法知道是属于哪个业务的
  2. api目录下的业务api请求js,正常情况都是与业务紧密关联的,统一放在API目录下降低了代码的可读性

单独放在业务目录下的好处:

方便跳转,在该业务目录下即可直达业务api请求ts文件,方便维护

我在A业务目录下就能找到A业务的接口文件,随时修改,虽然vscode提供方便的跳转,但是如果开发到一半,整个业务不做了,或者该业务废弃,那剔除业务代码是很方便的,删掉该目录即可

api接口与业务联系更紧密,提高了代码可读性

组件名称的命名

以Vue为例，组件名建议始终由多个单词组成，这样做可以避免与现有和未来的 HTML 元素冲突，因为所有 HTML 元素名称都是由单个单词组成的。

官方有两种推荐的命名方式，大驼峰(PascalCase)以及短横线(kebab-case)，因为在使用上，PascalCase是兼容kebab-case命名的，大多数人，在目录结构上会使用PascalCase，但是我认为应该要保持目录结构的统一性和直观性，应该使用kebab-case命名，为了解决使用上的兼容性，我们可以在组件的name配置上使用PascalCase作为组件名

// vue2
export default {
  name: 'TodoItem'
};

// vue3
defineOptions({
  name:'TodoItem',
})

1. 紧密耦合的组件名称:

与其父组件紧密耦合的子组件应包含父组件名称作为前缀。 命名规则: 父组件名称+子组件名称

好处:

关系更紧密,通过看组件名即可知道2个组件的联系

编辑器友好,例如VsCode,通常按字母顺序组织文件，因此这也使这些相关文件彼此相邻;

components/
|- todo-list.vue
|- todo-list-item.vue
|- todo-list-item-button.vue
|- user-profile-options.vue （完整单词）
  1. 紧密耦合的组件名称

与其父组件紧密耦合的子组件应包含父组件名称作为前缀。 命名规则: 父组件名称+子组件名称

好处:

关系更紧密,通过看组件名即可知道2个组件的联系

编辑器友好,例如VsCode,通常按字母顺序组织文件，因此这也使这些相关文件彼此相邻;

components/
|- todo-list.vue
|- todo-list-item.vue
|- todo-list-item-button.vue
|- user-profile-options.vue （完整单词）

2. index入口文件的使用场景

在工作遇到index入口文件滥用的情况，简单分析下使用场景

  1. 集中管理的 utils/styles ，方便使用及导出
  2. 封装公用的组件，使用 index.vue 作为入口文件
avatar
文章
阅读
粉丝