插件窝 干货文章 React 中的 SOLID 原则:编写可维护组件的关键

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

组件 strong gt div 237    来源:    2024-10-20

随着 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) =&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 原则可以带来更干净、更易于维护的代码库。