React 中的 SOLID 原则：编写可维护组件的关键

大家好，我们又见面了啊~本文《React 中的 SOLID 原则：编写可维护组件的关键》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

随着 react 应用程序的增长，事情可能会很快变得混乱——臃肿的组件、难以维护的代码和意外的错误。这就是 solid 原则派上用场的地方。这些原则最初是为面向对象编程而开发的，可帮助您编写干净、灵活且可扩展的代码。在本文中，我将分解每个 solid 原则，并展示如何在 react 中使用它们来保持组件井井有条，使代码更易于维护，并使应用程序做好成长的准备。

solid 是一个缩写词，代表五项设计原则，旨在编写干净、可维护和可扩展的代码，最初用于面向对象编程，但也适用于 react：

s：单一职责原则：组件应该有一项工作或职责。

o：开放/封闭原则：组件应该开放扩展**（容易增强或定制）但**封闭修改（它们的核心代码不需要变化）。

l：里氏替换原则：组件应该可以被它们的子组件替换而不破坏应用程序的行为。

i：接口隔离原则：组件不应该被迫依赖未使用的功能。

d：依赖倒置原则：组件应该依赖于抽象，而不是具体的实现。

单一职责原则（srp）

这样想：想象一下你有一个玩具机器人，它只能做一项工作，比如走路。如果你要求它做第二件事，比如说话，它会感到困惑，因为它应该专注于行走！如果你想要另一份工作，那就买第二个机器人。

在 react 中，一个组件应该只做一件事。如果它做的事情太多，比如同时获取数据、处理表单输入和显示 ui，它就会变得混乱且难以管理。

const usercard = () => {
  const [user, setuser] = usestate(null);

  useeffect(() => {
    fetch('/api/user')
      .then(response => response.json())
      .then(data => setuser(data));
  }, []);

  return user ? ( <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div> ) : <p>loading...</p>;
};

这里，usercard 负责获取数据和渲染 ui，这打破了单一职责原则。

const usefetchuser = (fetchuser) => {
  const [user, setuser] = usestate(null);

  useeffect(() => {
    fetchuser().then(setuser);
  }, [fetchuser]);

  return user;
};

const usercard = ({ fetchuser }) => {
  const user = usefetchuser(fetchuser);

  return user ? (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  ) : (
    <p>loading...</p>
  );
};

这里，数据获取逻辑被移动到自定义钩子（usefetchuser），而usercard仅专注于渲染ui，以及维护srp。

开闭原理 (ocp)

想象一个视频游戏角色。您可以向角色添加新技能（扩展），而不改变其核心能力（修改）。这就是 ocp 的意义所在——允许您的代码增长和适应，而不改变已有的内容。

const alert = ({ type, message }) => {
  if (type === 'success') {
    return <div classname="alert-success">{message}</div>;
  }
  if (type === 'error') {
    return <div classname="alert-error">{message}</div>;
  }
  return <div>{message}</div>;
};

这里，每次需要新的警报类型时，都必须修改警报组件，这会破坏 ocp。每当您在组件中添加条件渲染或切换案例渲染时，都会使该组件的维护性降低，因为您必须在功能中添加更多条件并修改破坏 ocp 的组件核心代码。

const alert = ({ classname, message }) => (
  <div classname={classname}>{message}</div>
);

const successalert = ({ message }) => (
  <alert classname="alert-success" message={message} />
);

const erroralert = ({ message }) => (
  <alert classname="alert-error" message={message} />
);

现在，alert 组件开放用于扩展（通过添加 successalert、erroralert 等），但关闭用于修改，因为我们不需要触及核心 alert 组件添加新的警报类型。

想要 ocp 吗？更喜欢组合而不是继承

里氏替换原理 (lsp)

想象一下你有一部手机，然后你得到了一部新的智能手机。您希望像使用普通电话一样在智能手机上拨打电话。如果智能手机不能打电话，那它就不是一个好的替代品，对吗？这就是 lsp 的意义所在——新组件或子组件应该像原始组件一样工作，而不会破坏任何东西。

const button = ({ onclick, children }) => (
  <button onclick={onclick}>{children}</button>
);

const iconbutton = ({ onclick, icon }) => (
  <button onclick={onclick}>
    <i classname={icon} />
  </button>
);

在这里，如果将 button 与 iconbutton 交换，则会丢失标签，从而破坏行为和期望。

const button = ({ onclick, children }) => (
  <button onclick={onclick}>{children}</button>
);

const iconbutton = ({ onclick, icon, label }) => (
  <button onclick={onclick}>
    <i classname={icon} /> {label}
  </button>
);

// iconbutton now behaves like button, supporting both icon and label

现在，iconbutton 正确扩展了 button 的行为，支持图标和标签，因此您可以在不破坏功能的情况下交换它们。这遵循里氏替换原则，因为子级 (iconbutton) 可以毫无意外地替换父级 (button)！

如果 b 组件扩展了 a 组件，那么在任何使用 a 组件的地方，都应该能够使用 b 组件。

接口隔离原则（isp）

想象一下您正在使用遥控器看电视。您只需要几个按钮，例如电源、音量和频道。如果遥控器上有大量不必要的 dvd 播放器、收音机和灯光按钮，使用起来会很烦人。

假设你有一个数据表组件需要很多 props，即使使用它的组件并不需要所有这些。

const datatable = ({ data, sortable, filterable, exportable }) => (
  <div>
    {/* table rendering */}
    {sortable && <button>sort</button>}
    {filterable && &lt;input placeholder=&quot;filter&quot; /&gt;}
    {exportable && <button>export</button>}
  </div>
);

这个组件迫使所有消费者考虑排序、过滤和导出——即使他们只想要一个简单的表格。

您可以根据需要将功能拆分为更小的组件。

const datatable = ({ data }) => (
  <div>
    {/* table rendering */}
  </div>
);

const sortabletable = ({ data }) => (
  <div>
    <datatable data={data} />
    <button>sort</button>
  </div>
);

const filterabletable = ({ data }) => (
  <div>
    <datatable data={data} />
    &lt;input placeholder=&quot;filter&quot; /&gt;
  </div>
);

现在，每个表仅包含所需的功能，并且您不会在各处强制使用不必要的道具。这遵循 isp，其中组件仅依赖于它们需要的部分。

依赖倒置原则（dip）

想象一下您正在使用乐高积木进行建造。您有一个由特定部件制成的机器人。但是如果你想换掉它的手臂或腿怎么办？您不必重建整个东西——只需更换零件即可。依赖倒置原则（dip）是这样的：你的机器人（高级）不依赖于特定的部分（低级）；这取决于您可以轻松更改的部分。

const usercomponent = () => {
  useeffect(() => {
    fetch('/api/user').then(...);
  }, []);
  return <div>...</div>;
};

这直接取决于 fetch — 你不能轻易地交换它。

const UserComponent = ({ fetchUser }) => {
  useEffect(() => {
    fetchUser().then(...);
  }, [fetchUser]);
  return <div>...</div>;
};

现在，fetchuser 函数已传入，您可以轻松地将其与其他实现（例如模拟 api 或其他数据源）交换，从而保持一切灵活且可测试。

最后的想法

在 react 中理解和应用 solid 原则可以极大地提高代码质量。这些原则（单一职责、开放/封闭、里氏替换、接口隔离和依赖倒置）可帮助您编写更加模块化、灵活且易于维护的组件。通过分解职责、保持代码可扩展性并确保应用程序的每个部分以可预测的方式交互，您可以创建更容易扩展且更易于调试的 react 应用程序。简而言之，solid 原则可以带来更干净、更易于维护的代码库。

终于介绍完啦！小伙伴们，这篇关于《React 中的 SOLID 原则：编写可维护组件的关键》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！