来源：React component code smells

译者：塔希

协议：CC BY-NC-SA 4.0

代码异味 是什么意思？简言之，就是暗示可能存在着深层次问题的代码结构。 (Wikipedia)

💩 代码异味

太多的 props 传递
矛盾的 props
从 props 派生 state
从函数中返回 JSX
多个布尔类型的 state
单组件中存在太多的 useState
庞大的 useEffect

太多的 props 传递

传递多个 props 到一个组件中暗示着也许这个组件应该被拆分。

你可能会问多少才算太多呢？嗯....“看情况”。你也许会面对这样一种情况，一个组件有着 20 或更多个 props ，但是你依然感到没问题，因为这个组件只做一件事。不过，当你被一个有太多 props 的组件给绊住时，又或者，你急切的想要在已经够长的 props 列表上，不知第几个的 “最后一次” 再加上一个 props ，你可能需要思考以下几个事情：

这个组件是不是做了多件事

和函数一样，组件也应该只做一件事，并做好，所以，时常检查能否把一个组件拆分成多个小组件是一个好习惯。比如说这个组件存在不合适的 props 或 从函数中返回 JSX 。

能进行组合抽象吗？

一个很好却经常被忽略模式是组合组件，而非在一个组件处理所有逻辑。假如说，我们有一个处理用户申请某组织的组件：

<ApplicationForm
  user={userData}
  organization={organizationData}
  categories={categoriesData}
  locations={locationsData}
  onSubmit={handleSubmit}
  onCancel={handleCancel}
  ...
/>

我们可以看到这个组件的所有 props 都和这个组件做什么有关系，但是依然存在优化的空间，可以将组件承担的一些责任迁移到它的 children 里

<ApplicationForm onSubmit={handleSubmit} onCancel={handleCancel}>
  <ApplicationUserForm user={userData} />
  <ApplicationOrganizationForm organization={organizationData} />
  <ApplicationCategoryForm categories={categoriesData} />
  <ApplicationLocationsForm locations={locationsData} />
</ApplicationForm>

现在，我们确保了 ApplicationForm 仅仅处理其应该承担的责任，提交和撤销表单。子组件可以很好在全局上仅仅处理与其自身相关的事情。这同样是一个使用 [React Context](https://zh-hans.reactjs.org/docs/context.html#gatsby-focus-wrapper) 来进行父子组件通信的好机会。

我是不是传递了太多“配置” props

在一些场景下，将一些 props 聚合到一个单独的对象上是个好注意，比如说，可以更轻松的交换配置。如果我们有一个战士排序表格的组件：

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

这些 props 中除了 data ，都可以认为是一些 配置项 。面对这种情况，将 Grid 改为接受一个 options 为 prop 也许是一个好主意。

const options = {
  pagination: false,
  autoSize: true,
  enableSort: true,
  sortOrder: 'desc',
  disableSelection: true,
  infiniteScroll: true,
  ...
}

<Grid
  data={gridData}
  options={options}
/>

这同样意味着当我们想要切换不同的选项时，很容易排除掉我们不想要的

矛盾的 props

避免传递看起来会互相冲突的 props

举个🌰，我们从创建一个处理文本的 <Input /> 组件开始，但过了一会，我们想要这个组件可以处理手机号的输入。组件的实现可能是这样：

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

  return <input value={value} type={isPhoneNumberInput ? 'tel' : 'text'} />
}

问题在于 isPhoneNumberInput 和 autoCapitalize 两个 props 在逻辑上是冲突的。我们是无法将手机号进行大写的。

在这种情况下，解决方法是将组件拆分成多个小组件。如果我们仍然有一些逻辑需要复用，我们可以将其移动到自定义 hook 中：

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

  return <input value={value} type="text" />
}

function PhoneNumberInput({ value }) {
  useSharedInputLogic()

  return <input value={value} type="tel" />
}

虽然这个例子显得有点刻意了，但找到逻辑上冲突的 props 是一个迹象，意味着，你应该检查组件是否需要被拆分。

从 props 派生 state

不要通过从 props 派生 state 使得数据之间的关联性消失。

思考下这个组件

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

  return <button>{buttonText}</button>
}

通过传递 text prop 作为 useState 的初始值，现在这个组件会忽略后续发生变化的 text prop。即使 text prop 的发生了变化，这个组件依然只会渲染其第一次得到的值。对于大多数 props 来说，这通常是一种意料之外的行为，会导致组件更容易产生 bug 。

作为这种现象更实际的一个例子是，想要根据 prop 进行一些计算，来派生出 state 。在下面的这个例子中，我们调用 slowlyFormatText 函数来格式化我们的 text prop ，执行这个函数需要花费大量的时间。

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

  return <button>{formattedText}</button>
}

通过将其放到 state 中，我们避免了函数反复执行的问题，但是我们同样使得组件无法响应 props 的更新。一个更好的方法是通过使用 [useMemo](https://zh-hans.reactjs.org/docs/hooks-reference.html#usememo) hook 来缓存函数结果，来解决这个问题

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

  return <button>{formattedText}</button>
}

现在 slowlyFormatText 仅仅在 text 改变的时候重新执行，不会导致组件无法响应更新

有时候我们的确需要忽略某个 prop 的所有后续更新，比如说一个颜色选择器，我们通过配置项来设置了所选颜色的初始值后，当用户选了另一个颜色时，我们不想更新覆写用户的选择的初始数据。在这种情况下，从 prop 的值直接复制到 state 是完全没问题的，不过为了表明这种行为模式，大多数开发者一般将加一些前缀到 prop 的名字，比如 initial 或 default ( initialColor / defaultColor ) 。

深入阅读：编写有弹性的组件 by Dan Abramov 。

从函数中返回 JSX

不要从一个组件内部使用函数返回 JSX

这种模式自从函数组件变得流行后已经大规模消失了，但我时而会遇到他们。用一个例子来演示下我的意思：

function Component() {
  const topSection = () => {
    return (
      <header>
        <h1>Component header</h1>
      </header>
    )
  }

  const middleSection = () => {
    return (
      <main>
        <p>Some text</p>
      </main>
    )
  }

  const bottomSection = () => {
    return (
      <footer>
        <p>Some footer text</p>
      </footer>
    )
  }

  return (
    <div>
      {topSection()}
      {middleSection()}
      {bottomSection()}
    </div>
  )
}

也许你刚开始会觉得没什么问题，与好的模式相比，这段代码会使得人们难以快速理解发生了什么，应该避免这种模式。可以通过内联 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 <Loader />
  if (hasError) return <Error />
  if (isFinished) return <Success />

  return <button onClick={fetchSomething} />
}

当按钮被点击时，我们将 isLoading 设置为 true ，然后是用 fetch 进行网络请求。如果请求是成功的，我们设置 isLoading 为 false ， isFinished 为 true ，否则我们设置 hasError 为 true ，如果存在 error 的话。

尽管组件可以正常的完成工作，却很难去理解当前组件所处的状态，并且比其他方案更容易出错。我们同于可能陷入到 ”非法状态“ 中，假如我们意外的同时将 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 <Loader />
  if (state === 'error') return <Error />
  if (state === 'finished') return <Success />

  return <button onClick={fetchSomething} />
}

这样做，我们避免了非法状态发生的可能，并使得识别组件当前状态变得容易起来。最终，如果你在使用某种类型系统比如说 TypeScript 那就更好了，因为你可以这样来指示可能的 state

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

太多的 `useState`

避免在单组件中使用太多的 useState hooks 。

一个带有多个 useState hooks 的组件很可能在做多个事情，可能更好的做法是拆分成多个组件，但是确实也存在一些复杂的情况，我们需要在单组件中管理各种复杂的状态

这里有个例子，演示了一个 autocomplete 组件中的状态和函数是什么样子的：

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 hook 返回的 setter 来完成相关的任务。现在想象一下，我们还有许多其他的操作需要更新状态，并且很容易看出长期情况下，这种状况很难保证不产生任何 bug 。面对这些场景，通过使用 useReducer hook 来管理状态，能对我们起到很大的帮助。

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 ，我们将状态管理相关的逻辑封装了起来，并将相关的复杂性与组件隔离了出来。我们可以单独的去思考我们的组件和状态，这使得我们理解到底发生了什么很有帮助。

useState 和 useReducer 有各自的利弊和使用场景。我最喜欢的 reducer 模式的是 state reducer pattern by Kent C. Dodds 。

庞大的 `useEffect`

避免会同时做很多事情庞大的 useEffect 。这会使得代码容易出错和难以理解。

hooks 发布时我经常犯的一个错误是在一个 useEffect 里面放了太多东西。为了演示，这是仅含一个 useEffect 的组件：

function Post({ id, unlisted }) {
  ...

  useEffect(() => {
    fetch(`/posts/${id}`).then(/* do something */)

    setVisibility(unlisted)
  }, [id, unlisted])

  ...
}

尽管这个 effect 并不庞大，但依然同时做了多个事情。当 unlisted prop 更新后，我们同样会去拉取数据，尽管 id 并没有发生变化。

为了捕捉住这样的错误，我尝试写或说 ”当 [dependencies] 改变时做这个“ 来描述 effect ，给自己参考。将这种模式应用到上述的 effect 我们可以得到 ”当 id 或 unlisted 改变后，拉取数据和更新状态“。如果这个句子包括字词 ”和“ 或 ”或“ 这通常暗示了有问题存在。

应该将这个 effect 拆分成两个 effect：

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])

  ...
}

这样做，我们减少了组件的复杂度，使其更容易理解并降低了发生 bug 的可能性。

总结

好了，这就是全部了！记住，这些东西并不是意味着规则，更多是一种信号，指示着也许有些事情可能 ”出错“ 了。你肯定会遇到有充分理由要需要用到以上方式的情况。

[译]-你的 React 组件的闻起来怎么样？