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 ? ( 

      
{user.name}
      
{user.email}
    
 ) : 
loading...
;
};

这里，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 ? (
    

      
{user.name}
      
{user.email}
    
  ) : (
    
loading...
  );
};

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

开闭原理 (ocp)

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

const alert = ({ type, message }) => {
  if (type === 'success') {
    return 
{message}
;
  }
  if (type === 'error') {
    return 
{message}
;
  }
  return 
{message}
;
};

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

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

const successalert = ({ message }) => (
  
);

const erroralert = ({ message }) => (
  
);

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

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

里氏替换原理 (lsp)

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

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

const iconbutton = ({ onclick, icon }) => (
  
    
  
);

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

const iconbutton = ({ onclick, icon, label }) => (
  
     {label}
  
);

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

const datatable = ({ data, sortable, filterable, exportable }) => (
  

    {/* table rendering */}
    {sortable && sort}
    {filterable && }
    {exportable && export}
  
);

const datatable = ({ data }) => (
  

    {/* table rendering */}
  
);

const sortabletable = ({ data }) => (
  

    
    sort
  
);

const filterabletable = ({ data }) => (
  

    
    
  
);

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

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