在React中應用SOLID原則的方法

更新時間：2022年07月15日 10:19:27 作者：GUOZE

SOLID?是一套原則，它們主要是關心代碼質(zhì)量和可維護性的軟件專業(yè)人員的指導方針，本文給大家分享如何在React中應用SOLID原則，感興趣的朋友一起看看吧

1、單一職責原則（SRP）

單一職責原則的定義是每個類應該只有一個職責，也就是只做一件事。這個原則是最容易解釋的，因為我們可以簡單地將其理解為“每個功能/模塊/組件都應該只做一件事”。

在所有這些原則中，單一職責原則是最容易遵循的，也是最有影響力的一項，因為它極大提高了代碼的質(zhì)量。為了確保組件只做一件事，可以這樣：

將功能較多的大型組件拆分為較小的組件。
將與組件功能無關的代碼提取到單獨的函數(shù)中。
將有聯(lián)系的功能提取到自定義 Hooks 中。

下面來看一個顯示活躍用戶列表的組件：

const ActiveUsersList = () => {
  const [users, setUsers] = useState([]) 
  useEffect(() => {
    const loadUsers = async () => {  
      const response = await fetch('/some-api')
      const data = await response.json()
      setUsers(data)
    }  
    loadUsers()
  }, [])
  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);
  return (
    <ul>
      {users.filter(user => !user.isBanned && user.lastActivityAt >= weekAgo).map(user => 
         <li key={user.id}>
           <img src={user.avatarUrl} />
           <p>{user.fullName}</p>
           <small>{user.role}</small>
         </li>
      )}
    </ul>    
  )
}

這個組件雖然代碼不多，但是做了很多事情：獲取數(shù)據(jù)、過濾數(shù)據(jù)、渲染數(shù)據(jù)。來看看如何分解它。

首先，只要同時使用了 useState? 和 useEffect，就可以將它們提取到自定義 Hook 中：

const useUsers = () => {
  const [users, setUsers] = useState([])
  useEffect(() => {
    const loadUsers = async () => {  
      const response = await fetch('/some-api')
      const data = await response.json()
      setUsers(data)
    }
    loadUsers()
  }, []) 
  return { users }
}
const ActiveUsersList = () => {
  const { users } = useUsers()  
  const weekAgo = new Date()
  weekAgo.setDate(weekAgo.getDate() - 7)
  return (
    <ul>
      {users.filter(user => !user.isBanned && user.lastActivityAt >= weekAgo).map(user => 
        <li key={user.id}>
          <img src={user.avatarUrl} />
          <p>{user.fullName}</p>
          <small>{user.role}</small>
        </li>
      )}
    </ul>    
  )
}

現(xiàn)在，useUsers Hook只關心一件事——從API獲取用戶。它使我們的組件代碼更具可讀性。

接下來看一下組件渲染的 JSX。每當我們對對象數(shù)組進行遍歷時，都應該注意它為每個數(shù)組項生成的 JSX 的復雜性。如果它是一個沒有附加任何事件處理函數(shù)的單行代碼，將其保持內(nèi)聯(lián)是完全沒有問題的。但對于更復雜的JSX，將其提取到單獨的組件中可能是一個更好的主意：

const UserItem = ({ user }) => {
  return (
    <li>
      <img src={user.avatarUrl} />
      <p>{user.fullName}</p>
      <small>{user.role}</small>
    </li>
  )
}
const ActiveUsersList = () => {
  const { users } = useUsers() 
  const weekAgo = new Date()
  weekAgo.setDate(weekAgo.getDate() - 7)
  return (
    <ul>
      {users.filter(user => !user.isBanned && user.lastActivityAt >= weekAgo).map(user => 
        <UserItem key={user.id} user={user} />
      )}
    </ul>    
  )
}

這里將用于呈現(xiàn)用戶信息的邏輯提取到了一個單獨的組件中，從而使我們的組件更小、更可讀。

最后，從 API 獲取到的用戶列表中過濾出所有非活躍用戶的邏輯是相對獨立的，可以在其他部分重用，所以可以將其提取到一個公共函數(shù)中：

const getOnlyActive = (users) => {
  const weekAgo = new Date()
  weekAgo.setDate(weekAgo.getDate() - 7)
  return users.filter(user => !user.isBanned && user.lastActivityAt >= weekAgo)
}
const ActiveUsersList = () => {
  const { users } = useUsers()
  return (
    <ul>
      {getOnlyActive(users).map(user => 
        <UserItem key={user.id} user={user} />
      )}
    </ul>    
  )
}

到現(xiàn)在為止，通過上面三步拆解，組件已經(jīng)變得比較簡單。但是，仔細觀察會發(fā)現(xiàn)，這個組件還有優(yōu)化的空間。目前，組件首先獲取數(shù)據(jù)，然后需要對數(shù)據(jù)進行過濾。理想情況下，我們只想獲取數(shù)據(jù)并渲染它，而不需要任何額外的操作。所以，可以將這個邏輯封裝到一個新的自定義 Hook 中，最終的代碼如下：

// 獲取數(shù)據(jù)
const useUsers = () => {
  const [users, setUsers] = useState([])
  
  useEffect(() => {
    const loadUsers = async () => {  
      const response = await fetch('/some-api')
      const data = await response.json()
      setUsers(data)
    }
    loadUsers()
  }, [])
  
  return { users }
}
// 列表渲染
const UserItem = ({ user }) => {
  return (
    <li>
      <img src={user.avatarUrl} />
      <p>{user.fullName}</p>
      <small>{user.role}</small>
    </li>
  )
}
// 列表過濾
const getOnlyActive = (users) => {
  const weekAgo = new Date()
  weekAgo.setDate(weekAgo.getDate() - 7) 
  return users.filter(user => !user.isBanned && user.lastActivityAt >= weekAgo)
}
const useActiveUsers = () => {
  const { users } = useUsers()
  const activeUsers = useMemo(() => {
    return getOnlyActive(users)
  }, [users])
  return { activeUsers }
}
const ActiveUsersList = () => {
  const { activeUsers } = useActiveUsers()
  return (
    <ul>
      {activeUsers.map(user => 
        <UserItem key={user.id} user={user} />
      )}
    </ul>    
  )
}

在這里，我們創(chuàng)建了useActiveUsers Hook 來處理獲取和過濾數(shù)據(jù)的邏輯，而組件只做了最少的事情——渲染它從 Hook 中獲取的數(shù)據(jù)。

現(xiàn)在，這個組件只剩下兩個職責：獲取數(shù)據(jù)和渲染數(shù)據(jù)，當然我們也可以在組件的父級獲取數(shù)據(jù)，并通過 props 傳入該組件，這樣只需要渲染組件就可以了。當然，還是要視情況而定。我們可以簡單地將獲取并渲染數(shù)據(jù)看作是“一件事”。

總而言之，遵循單一職責原則，我們有效地采用了大量獨立的代碼并使其更加模塊化，模塊化的代碼更容易測試和維護。

2、開放封閉原則（OCP）

開放封閉原則指出“ 一個軟件實體（類、模塊、函數(shù)）應該對擴展開放，對修改關閉 ”。開放封閉原則主張以一種允許在不更改源代碼的情況下擴展組件的方式來構造組件。

下面來看一個場景，有一個可以在不同頁面上使用的 Header? 組件，根據(jù)所在頁面的不同，Header 組件的 UI 應該有略微的不同：

const Header = () => {
  const { pathname } = useRouter()
  return (
    <header>
      <Logo />
      <Actions>
        {pathname === '/dashboard' && <Link to="/events/new">Create event</Link>}
        {pathname === '/' && <Link to="/dashboard">Go to dashboard</Link>}
      </Actions>
    </header>
  )
}
const HomePage = () => (
  <>
    <Header />
    <OtherHomeStuff />
  </>
)
const DashboardPage = () => (
  <>
    <Header />
    <OtherDashboardStuff />
  </>
)

這里，根據(jù)所在頁面的不同，呈現(xiàn)指向不同頁面組件的鏈接。那現(xiàn)在考慮一下，如果需要將這個Header?組件添加到更多的頁面中會發(fā)生什么呢？每次創(chuàng)建新頁面時，都需要引用 Header? 組件，并修改其內(nèi)部實現(xiàn)。這種方式使得 Header 組件與使用它的上下文緊密耦合，并且違背了開放封閉原則。

為了解決這個問題，我們可以使用組件組合。Header? 組件不需要關心它將在內(nèi)部渲染什么，相反，它可以將此責任委托給將使用 children 屬性的組件：

const Header = ({ children }) => (
  <header>
    <Logo />
    <Actions>
      {children}
    </Actions>
  </header>
)
const HomePage = () => (
  <>
    <Header>
      <Link to="/dashboard">Go to dashboard</Link>
    </Header>
    <OtherHomeStuff />
  </>
)
const DashboardPage = () => (
  <>
    <Header>
      <Link to="/events/new">Create event</Link>
    </Header>
    <OtherDashboardStuff />
  </>
)

使用這種方法，我們完全刪除了 Header? 組件內(nèi)部的變量邏輯。現(xiàn)在可以使用組合將想要的任何內(nèi)容放在Header中，而無需修改組件本身。

遵循開放封閉原則，可以減少組件之間的耦合，使它們更具可擴展性和可重用性。

3、里氏替換原則（LSP）

里氏替換原則可以理解為對象之間的一種關系，子類型對象應該可以替換為超類型對象。這個原則嚴重依賴類繼承來定義超類型和子類型關系，但它在 React 中可能不太適用，因為我們幾乎不會處理類，更不用說類繼承了。雖然遠離類繼承會不可避免地將這一原則轉(zhuǎn)變?yōu)橥耆煌臇|西，但使用繼承編寫 React 代碼會使代碼變得糟糕（React 團隊不推薦使用繼承）。因此，對于這一原則不再過多解釋。

4、接口隔離原則（ISP）

根據(jù)接口隔離原則的說法，客戶端不應該依賴它不需要的接口。為了更好的說明 ISP 所針對的問題，來看一個呈現(xiàn)視頻列表的組件：

type Video = {
  title: string
  duration: number
  coverUrl: string
}
type Props = {
  items: Array<Video>
}
const VideoList = ({ items }) => {
  return (
    <ul>
      {items.map(item => 
        <Thumbnail 
          key={item.title} 
          video={item} 
        />
      )}
    </ul>
  )
}

Thumbnail 組件的實現(xiàn)如下：

type Props = {
  video: Video
}
const Thumbnail = ({ video }: Props) => {
  return <img src={video.coverUrl} />
}

Thumbnail? 組件非常小并且很簡單，但它有一個問題：它希望將完整的視頻對象作為 props? 傳入，但是僅有效地使用其屬性之一（coverUrl）。

除了視頻，我們還需要渲染直播的縮略圖，這兩種媒體資源會混合在同一個列表中。

下面來定義直播的類型 LiveStream ：

type LiveStream = {
  name: string
  previewUrl: string
}

這是更新后的 VideoList 組件：

type Props = {
  items: Array<Video | LiveStream>
}
const VideoList = ({ items }) => {
  return (
    <ul>
      {items.map(item => {
        if ('coverUrl' in item) {
          return <Thumbnail video={item} />
        } else {
          // 直播組件，該怎么寫？
        }
      })}
    </ul>
  )
}

這時就發(fā)現(xiàn)一個問題，我們可以輕松的區(qū)分視頻和直播對象，但是不能將后者傳遞給Thumbnail?組件，因為Video和LiveStream?類型不兼容。它們包含了不同的屬性來保存縮略圖：視頻對象調(diào)用coverUrl?，直播對象調(diào)用previewUrl?。這就是使組件依賴了比實際更多的props的原因所在。

下面來重構 Thumbnail? 組件以確保它僅依賴于它需要的props：

type Props = {
  coverUrl: string
}
const Thumbnail = ({ coverUrl }: Props) => {
  return <img src={coverUrl} />
}

通過這樣修改，現(xiàn)在我們可以使用它來渲染視頻和直播的對略圖：

type Props = {
  items: Array<Video | LiveStream>
}
const VideoList = ({ items }) => {
  return (
    <ul>
      {items.map(item => {
        if ('coverUrl' in item) {
          return <Thumbnail coverUrl={item.coverUrl} />
        } else {
          return <Thumbnail coverUrl={item.previewUrl} />
        }
      })}
    </ul>
  )
}

當然，這段代碼還可以簡化一下：

type Props = {
  items: Array<Video | LiveStream>
}
const VideoList = ({ items }) => {
  return (
    <ul>
      {items.map(item => (
         <Thumbnail coverUrl={'coverUrl' in item ? item.coverUrl : item.previewUrl} />
      ))}
    </ul>
  )
}

接口隔離原則主張最小化系統(tǒng)組件之間的依賴關系，使它們的耦合度降低，從而提高可重用性。

5、依賴倒置原則（DIP）

依賴倒置原則指出“要依賴于抽象，不要依賴于具體”。換句話說，一個組件不應該直接依賴于另一個組件，而是它們都應該依賴于一些共同的抽象。這里，“組件”是指應用程序的任何部分，可以是 React 組件、函數(shù)、模塊或第三方庫。這個原則可能很難理解，下面來看一個具體的例子。

有一個 LoginForm 組件，它在提交表單時將用戶憑據(jù)發(fā)送到某些 API：

import api from '~/common/api'
const LoginForm = () => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')

  const handleSubmit = async (evt) => {
    evt.preventDefault()
    await api.login(email, password)
  }
  return (
    <form onSubmit={handleSubmit}>
      <input type="email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" value={password} onChange={e => setPassword(e.target.value)} />
      <button type="submit">Log in</button>
    </form>
  )
}

在這段代碼中，LoginForm? 組件直接引用了 api 模塊，因此它們之間存在緊密耦合。這種依賴關系就會導致一個組件的更改會影響其他組件。依賴倒置原則就提倡打破這種耦合，下面來看看如何實現(xiàn)這一點。

首先，從 LoginForm? 組件中刪除對 api? 模塊的直接引用，而是允許通過 props 傳入所需的回調(diào)函數(shù)：

type Props = {
  onSubmit: (email: string, password: string) => Promise<void>
}
const LoginForm = ({ onSubmit }: Props) => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const handleSubmit = async (evt) => {
    evt.preventDefault()
    await onSubmit(email, password)
  }
  return (
    <form onSubmit={handleSubmit}>
      <input type="email" value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" value={password} onChange={e => setPassword(e.target.value)} />
      <button type="submit">Log in</button>
    </form>
  )
}

通過這樣修改，LoginForm? 組件不再依賴于 api? 模塊。向 API 提交憑證的邏輯是通過 onSubmit 回調(diào)函數(shù)抽象出來的，現(xiàn)在由父組件負責提供該邏輯的具體實現(xiàn)。

為此，創(chuàng)建了一個 ConnectedLoginForm? 組件來將表單提交邏輯委托給 api 模塊：

import api from '~/common/api'
const ConnectedLoginForm = () => {
  const handleSubmit = async (email, password) => {
    await api.login(email, password)
  }
  return (
    <LoginForm onSubmit={handleSubmit} />
  )
}

ConnectedLoginForm? 組件充當 api? 和 LoginForm 之間的粘合劑，而它們本身保持完全獨立。這樣就可以對這兩個組件進行單獨的修改和維護，而不必擔心修改會影響其他組件。

依賴倒置原則旨在最小化應用程序不同組件之間的耦合。你可能已經(jīng)注意到，最小化是所有 SOLID 原則中反復出現(xiàn)的關鍵詞——從最小化單個組件的職責范圍到最小化它們之間的依賴關系等等。

6、小結

通過上面的示例，相信你已經(jīng)對如何在 React 中使用 SOLID 原則有了一定的了解。應用SOLID 原則使我們的 React 代碼更易于維護和健壯。

但是需要注意，虔誠地遵循這些原則可能會造成破壞并導致代碼過度設計，因此我們應該學會識別對組件的進一步分解或解耦何時會導致其復雜度增加而幾乎沒有任何好處。

到此這篇關于如何在React中應用SOLID原則？的文章就介紹到這了,更多相關React SOLID原則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章:

淺談React + Webpack 構建打包優(yōu)化
本篇文章主要介紹了淺談React + Webpack 構建打包優(yōu)化，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
2018-01-01
React中FormData的使用實例詳解
FormData 是一個非常靈活的工具,適用于處理表單數(shù)據(jù),特別是在需要發(fā)送文件或復雜表單數(shù)據(jù)時,本文給大家介紹React中FormData的使用示例詳解,感興趣的朋友一起看看吧
2025-04-04
react 組件表格固定底部的實現(xiàn)代碼
在React中,要實現(xiàn)一個組件表格并且固定底部,可以使用CSS的固定定位或絕對定位來實現(xiàn),下面通過示例代碼給大家分享react 組件表格固定底部的實現(xiàn)代碼,感興趣的朋友跟隨小編一起看看吧
2024-05-05
深入理解React Native原生模塊與JS模塊通信的幾種方式
本篇文章主要介紹了深入理解React Native原生模塊與JS模塊通信的幾種方式，具有一定的參考價值，有興趣的可以了解一下
2017-07-07
React中useEffect原理的代碼簡單實現(xiàn)詳解
React的useEffect鉤子是React函數(shù)組件中處理副作用,本文將通過一個簡單的例子解釋如何用代碼實現(xiàn)useEffect的基本原理,感興趣的小伙伴可以了解下
2023-12-12
ReactJS中的自定義組件實例代碼
React 是一個用于構建用戶界面的 JAVASCRIPT 庫。這篇文章主要介紹了ReactJS中的自定義組件的代碼講解,需要的朋友可以參考下
2019-11-11
react-native動態(tài)切換tab組件的方法
在APP中免不了要使用tab組件,有的是tab切換,也有的是tab分類切換.這篇文章主要介紹了react-native動態(tài)切換tab組件的方法，非常具有實用價值，需要的朋友可以參考下
2018-07-07
React配置多個代理實現(xiàn)數(shù)據(jù)請求返回問題
這篇文章主要介紹了React之配置多個代理實現(xiàn)數(shù)據(jù)請求返回問題，本文通過示例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
2022-08-08
關于getDerivedStateFromProps填坑記錄
這篇文章主要介紹了關于getDerivedStateFromProps填坑記錄，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教
2023-06-06
React封裝自定義Hook捕獲所有錯誤的實現(xiàn)方法
在 React 開發(fā)中,錯誤處理是確保應用穩(wěn)定性和用戶體驗的重要部分,React 提供了多種錯誤捕獲方式,包括錯誤邊界**等,本文將詳細介紹這些方法,并展示如何封裝一個能夠捕獲所有同步和異步錯誤的自定義 Hook,需要的朋友可以參考下
2024-12-12