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

百变鹏仔 3天前 #JavaScript

文章标签组件

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

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

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

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

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

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

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

单一职责原则（srp）

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

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

const usercard = () =&gt; {  const [user, setuser] = usestate(null);  useeffect(() =&gt; {    fetch('/api/user')      .then(response =&gt; response.json())      .then(data =&gt; setuser(data));  }, []);  return user ? ( <div>      <h2>{user.name}</h2>      <p>{user.email}</p>    </div> ) : <p>loading...</p>;};

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

const usefetchuser = (fetchuser) =&gt; {  const [user, setuser] = usestate(null);  useeffect(() =&gt; {    fetchuser().then(setuser);  }, [fetchuser]);  return user;};const usercard = ({ fetchuser }) =&gt; {  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 }) =&gt; {  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 }) =&gt; (  <div classname="{classname}">{message}</div>);const successalert = ({ message }) =&gt; (  <alert classname="alert-success" message="{message}"></alert>);const erroralert = ({ message }) =&gt; (  <alert classname="alert-error" message="{message}"></alert>);

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

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

里氏替换原理 (lsp)

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

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

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

const button = ({ onclick, children }) =&gt; (  <button onclick="{onclick}">{children}</button>);const iconbutton = ({ onclick, icon, label }) =&gt; (  <button onclick="{onclick}">    <i classname="{icon}"></i> {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 }) =&gt; (  <div>    {/* table rendering */}    {sortable &amp;&amp; <button>sort</button>}    {filterable &amp;&amp; <input placeholder="filter">}    {exportable &amp;&amp; <button>export</button>}  </div>);

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

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

const datatable = ({ data }) =&gt; (  <div>    {/* table rendering */}  </div>);const sortabletable = ({ data }) =&gt; (  <div>    <datatable data="{data}"></datatable><button>sort</button>  </div>);const filterabletable = ({ data }) =&gt; (  <div>    <datatable data="{data}"></datatable><input placeholder="filter"></div>);

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

依赖倒置原则（dip）

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

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

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

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

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

最后的想法

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

文章推荐

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

单一职责原则（srp）

开闭原理 (ocp)

里氏替换原理 (lsp)

接口隔离原则（isp）

依赖倒置原则（dip）

最后的想法

JavaScript如何获取宏控件数据？

JavaScript怎样读取宏控件数据？

JavaScript获取宏控件数据的技巧

探究JavaScript与Java的联系和区别

javascript:void(o)如何解决？