随着 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 && <input placeholder="filter" />}
{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} />
<input placeholder="filter" />
</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 原则可以带来更干净、更易于维护的代码库。
