在React中應用SOLID原則的方法
在面向?qū)ο缶幊蹋∣OP）中，SOLID 原則是設計模式的基礎，它的每個字母代表一種設計原則：
- 單一職責原則（SRP）
- 開放封閉原則（OCP）
- 里氏替換原則（LSP）
- 接口隔離原則（ISP）
- 依賴倒置原則（DIP）
下面就來看看每個原則的含義以及如何在 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ù)）應該對擴展開放，對修改關閉 ”。開放封閉原則主張以一種允許在不更改源代碼的情況下擴展組件的方式來構(gòu)造組件。
下面來看一個場景，有一個可以在不同頁面上使用的 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)部的變量邏輯?，F(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的原因所在。
下面來重構(gòu) 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、小結(jié)
通過上面的示例，相信你已經(jīng)對如何在 React 中使用 SOLID 原則有了一定的了解。應用SOLID 原則使我們的 React 代碼更易于維護和健壯。
但是需要注意，虔誠地遵循這些原則可能會造成破壞并導致代碼過度設計，因此我們應該學會識別對組件的進一步分解或解耦何時會導致其復雜度增加而幾乎沒有任何好處。
到此這篇關于如何在React中應用SOLID原則？的文章就介紹到這了,更多相關React SOLID原則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
這篇文章主要介紹了react中定義變量并使用方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-02-02
react中的ref類似于vue中的ref,都是可以操作dom的,這篇文章我們通過一個demo來學習這個屬性,文中有詳細的代碼示例供大家參考,具有一定的參考價值,需要的朋友可以參考下2023-08-08
這篇文章主要給大家介紹了關于React如何使用相對于根目錄進行引用組件的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧。2017-10-10
詳解在React項目中安裝并使用Less（用法總結(jié)）
這篇文章主要介紹了詳解在React項目中安裝并使用Less（用法總結(jié)），文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-03-03
React中hook函數(shù)與useState及useEffect的使用
這篇文章主要介紹了React中hook函數(shù)與useState及useEffect的使用，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習吧2022-10-10
React路由的history對象的插件history的使用解讀
這篇文章主要介紹了React路由的history對象的插件history的使用,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-10-10
這篇文章主要介紹了使用React-Router時出現(xiàn)的錯誤及解決方案,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-03-03
React?Hooks使用startTransition與useTransition教程示例
這篇文章主要為大家介紹了React?Hooks使用startTransition與useTransition教程示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-01-01
寫react的時候，踩了幾次坑發(fā)現(xiàn)setstate之后state不會立刻更新，于是判定setstate就是異步的方法，但是直到有一天，我想立刻拿到更新的state去傳參另一個方法的時候，才問自己，為什么setstate是異步的？準確地說，在React內(nèi)部機制能檢測到的地方，setState就是異步的2022-10-10
這篇文章主要介紹了如何在React中直接使用Redux,目前redux在react中使用是最多的，所以我們需要將之前編寫的redux代碼，融入到react當中去，本文給大家詳細講解，需要的朋友可以參考下2022-12-12