React文件名和目录规范最佳实践记录(总结篇)

目录
  • 文件类型
  • 处理index文件
  • 规范
  • 类型文件夹
  • 特性文件夹
    • 大驼峰命名
    • 烧烤串命名

React在使用时非常灵活,如果没有一个规范约束项目,在开发过程中会非常混乱,本文将介绍几个优秀的规范。

文件类型

介绍文件名和目录前,需要先简述一下几种通用的类型,用来区分文件的功能。

  • component 组件文件
  • page 如果有路由(React Router、NextJS等),则有页面文件
  • util 需要复用的工具函数
  • helper 一段特定逻辑,不是通用工具,可复用也可仅作为代码拆分片段
  • hook 自定义React Hook
  • constant 定义常量,大写+下划线命名 CONSTANT_VALUE

处理index文件

在做组件或者页面的时候,你可能会划分组件,并把主组件用index.tsx导出。这样做的时候有一个好处就是可以按照文件夹名引入,从结构上看是很清晰的。

但是事实上,在编辑器中会有多个index.tsx文件,开发时需要看文件所在的文件夹,非常难受。

我的解决方案是,你的主组件应该和原来一样导出,index.ts 文件二次导出主组件。

你的 index.ts 应该这样写:

export * from './MainComponent';
export { default } from './MainComponent';

虽然把一个文件变成了两个文件,但是有效地减少了开发时的心智负担。

接下来规范中所有的 index.ts 都是这个作用

规范

类型文件夹

这应该是一个比较官方的规范,很多项目都在使用。

此处使用大驼峰命名组件(component)和页面(page),其他文件通常用小驼峰

如果你有路由,那么此时component中的组件应为通用组件。

src/
├── components/
│   ├── MyHeader.tsx
│   └── MyFooter.tsx
├── pages/
│   ├── Home.tsx
│   ├── About.tsx
│   └── Widget/
│       ├── components/
│       │   ├── Tool.tsx
│       │   └── Option.tsx
│       ├── helpers/
│       │   └── setOptionStorage.ts
│       ├── Widget.tsx
│       └── index.ts
├── hooks/
│   └── useTheme.ts
├── utils/
│   └── getRamdomNumber.ts
└── constants.ts

这个规范在小项目中尚可实行。但是如果相对复杂的项目,由于文件夹层数多,会导致引入混乱。接下来会推荐特性分类的规范。

示例项目:Ant Design Pro

特性文件夹

特性文件夹分类很好地解决了层数过多的问题,增加平铺的可能。并更直观地展示了代码逻辑,方便维护。

大驼峰命名

这种命名规范中,除了组件和页面以外,所有的文件都需要添加类型后缀。
并且在一个特性中,可以将类型相同的函数放在一个文件内。
例如 Widget.helper.ts Widget.util.ts

如果是通用的或复用的代码,都建议放到 common 文件夹统一管理,其余特性文件夹均大写。

非组件或页面的独立的文件,请使用烧烤串命名(中划线分割)

同一个特性的组件可以不另设 components 文件夹

src/
├── common/
│   ├── components/
│   │   ├── MyHeader.tsx
│   │   └── MyFooter.tsx
│   ├── utils/
│   │   └── get-random-number.util.ts
│   ├── hooks/
│   │   └── use-theme.hook.ts
│   └── constants.ts
├── Home/
│   └── Home.tsx
├── Widget/
│   ├── Tool.tsx
│   ├── Option.tsx
│   ├── Widget.helpers.ts
│   ├── Widget.utils.ts
│   ├── Widget.constants.ts
│   ├── Widget.tsx
│   └── index.ts
└── About/
    └── About.tsx

参考文章:Delightful React File/Directory Structure

烧烤串命名

这个实际上是参考了Angular规范,如果你对上面这个规范的大小写命名强迫症,不妨试试这个更严苛的规范。

  • 所有文件名、文件夹名都小写,使用烧烤串命名(中划线分割)。
  • 所有的文件都需要添加类型后缀。
  • 只有主要的页面组件可以放在特性文件夹底层,其余文件都需要在特性文件夹中再设置类型文件夹。
  • 每个函数都应该是一个文件,不要把相同功能的函数放在一个文件内。
  • 移除 index.ts 导出,因为文件名变长且有类型后缀,引入方便判断类型
src/
├── common/
│   ├── components/
│   │   ├── my-header.component.tsx
│   │   └── my-footer.component.tsx
│   ├── utils/
│   │   └── get-random-number.util.ts
│   ├── hooks/
│   │   └── use-theme.hook.ts
│   └── constants.ts
├── home/
│   └── home.page.tsx
├── widget/
│   ├── components/
│   │   ├── tool.component.tsx
│   │   └── option.component.tsx
│   ├── helpers/
│   │   └── set-option-storage.helper.ts
│   └── widget.page.tsx
└── about/
    └── about.page.tsx

示例项目

到此这篇关于几种React文件名和目录规范最佳实践的文章就介绍到这了,更多相关React文件名和目录实践内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • React如何利用相对于根目录进行引用组件详解

    前言 本文主要给大家介绍了关于React利用相对于根目录进行引用组件的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 在对自己开发的组件中经常会做诸如以下的引用: import genFetchEntryListArgs from '../../../utils/table/genFetchEntryListArgs'; import { parseQuery, stringifyQuery } from '../../../utils/query'; import

  • react+antd 递归实现树状目录操作

    1.写在前面 作为前端小白的我一直对算法和数据结构浅尝辄止,哝,吃亏了.使用多次递归实现数据格式化后将数据进行树状展示的目的,分享一下我这次挠头的经历~ 2.数据 后台传过来的数据大概是这样的 { "data":[ { "id":1, "name":"一级节点", "parentId":0, "isValid":true, "canAddChild":true, &q

  • apache下面二级目录部署react/vue的方法

    本文主要是记录一下在apache二级目录上面部署react和vue项目.根目录下面部署很简单,但是在二级目录下就需要在webpack的配置或者vue-cli的配置文件以及路由组件做一些简单调整.由于mac系统自己带了apache,所以我们只需要开启就可以了. 配置apache 在终端中输入sudo apachectl start,然后在浏览器中输入"http://localhost",如果出现"It works!"则说明apache启动成功. 由于mac系统在当前用

  • React文件名和目录规范最佳实践记录(总结篇)

    目录 文件类型 处理index文件 规范 类型文件夹 特性文件夹 大驼峰命名 烧烤串命名 React在使用时非常灵活,如果没有一个规范约束项目,在开发过程中会非常混乱,本文将介绍几个优秀的规范. 文件类型 介绍文件名和目录前,需要先简述一下几种通用的类型,用来区分文件的功能. component 组件文件 page 如果有路由(React Router.NextJS等),则有页面文件 util 需要复用的工具函数 helper 一段特定逻辑,不是通用工具,可复用也可仅作为代码拆分片段 hook

  • SpringMVC使用hibernate-validator进行参数校验最佳实践记录

    在我们用Controller接收参数后,往往需要对参数进行校验.如果我们手写校验的话,就会有一堆的判空代码,看起来很不优雅,写起来也费时费力.下面来看下通过hibernate-validator来进行优雅的参数校验. 首先需要引入依赖: <dependency> <groupId>org.hibernate.validator</groupId> <artifactId>hibernate-validator</artifactId> <v

  • .NET Core 2.1中HttpClientFactory的最佳实践记录

    前言 ASP.NET Core 2.1中出现一个新的HttpClientFactory功能, 它有助于解决开发人员在使用HttpClient实例从其应用程序发出外部Web请求时可能遇到的一些常见问题. 介绍 在.NETCore平台的2.1新增了HttpClientFactory,虽然HttpClient这个类实现了disposable,但使用它的时候用声明using包装块的方式通常不是最好的选择.处理HttpClient,底层socket套接字不会立即释放.该HttpClient类是专为多个请求

  • react+ts实现简单jira项目的最佳实践记录

    练手的一套项目 react+ts 虽然内容较少,但是干货挺多,尤其是对hooks的封装,ts的泛型的理解,使用更上一层楼 项目代码:https://gitee.com/fine509/react_jiar 效果图 这是三个主要页面,还有一些小细节 等等 一些值得注意的地方(只是讲大概的功能,没有具体的详解怎么用) 使用错误边界处理,getDerivedStateFromError来处理当某个页面某处地方有报错的时候显示报错组件而不是挂掉. useSearchParams的使用 这个api可以获取

  • iOS中创建Model的最佳实践记录

    前言 作为一个优秀的程序员,或者想成为优秀的程序员,最基本的你得有MVC编程思想,那么你就要对JSON获取的数据建Model,将service和controller层都分离,从而做到低耦合.现在有很多利用runtime能快速的将json数据转为一个Model.但是我在做项目的时候,发现创建Model(特别是属性特多的)写属性代码很浪费时间,降低了编程效率.后来我自己就写了个好玩的能省去时间创建Model的一个方法,下面话不多说了,来一起看看详细的介绍吧 Immutable Model 我们以Us

  • Go单体服务开发最佳实践总结

    目录 单体最佳实践的由来 单体示例 单体实现 API 定义 Download 服务定义 Upload 服务定义 问题来了 定义单体服务接口 生成单体服务 实现业务逻辑 单体开发的总结 项目地址 单体最佳实践的由来 对于很多初创公司来说,业务的早期我们更应该关注于业务价值的交付,并且此时用户体量也很小,QPS 也非常低,我们应该使用更简单的技术架构来加速业务价值的交付,此时单体的优势就体现出来了. 正如我直播分享时经常提到,我们在使用单体快速交付业务价值的同时,也需要为业务的发展预留可能性,我们可

  • React 条件渲染最佳实践小结(7种)

    在 React 中,条件渲染可以通过多种方式,不同的使用方式场景取决于不同的上下文. 在本文中,我们将讨论所有可用于为 React 中的条件渲染编写更好的代码的方法. 条件渲染在每种编程语言(包括 javascript)中都是的常见功能. 在 javascript 中,我们通常使用if else 语句,switch case语句和三元运算符编写条件渲染. 以上所有这些方法都适用于 React. 但是问题是,我们如何才能有效地使用它们? 像你知道的那样,React 具有 JSX 标记,通常我们需要

  • MySQL 的 21 个规范、优化最佳实践!

    前言 每一个好习惯都是一笔财富,本文分 SQL 后悔药,SQL 性能优化,SQL 规范优雅三个方向,分享写 SQL 的 21 个好习惯和最佳实践! 写完SQL先explain查看执行计划(SQL性能优化) 日常开发写 SQL 的时候,尽量养成这个好习惯呀:写完 SQL 后,用 explain 分析一下,尤其注意走不走索引. 操作 delete 或者 update 语句,加个 limit(SQL后悔药) 在执行删除或者更新语句,尽量加上 limit,以下面的这条 SQL 为例吧: delete f

  • react后台系统最佳实践示例详解

    目录 一.中后台系统的技术栈选型 1. 要做什么 2. 要求 3. 技术栈怎么选 二.hooks时代状态管理库的选型 context redux recoil zustand MobX 三.hooks的使用问题与解决方案 总结 一.中后台系统的技术栈选型 本文主要讲三块内容:中后台系统的技术栈选型.hooks时代状态管理库的选型以及hooks的使用问题与解决方案. 1. 要做什么 我们的目标是搭建一个适用于公司内部中后台系统的前端项目最佳实践. 2. 要求 由于业务需求比较多,一名开发人员需要负

随机推荐