如何写出更优雅的 React 组件 - 代码结构篇

开发 前端
我们从代码结构的角度来谈谈如何设计一个更优雅的 React 组件。优秀的组件有着一个清晰的目录结构。这里的目录结构分为项目级结构、单组件级结构。

[[438981]]

在日常团队开发中大家写的组件质量参差不齐,风格千差万别。会因为很多需求导致组件无法扩展,或难以维护。导致很多业务组件的功能重复,使用起来相当难受。我们从代码结构的角度来谈谈如何设计一个更优雅的 React 组件。

组件目录结构

优秀的组件有着一个清晰的目录结构。这里的目录结构分为项目级结构、单组件级结构。

容器组件/展示组件

在项目中我们的目录结构可以根据组件和业务耦合来划分,和业务的耦合程度越低, 可复用性越强。展示组件只关注展示层, 可以在多个地方被复用, 它不耦合业务。容器组件主要关注业务处理,容器组件通过组合展示组件来构建完整视图。

示例:

  1. src/ 
  2.   components/ (通用组件,与业务无关,可被其他所有组件调用) 
  3.     Button/ 
  4.       index.tsx 
  5.   containers/ (容器组件,与业务深度耦合,可被页面组件调用) 
  6.     Hello/ 
  7.       Kitty/ (容器组件中的特有组件,不能与其他容器组件共享) 
  8.       index.tsx 
  9.     World/ 
  10.       components/ 
  11.       index.tsx 
  12.   hooks/ (公共的 hooks) 
  13.   pages/ (页面组件,特定的页面,无复用性) 
  14.     my-app/ 
  15.   store/ (状态管理) 
  16.   services/ (接口定义) 
  17.   utils/ (工具类) 

组件目录结构

我们可以根据文件类型/功能/职责等划分不同的目录。

  1. 根据文件类型可以分出 images 等目录
  2. 根据文件功能可以分出 __tests__ 、demo 等目录
  3. 根据文件职责可以分出 types 、utils 、hooks 等目录
  4. 根据组件的特点可以用目录划分归类
  1. HelloWorld/ (普通的业务组件) 
  2.   __tests__/ (测试用例) 
  3.   demo/ (组件示例) 
  4.   Bar/ (特有组件分类) 
  5.     Kitty.tsx (特有组件) 
  6.     Kitty.module.less 
  7.   Foo/ 
  8.   hooks/ (自定义 hooks) 
  9.   images/ (图片目录) 
  10.   types/ (类型定义) 
  11.   utils/ (工具类方法) 
  12.   index.tsx (出口文件) 

比如我最近写的一个表格组件的目录结构:

  1. ├─SheetTable 
  2. │  ├─Cell 
  3. │  ├─Header 
  4. │  ├─Layer 
  5. │  ├─Main 
  6. │  ├─Row 
  7. │  ├─Store 
  8. │  ├─types 
  9. │  └─utils 

组件内部结构

组件内部需要保持良好的顺序逻辑,统一团队规范。约定俗成后,这样一目了然定义可以让我们更清晰地去 Review。

导入顺序

导入顺序为 node_modules -> @/ 开头文件 -> 相对路径文件 -> 当前组件样式文件

  1. // 导入 node_modules 依赖 
  2. import React from'react'
  3. // 导入公共组件 
  4. import Button from'@/components/Button'
  5. // 导入相对路径组件 
  6. import Foo from'./Foo'
  7. // 导入对应同名的 .less 文件,命名为 styles 
  8. import styles from'./Kitty.module.less'

使用 组件名 + Props 形式命名 Props 类型并导出。

类型与参数书写的顺序保持一致,一般以 [a-z] 的顺序定义。变量的注释禁止放末尾,原因是会导致编辑器识别错位,无法正确提示

  1. /** 
  2.  * 类型定义(命名:组件名 + Props) 
  3.  */ 
  4. export interface KittyProps { 
  5.   /** 
  6.    * 多行注释(建议) 
  7.    */ 
  8.   email: string; 
  9.   // 单行注释(不推荐) 
  10.   mobile: string; 
  11.   username: string; // 末尾注释(禁止) 

使用 React.FC 定义

  1. const Kitty: React.FC<KittyProps> = ({ email, mobile, usename }) => {}; 

泛型,代码提示更智能

以下例子,可以用过泛型让 value 和 onChange 回调中的类型保持一致,并做到编辑器智能类型提示。

注意:泛型组件无法使用 React.FC 类型

  1. export interface FooProps<Value> { 
  2.   value: Value; 
  3.   onChange: (value: Value) =>void; 
  4.  
  5. exportfunction Foo<Value extends React.Key>(props: FooProps<Value>) {} 

禁止直接使用 any 类型

无论隐式和显式的方式,都不推荐使用 any 类型。定义了 any 的参数会让使用该组件的人产生极度困惑,无法明确地知道其中的类型。我们可以通过泛型的方式去声明。

  1. // 隐式 any (禁止) 
  2. let foo; 
  3. function bar(param) {} 
  4.  
  5. // 显式 any (禁止) 
  6. let hello: any
  7. function world(param: any) {} 
  8.  
  9. // 使用泛型继承,缩小类型范围 (推荐) 
  10. function Tom<P extends Record<string, any>>(param: P) {} 

一个组件对应一个样式文件

我们以组件的颗粒度大小为抽象单元,样式文件则应与组件本身保持一致。不推荐交叉引入样式文件的做法,这样会导致重构混乱,无法明确当前这个样式被多少个组件使用。

  1. - Tom.tsx 
  2. - Tom.module.less 
  3. - Kitty.tsx 
  4. - Kitty.module.less 

内联样式

避免偷懒,要时刻保持优雅,随手一个 style={} 是极为不推荐的。这样不仅每次渲染都有重新创建的消耗,而且是清晰的 JSX 上的噪点,影响阅读。

组件行数限制

组件需要明确的注释,并保持 300 行以内的代码行数。代码行数可以通过配置 eslint 来做到限制(可以跳过注释/空行的的统计):

  1. 'max-lines-per-function': [2, { max: 320, skipComments: true, skipBlankLines: true }], 

组件内部编写代码的顺序

组件内部的顺序为 state -> custom Hooks -> effects -> 内部 function -> 其他逻辑 -> JSX

  1. /** 
  2.  * 组件注释(简明概要) 
  3.  */ 
  4. const Kitty: React.FC<KittyProps> = ({ email }) => { 
  5.   // 1. state 
  6.  
  7.   // 2. custom Hooks 
  8.  
  9.   // 3. effects 
  10.  
  11.   // 4. 内部 function 
  12.  
  13.   // 5. 其他逻辑... 
  14.  
  15.   return ( 
  16.     <div className={styles.wrapper}> 
  17.       {email} 
  18.       <Child /> 
  19.     </div> 
  20.   ); 
  21. }; 

事件函数命名区分

内部方法按照 handle{Type}{Event} 命名,例如 handleNameChange。暴露外部的方法按照 on{Type}{Event},例如 onNameChange。这样做的好处可以直接通过函数名区分是否为外部参数。

例如 antd/Button 组件片段:

  1. const handleClick = (e: React.MouseEvent<HTMLButtonElement | HTMLAnchorElement, MouseEvent>) => { 
  2.   const { onClick, disabled } = props; 
  3.   if (innerLoading || disabled) { 
  4.     e.preventDefault(); 
  5.     return
  6.   } 
  7.   (onClick as React.MouseEventHandler<HTMLButtonElement | HTMLAnchorElement>)?.(e); 
  8. }; 

继承原生元素 props 定义

原生元素 props 都继承了 React.HTMLAttributes。某些特殊元素也会扩展自己的属性,例如 InputHTMLAttributes。

我们定义一个自定义组件则可以通过继承 React.InputHTMLAttributes ,让其类型具有所有 input 的特性。

  1. export interface KittyProps extends React.InputHTMLAttributes<HTMLInputElement> { 
  2.   /** 
  3.    * 新增支持回车键事件 
  4.    */ 
  5.   onPressEnter?: React.KeyboardEventHandler<HTMLInputElement>; 
  6.  
  7. function Kitty({ onPressEnter, onKeyUp, ...restProps }: KittyProps) { 
  8.   function handleKeyUp(e: React.KeyboardEvent<HTMLInputElement>) { 
  9.     if (e.code.includes('Enter') && onPressEnter) { 
  10.       onPressEnter(e); 
  11.     } 
  12.     if (onKeyUp) { 
  13.       onKeyUp(e); 
  14.     } 
  15.   } 
  16.  
  17.   return<input onKeyUp={handleKeyUp} {...restProps} />; 

避免循环依赖

如果你写的组件包含了循环依赖, 这时候你需要考虑拆分和设计模块文件

  1. // --- Foo.tsx --- 
  2. import Bar from'./Bar'
  3.  
  4. export interface FooProps {} 
  5.  
  6. exportconst Foo: React.FC<FooProps> = () => {}; 
  7. Foo.Bar = Bar; 
  8.  
  9. // --- Bar.tsx ---- 
  10. import { FooProps } from'./Foo'

上面 Foo 和 Bar 组件就形成了一个简单循环依赖, 尽管它不会造成什么运行时问题. 解决方案就是将 FooProps 抽取到单独的文件:

  1. // --- types.ts --- 
  2. export interface FooProps {} 
  3.  
  4. // --- Foo.tsx --- 
  5. import Bar from'./Bar'
  6. import { FooProps } from'./types'
  7.  
  8. exportconst Foo: React.FC<FooProps> = () => {}; 
  9. Foo.Bar = Bar; 
  10.  
  11. // --- Bar.tsx ---- 
  12. import { FooProps } from'./types'

相对路径不要超过两级

当项目复杂的情况下,目录结构会越来越深,文件会有很长的 ../ 路径,这样看起来很不优雅:

  1. import { ButtonProps } from'../../../components/Button'

我们可以通过在 tsconfig.json 中配置

  1. "paths": { 
  2.   "@/*": ["src/*"

和 vite 中配置

  1. alias: { 
  2.   '@/': `${path.resolve(process.cwd(), 'src')}/`, 

现在我们可以导入相对于 src 的模块:

  1. import { ButtonProps } from'@/components/Button'

当然更彻底一点,可以使用 monorepo 的项目管理方式来解耦各个组件。只要搭建一套脚手架,就能管理(构建、测试、发布)多个 package

不要直接使用 export default 导出未命名的组件

这种方式导出的组件在 React Inspector 查看时会显示为 Unknown

  1. // 错误做法 
  2. exportdefault () => {}; 
  3.  
  4. // 正确做法 
  5. exportdefaultfunction Kitty() {} 
  6.  
  7. // 正确做法:先声明后导出 
  8. function Kitty() {} 
  9.  
  10. exportdefault Kitty; 

结语

以上是写 React 组件在目录结构以及编码规则上需要注意的点,后续我们讲解如何在思维上保持优雅。

 

责任编辑:姜华 来源: 前端星辰
相关推荐

2021-12-13 14:37:37

React组件前端

2022-03-11 12:14:43

CSS代码前端

2022-05-13 08:48:50

React组件TypeScrip

2016-11-25 13:50:15

React组件SFC

2023-12-21 10:26:30

​​Prettier

2021-01-04 07:57:07

C++工具代码

2019-09-20 15:47:24

代码JavaScript副作用

2017-09-01 14:18:50

前端React组件

2020-05-14 09:15:52

设计模式SOLID 原则JS

2018-07-12 14:20:33

SQLSQL查询编写

2020-07-15 08:17:16

代码

2020-05-08 14:45:00

JS代码变量

2022-08-09 13:22:26

Hooksreactvue

2013-06-07 14:00:23

代码维护

2020-05-11 15:23:58

CQRS代码命令

2021-09-01 08:55:20

JavaScript代码开发

2021-11-30 10:20:24

JavaScript代码前端

2022-02-08 19:33:13

技巧代码格式

2022-02-17 10:05:21

CSS代码前端

2020-05-19 15:00:26

Bug代码语言
点赞
收藏

51CTO技术栈公众号