编写优雅且有弹性的组件的技巧

2025-05-28

编写优雅且有弹性的组件的技巧

作为前端开发人员,构建有弹性且可重用的组件是我的首要任务,并且有很多论据支持经过深思熟虑的组件。

值得庆幸的是,如今大多数 UI 库和框架都能帮助你为你的项目(更重要的是,为你的团队)构建出尽可能优秀的组件。然而,牢记一些准则可以帮助我们避免陷阱,尤其是在开发大型应用程序时。

在本文中,我们将介绍我每天关注的与库和框架无关的概念,这意味着它们适用于整个 UI 组件。

  1. 采用模块化方法
  2. 正确命名组件
  3. 保持道具简单
  4. 将您的业务逻辑保留在容器组件中

采用模块化方法

理想情况下,您的组件应该遵循FIRST原则:

  • 重点:一个组件,一个职责,如果一个组件做的太多,问问自己是否可以在某处提取该逻辑。
  • 独立:理想情况下,一个组件的功能不应该依赖于另一个组件。传递简单直接的 props 可以帮助你创建独立的元素。如果你曾经使用过Storybook,可以这样想:我可以轻松地将这个组件提取到故事中吗
  • 复用性:UI 组件就像乐高积木,应该很容易适应任何地方。同样,组件的可复用性通常取决于其 props 的简洁性(稍后会详细介绍)。
  • 精简:我目前正在咨询的一个项目中,组件代码竟然达到了 1000 行,这让我感到震惊。保持组件代码👏👏精简。小组件易于阅读和解释,也更易于测试。
  • 可测试性:测试这个组件需要多少模拟?这通常是一个很好的问题,复杂的组件需要事先模拟复杂的上下文。请记住,最容易测试的组件被称为纯组件,这意味着对于给定的输入,组件将始终呈现相同的输出,不会产生副作用,也不依赖任何外部可变状态。

当然,您将处理真正依赖于业务逻辑的元素,这意味着您可能无法完全遵循这些准则,这没关系。有些组件并非可重用,有些组件也不是独立的;但牢记这一原则是一个好的开始。

正确命名组件

我倾向于尝试保持组件名称简短有意义易于发音

以下是一些好的和坏的例子:

<!-- Good -->
<user-button></user-button>
<payment-details></payment-details>
<user-card></user-card>

<!-- Bad -->
<user-btn></user-btn> <!-- hard to pronounce -->
<user-guarantee-payment-tab></user-guarantee-payment-tab> <!-- too long -->
<ui-dropdown></ui-dropdown> <!-- every component is a UI element, no need to mention it -->
Enter fullscreen mode Exit fullscreen mode

保持道具简单

正如第一个技巧中提到的,道具可以成就或毁掉一个组件。

  • 避免传递复杂的对象结构,尽可能将单个属性作为 props
  • 为你的 props 使用简单的名称。我们应该能够在阅读时理解它的用途(哪怕只是部分)。

基本上,尽可能尝试使用 Javascript 原语(字符串、数字、布尔值)和函数作为 props。

将您的业务逻辑保留在容器组件中

容器组件(例如布局)应该整体处理计算和业务逻辑,以便将其结果作为 props 传递给展示组件

这种模式并非总是有效,但它所倡导的理念值得牢记:复杂且有状态的逻辑如果保持分离,更容易维护。例如,在 React 应用程序中,这种业务逻辑可以在自定义钩子中提取出来,因此这种“智能/愚蠢”组件模式实际上就是关注点分离。

很多时候,让每个组件处理自己的逻辑会导致它们难以在整个应用程序中重复使用,因为它们将被绑定到特定的上下文。

不要过度

这些只是构建高效组件的通用技巧。当然,每个项目都有不同的需求,可能不允许您始终遵循这些准则。

正如 Dan Abramov 在他的《编写弹性组件》一文中所说:不要被想象的问题分散注意力。请记住,过度设计所有组件并强制执行可能不会带来有意义差异的规则是不值得的。

希望这份简短的清单能帮助大家在日常工作中构建更好的 UI 组件。一如既往,如有任何疑问,请在推特上@christo_kade ❤️

文章来源:https://dev.to/christopherkade/writing-elegant-and-resilient-components-547i
PREV
你的代码应该讲述一个故事:编写供他人阅读的代码的技巧
NEXT
使用 Vanilla JavaScript 构建一个简单的街机游戏 - DOM 操作🚀 我们将涵盖解决它的过程 1. 布局样式 2. JavaScript 完成的程序