?

前言

原文链接：https://dev.to/awnton/7-code-smells-in-react-components-5f66

作者信息：Anton Gunnarsson

翻译许可：

Agree

正文

自从使用?React?后，我见过越来越多可值得优化的点，比如：

• 大量的?props

  
  



• props?的不兼容性

  
  



• props?复制为?state

  
  



• 返回?JSX?的函数

  
  



• state?的多个状态

  
  



• useState?过多

  
  



• 复杂的?useEffect

  
  

在本文中，我想分享几个技巧，这些技巧将改善你的React代码。

大量的 props

如果需要把大量的?props?传递到一个组件中，那么很有可能 该组件可再进一步拆分。

问题来了，“大量” 具体是多少呢？答案是 看情况。

假设你正在开发 一个包含 20 个或更多?props?的组件时，你想再添加一些?props?完善其他功能，这时有两点可以参考 是否应拆分组件：

该组件是否做了多件事？

像函数一样，一个组件应该只做好一件事，所以考虑下 将组件拆分成多个小组件是否会更好。

例如，该组件存在?props?的不兼容性?或?返回?JSX?的函数。

该组件是否可被合成？

开发中，组合是一种很好的模式但经常被忽视。

如果你的组件中存在将不相干逻辑塞到一起的情况，是时候考虑使用组合了。

假设我们有一个表单组件来处理某组织的用户信息:

??user={userData}
??organization={organizationData}
??categories={categoriesData}
??locatiOns={locationsData}
??OnSubmit={handleSubmit}
??OnCancel={handleCancel}
??...
/>

通过该组件的?props?，我们可看到它们都与组件提供的功能密切相关。

该组件看起来并无大碍，但如果将其中的一些?props?分担到子组件，那么数据流就会更清晰。

??
??
??
??

现在，我们已经看到该表单组件只处理提交和取消动作，其他范围内的事情，都交给了对应的子组件。

是否传递了很多有关配置的?props

在某些情况下，将多个有关配置的?props?组合成一个?options?是个不错的实践。

假设我们有一个可显示某种表格的组件：

??data={gridData}
??pagination={false}
??autoSize={true}
??enableSort={true}
??sortOrder="desc"
??disableSelection={true}
??infiniteScroll={true}
??...
/>

我们可以很清楚地看出，该组件除了?data?外其余的?props?都是与配置有关的。

如果将多个配置?props?合成为一个?options?，就可更好地控制组件的选项，规范性也得到提升。

const?options?=?{
??pagination:?false,
??autoSize:?true,
??enableSort:?true,
??sortOrder:?‘desc‘,
??disableSelection:?true,
??infiniteScroll:?true,
??...
}
??data={gridData}
??optiOns={options}
/>

props 的不兼容性

避免组件之间传递不兼容的?props。

假设你的组件库中有一个??组件，而该组件开始时仅用于处理文本，但过了一段时间后，你将它用于电话号码处理。

你的实现可能如下：

function?Input({?value,?isPhoneNumberInput,?autoCapitalize?})?{
??if?(autoCapitalize)?capitalize(value)
??return?
}

问题在于，isPhoneNumberInput?与?autoCapitalize?之间并不存在关联，将一个手机号首字母大写是没有任何意义的。

在这种情况下，我们可以将其分割成多个小组件，来明确具体的职责，如果有共享逻辑，可以将其放到?hooks?中。

function?TextInput({?value,?autoCapitalize?})?{
??if?(autoCapitalize)?capitalize(value)
??useSharedInputLogic()
??return?
}
function?PhoneNumberInput({?value?})?{
??useSharedInputLogic()
??return?
}

虽然上面例子有点勉强，可当发现组件的props存在不兼容性时，是时候考虑拆分组件了。

props 复制为 state

如何更好地将?props?作为?state?的初始值。

有如下组件：

function?Button({?text?})?{
??const?[buttonText]?=?useState(text)
??return?{buttonText}
}

该组件将?text?作为?useState?的初始值，可能会导致意想不到的行为。

实际上该组件已经关掉了?props?的更新通知，如果?text?在上层被更新，它将仍呈现 接受到?text?的第一次值，这更容易使组件出错。

一个更实际场景是，我们想基于?props?通过大量计算来得到新的?state。

在下面的例子中，slowlyFormatText?函数用于格式化?text，注意 需要很长时间才能完成。

function?Button({?text?})?{
??const?[formattedText]?=?useState(()?=>?slowlyFormatText(text))
??return?{formattedText}
}

解决此问题 最好的方案是 使用?useMemo?代替?useState。

function?Button({?text?})?{
??const?formattedText?=?useMemo(()?=>?slowlyFormatText(text),?[text])
??return?{formattedText}
}

现在?slowFormatFormat?仅在?text?更改时运行，并且没有阻断 上层组件更新。

进一步阅读：Writing resilient components by Dan Abramov。

返回 JSX 的函数

不要从组件内部的函数中返回?JSX。

这种模式虽然很少出现，但我还是时不时碰到。

仅举一个例子来说明:

function?Component()?{
??const?topSection?=?()?=>?{
????return?(
??????
????????

Component?header

该例子虽然看起来没什么问题，但其实这会破坏代码的整体性，使维护变得困难。

要么把函数返回的?JSX?直接内联到组件内，要么将其拆分成一个组件。

有一点需要注意，如果你创建了一个新组件，不必将其移动到新文件中的。

如果多个组件紧密耦合，将它们保存在同一个文件中是有意义的。

state 的多个状态

避免使用多个布尔值来表示组件状态。

当编写一个组件并多次迭代后，很容易出现这样一种情况，即内部有多个布尔值来表示 该组件处于哪种状态。

比如下面的例子：

function?Component()?{
??const?[isLoading,?setIsLoading]?=?useState(false)
??const?[isFinished,?setIsFinished]?=?useState(false)
??const?[hasError,?setHasError]?=?useState(false)
??const?fetchSomething?=?()?=>?{
????setIsLoading(true)
????fetch(url)
??????.then(()?=>?{
????????setIsLoading(false)
????????setIsFinished(true)
??????})
??????.catch(()?=>?{
????????setHasError(true)
??????})
??}
??if?(isLoading)?return?
??if?(hasError)?return?
??if?(isFinished)?return?
??return?
}

当按钮被点击时，我们将?isLoading?设置为?true，并通过?fetch?执行网络请求。

如果请求成功，我们将?isLoading?设置为?false，isFinished?设置为?true，如果有错误，将?hasError?设置为?true。

虽然这在技术上是可行的，但很难推断出组件处于什么状态，而且不容易维护。

并且有可能最终处于“不可能的状态”，比如我们不小心同时将?isLoading?和?isFinished?设置为?true。

解决此问题一劳永逸的方案是 使用枚举来管理状态。

在其他语言中，枚举是一种定义变量的方式，该变量只允许设置为预定义的常量值集合，虽然在Javascript?中不存在枚举，但我们可以使用字符串作为枚举：

function?Component()?{
??const?[state,?setState]?=?useState(‘idle‘)
??const?fetchSomething?=?()?=>?{
????setState(‘loading‘)
????fetch(url)
??????.then(()?=>?{
????????setState(‘finished‘)
??????})
??????.catch(()?=>?{
????????setState(‘error‘)
??????})
??}
??if?(state?===?‘loading‘)?return?
??if?(state?===?‘error‘)?return?
??if?(state?===?‘finished‘)?return?
??return?
}

通过这种方式，完全杜绝了出现 不可能状态的情况，并更利用扩展。

如果你使用?TypeScript?开发的话，则可以从定义时就实现枚举：

const?[state,?setState]?=?useState<‘idle‘?|?‘loading‘?|?‘error‘?|?‘finished‘>(‘idle‘)

useState 过多

避免在同一个组件中使用太多的?useState。

一个包含许多?useState?的组件可能会做多件事情，可以考虑是否要拆分它。

当然也存在一些复杂的场景，我们需要在组件中管理一些复杂的状态。

下面是自动输入组件的例子：

function?AutocompleteInput()?{
??const?[isOpen,?setIsOpen]?=?useState(false)
??const?[inputValue,?setInputValue]?=?useState(‘‘)
??const?[items,?setItems]?=?useState([])
??const?[selectedItem,?setSelectedItem]?=?useState(null)
??const?[activeIndex,?setActiveIndex]?=?useState(-1)
??const?reset?=?()?=>?{
????setIsOpen(false)
????setInputValue(‘‘)
????setItems([])
????setSelectedItem(null)
????setActiveIndex(-1)
??}
??const?selectItem?=?(item)?=>?{
????setIsOpen(false)
????setInputValue(item.name)
????setSelectedItem(item)
??}
??...
}

我们有一个?reset?函数，可以重置所有状态，还有一个?selectItem?函数，可更新一些状态。

这些函数都离不开?useState?定义的状态。如果功能继续迭代，那么函数就会越来越多，状态也会随之增加，数据流就会变得模糊不清。

在这种情况下，使用?useReducer?来代替 过多的?useState?是一个不错的选择。

const?initialState?=?{
??isOpen:?false,
??inputValue:?"",
??items:?[],
??selectedItem:?null,
??activeIndex:?-1
}
function?reducer(state,?action)?{
??switch?(action.type)?{
????case?"reset":
??????return?{
????????...initialState
??????}
????case?"selectItem":
??????return?{
????????...state,
????????isOpen:?false,
????????inputValue:?action.payload.name,
????????selectedItem:?action.payload
??????}
????default:
??????throw?Error()
??}
}
function?AutocompleteInput()?{
??const?[state,?dispatch]?=?useReducer(reducer,?initialState)
??const?reset?=?()?=>?{
????dispatch({?type:?‘reset‘?})
??}
??const?selectItem?=?(item)?=>?{
????dispatch({?type:?‘selectItem‘,?payload:?item?})
??}
??...
}

通过使用?reducer，我们封装了管理状态的逻辑，并将复杂的逻辑移出了组件，这使得组件更容易维护。

进一步阅读：state reducer pattern by Kent C. Dodds。

复杂的 useEffect

避免在?useEffect?中做太多事情，它们使代码易于出错，并且难以推理。

下面的例子中 犯了一个很大的错误：

function?Post({?id,?unlisted?})?{
??...
??useEffect(()?=>?{
????fetch(`/posts/${id}`).then(/*?do?something?*/)
????setVisibility(unlisted)
??},?[id,?unlisted])
??...
}

当?unlisted?改变时，即使?id?没有变，也会调用?fetch。

正确的写法应该是 将多个依赖分离：

function?Post({?id,?unlisted?})?{
??...
??useEffect(()?=>?{?//?when?id?changes?fetch?the?post
????fetch(`/posts/${id}`).then(/*?...?*/)
??},?[id])
??useEffect(()?=>?{?//?when?unlisted?changes?update?visibility
????setVisibility(unlisted)
??},?[unlisted])
??...
}

结束语

以上就是我分享的全部。请记住，这些绝不是规则，而是表明某些东西可能是“错误的”。