摘要:編寫組件時要考慮的基本準則是單一職責原則。這些更改通常要求組件在隔離狀態下易于修改這也是的目標。解決多重責任問題需要將分割為兩個組件和。組件之間的通信是通過實現。更改的唯一原因是修改表單字段。
翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-...
原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的React組件非常有幫助。但因為篇幅實在太長,我不得不進行了分割,本篇文章重點闡述 SRP,即單一職責原則。
————————————我是一條分割線————————————
更多文章可戳: https://github.com/YvetteLau/...
我喜歡React組件式開發方式。你可以將復雜的用戶界面分割為一個個組件,利用組件的可重用性和抽象的DOM操作。
基于組件的開發是高效的:一個復雜的系統是由專門的、易于管理的組件構建的。然而,只有設計良好的組件才能確保組合和復用的好處。
盡管應用程序很復雜,但為了滿足最后期限和意外變化的需求,你必須不斷地走在架構正確性的細線上。你必須將組件分離為專注于單個任務,并經過良好測試。
不幸的是,遵循錯誤的路徑總是更加容易:編寫具有許多職責的大型組件、緊密耦合組件、忘記單元測試。這些增加了技術債務,使得修改現有功能或創建新功能變得越來越困難。
編寫React應用程序時,我經常問自己:
如何正確構造組件?
在什么時候,一個大的組件應該拆分成更小的組件?
如何設計防止緊密耦合的組件之間的通信?
幸運的是,可靠的組件具有共同的特性。讓我們來研究這7個有用的標準(本文只闡述 SRP,剩余準則正在途中),并將其詳細到案例研究中。
單一職責當一個組件只有一個改變的原因時,它有一個單一的職責。
編寫React組件時要考慮的基本準則是單一職責原則。單一職責原則(縮寫:SRP)要求組件有一個且只有一個變更的原因。
組件的職責可以是呈現列表,或者顯示日期選擇器,或者發出 HTTP 請求,或者繪制圖表,或者延遲加載圖像等。你的組件應該只選擇一個職責并實現它。當你修改組件實現其職責的方式(例如,更改渲染的列表的數量限制),它有一個更改的原因。
為什么只有一個理由可以改變很重要?因為這樣組件的修改隔離并且受控。單一職責原則制了組件的大小,使其集中在一件事情上。集中在一件事情上的組件便于編碼、修改、重用和測試。
下面我們來舉幾個例子
實例1:一個組件獲取遠程數據,相應地,當獲取邏輯更改時,它有一個更改的原因。
發生變化的原因是:
修改服務器URL
修改響應格式
要使用其他HTTP請求庫
或僅與獲取邏輯相關的任何修改。
示例2:表組件將數據數組映射到行組件列表,因此在映射邏輯更改時有一個原因需要更改。
發生變化的原因是:
你需要限制渲染行組件的數量(例如,最多顯示25行)
當沒有要顯示的項目時,要求顯示提示信息“列表為空”
或僅與數組到行組件的映射相關的任何修改。
你的組件有很多職責嗎?如果答案是“是”,則按每個多帶帶的職責將組件分成若干塊。
如果您發現SRP有點模糊,請閱讀本文。
在項目早期階段編寫的單元將經常更改,直到達到發布階段。這些更改通常要求組件在隔離狀態下易于修改:這也是 SRP 的目標。
當一個組件有多個職責時,就會發生一個常見的問題。乍一看,這種做法似乎是無害的,并且工作量較少:
你立即開始編碼:無需識別職責并相應地規劃結構
一個大的組件可以做到這一切:不需要為每個職責創建組成部分
無拆分-無開銷:無需為拆分組件之間的通信創建 props 和 callbacks
這種幼稚的結構在開始時很容易編碼。但是隨著應用程序的增加和變得復雜,在以后的修改中會出現困難。同時實現多個職責的組件有許多更改的原因。現在出現的主要問題是:出于某種原因更改組件會無意中影響同一組件實現的其它職責。
不要關閉電燈開關,因為它同樣作用于電梯。
這種設計很脆弱。意外的副作用是很難預測和控制的。
例如,
當你更改表單字段(例如,將 修改為 時,你無意中中斷圖表的渲染。此外,圖表實現是不可重用的,因為它與表單細節耦合在一起。
解決多重責任問題需要將
多重責任問題的最壞情況是所謂的上帝組件(上帝對象的類比)。上帝組件傾向于了解并做所有事情。你可能會看到它名為
在組合的幫助下使其符合SRP,從而分解上帝組件。(組合(composition)是一種通過將各組件聯合在一起以創建更大組件的方式。組合是 React 的核心。)
1.2 案例研究:使組件只有一個職責設想一個組件向一個專門的服務器發出 HTTP 請求,以獲取當前天氣。成功獲取數據時,該組件使用響應來展示天氣信息:
import axios from "axios"; // 問題: 一個組件有多個職責 class Weather extends Component { constructor(props) { super(props); this.state = { temperature: "N/A", windSpeed: "N/A" }; } render() { const { temperature, windSpeed } = this.state; return (); } componentDidMount() { axios.get("http://weather.com/api").then(function (response) { const { current } = response.data; this.setState({ temperature: current.temperature, windSpeed: current.windSpeed }) }); } }Temperature: {temperature}°CWind: {windSpeed}km/h
在處理類似的情況時,問問自己:是否必須將組件拆分為更小的組件?通過確定組件可能會如何根據其職責進行更改,可以最好地回答這個問題。
這個天氣組件有兩個改變原因:
componentDidMount() 中的 fetch 邏輯:服務器URL或響應格式可能會改變。
render() 中的天氣展示:組件顯示天氣的方式可以多次更改。
解決方案是將
import axios from "axios"; // 解決措施: 組件只有一個職責就是請求數據 class WeatherFetch extends Component { constructor(props) { super(props); this.state = { temperature: "N/A", windSpeed: "N/A" }; } render() { const { temperature, windSpeed } = this.state; return (); } componentDidMount() { axios.get("http://weather.com/api").then(function (response) { const { current } = response.data; this.setState({ temperature: current.temperature, windSpeed: current.windSpeed }); }); } }
這種結構有什么好處?
例如,你想要使用 async/await 語法來替代 promise 去服務器獲取響應。更改原因:修改獲取邏輯
// 改變原因: 使用 async/await 語法 class WeatherFetch extends Component { // ..... // async componentDidMount() { const response = await axios.get("http://weather.com/api"); const { current } = response.data; this.setState({ temperature: current.temperature, windSpeed: current.windSpeed }); } }
因為
// 解決方案: 組件只有一個職責,就是顯示天氣 function WeatherInfo({ temperature, windSpeed }) { return (); }Temperature: {temperature}°CWind: {windSpeed} km/h
讓我們更改
// 改變原因: 無風時的顯示 function WeatherInfo({ temperature, windSpeed }) { const windInfo = windSpeed === 0 ? "calm" : `${windSpeed} km/h`; return (); }Temperature: {temperature}°CWind: {windInfo}
同樣,對
按職責使用分塊組件的組合并不總是有助于遵循單一責任原則。另外一種有效實踐是高效組件(縮寫為 HOC)
高階組件是一個接受一個組件并返回一個新組件的函數。
HOC 的一個常見用法是為封裝的組件增加新屬性或修改現有的屬性值。這種技術稱為屬性代理:
function withNewFunctionality(WrappedComponent) { return class NewFunctionality extends Component { render() { const newProp = "Value"; const propsProxy = { ...this.props, // 修改現有屬性: ownProp: this.props.ownProp + " was modified", // 增加新屬性: newProp }; return; } } } const MyNewComponent = withNewFunctionality(MyComponent);
你還可以通過控制輸入組件的渲染過程從而控制渲染結果。這種 HOC 技術被稱為渲染劫持:
function withModifiedChildren(WrappedComponent) { return class ModifiedChildren extends WrappedComponent { render() { const rootElement = super.render(); const newChildren = [ ...rootElement.props.children, // 插入一個元素New child]; return cloneElement( rootElement, rootElement.props, newChildren ); } } } const MyNewComponent = withModifiedChildren(MyComponent);
如果您想深入了解HOCS實踐,我建議您閱讀“深入響應高階組件”。
讓我們通過一個例子來看看HOC的屬性代理技術如何幫助分離職責。
組件
input 的狀態在 handlechange(event) 方法中更新。點擊按鈕,值將保存到本地存儲,在 handleclick() 中處理:
class PersistentForm extends Component { constructor(props) { super(props); this.state = { inputValue: localStorage.getItem("inputValue") }; this.handleChange = this.handleChange.bind(this); this.handleClick = this.handleClick.bind(this); } render() { const { inputValue } = this.state; return (); } handleChange(event) { this.setState({ inputValue: event.target.value }); } handleClick() { localStorage.setItem("inputValue", this.state.inputValue); } }
遺憾的是:
讓我們重構一下
class PersistentForm extends Component { constructor(props) { super(props); this.state = { inputValue: props.initialValue }; this.handleChange = this.handleChange.bind(this); this.handleClick = this.handleClick.bind(this); } render() { const { inputValue } = this.state; return (); } handleChange(event) { this.setState({ inputValue: event.target.value }); } handleClick() { this.props.saveValue(this.state.inputValue); } }
組件從屬性初始值接收存儲的輸入值,并使用屬性函數 saveValue(newValue) 來保存輸入值。這些props 由使用屬性代理技術的 withpersistence() HOC提供。
現在
查詢和保存到本地存儲的職責由 withPersistence() HOC承擔:
function withPersistence(storageKey, storage) { return function (WrappedComponent) { return class PersistentComponent extends Component { constructor(props) { super(props); this.state = { initialValue: storage.getItem(storageKey) }; } render() { return (); } saveValue(value) { storage.setItem(storageKey, value); } } } }
withPersistence()是一個 HOC,其職責是持久的。它不知道有關表單域的任何詳細信息。它只聚焦一個工作:為傳入的組件提供 initialValue 字符串和 saveValue() 函數。
將
const LocalStoragePersistentForm = withPersistence("key", localStorage)(PersistentForm); const instance =;
只要
反之亦然:只要 withPersistence() 提供正確的 initialValue 和 saveValue(),對 HOC 的任何修改都不能破壞處理表單字段的方式。
SRP的效率再次顯現出來:修改隔離,從而減少對系統其他部分的影響。
此外,代碼的可重用性也會增加。你可以將任何其他表單
const LocalStorageMyOtherForm = withPersistence("key", localStorage)(MyOtherForm); const instance =;
你可以輕松地將存儲類型更改為 session storage:
const SessionStoragePersistentForm = withPersistence("key", sessionStorage)(PersistentForm); const instance =;
初始版本
在不好分塊組合的情況下,屬性代理和渲染劫持的 HOC 技術可以使得組件只有一個職責。
謝謝各位小伙伴愿意花費寶貴的時間閱讀本文,如果本文給了您一點幫助或者是啟發,請不要吝嗇你的贊和Star,您的肯定是我前進的最大動力。 https://github.com/YvetteLau/...關注公眾號,加入技術交流群。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/106528.html
摘要:單元測試不僅涉及早期錯誤檢測。當組件的架構設計很脆弱時,就會變得難以測試,而當組件難以測試的時候,你大概念會跳過編寫單元測試的過程,最終的結果就是組件未測試??蓽y試性是確定組件結構良好程度的實用標準??蓮陀玫慕M件是精心設計的系統的結果。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 本篇文章重點闡述可測試和富有意義。因水平有限,文中部分翻譯可...
摘要:幸運的是,組合易于理解。組件的組合是自然而然的。高效用戶界面可組合的層次結構,因此,組件的組合是一種構建用戶界面的有效的方式。這個原則建議避免重復。只有一個組件符合單一責任原則并且具有合理的封裝時,它是可復用的。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和...
摘要:組件可以處理其他組件的實例化為了避免破壞封裝,請注意通過傳遞的內容。因此,將狀態管理的父組件實例傳遞給子組件會破壞封裝。讓我們改進兩個組件的結構和屬性,以便恢復封裝。組件的可重用性和可測試性顯著增加。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的Re...
摘要:父類為,代表著一系列文章的列表。對于可讀性較好地與代碼,不應該像一本書,而應該像一個故事,一個故事中會存在角色和角色之間的關系,而這種更多的語義化地可以較好地提示你整個代碼的可維護性。無論哪種文件組織方式比較順眼,你都應該遵循統一的原則。 原文地址。本文從屬于Web 前端入門與最佳實踐。 CSS的學習是一個典型的低門檻,高瓶頸的過程,第一次接觸CSS的時候覺得一切是如此簡單,直到后面越...
摘要:設計方案的容易改變這就是所謂的軟件構建的可維護性,可擴展性和靈活性。這也可能表明類型或方法可能難以維護?;谠创a中不同運算符和操作數的數量的合成度量。對修改的封閉這種模塊的源代碼是不可侵犯的。 大綱 軟件維護和演變可維護性度量模塊化設計和模塊化原則OO設計原則:SOLIDOO設計原則:GRASP總結 軟件維護和演變 什么是軟件維護? 軟件工程中的軟件維護是交付后修改軟件產品以糾正故障...
閱讀 2797·2023-04-25 23:08
閱讀 1583·2021-11-23 09:51
閱讀 1564·2021-10-27 14:18
閱讀 3115·2019-08-29 13:25
閱讀 2831·2019-08-29 13:14
閱讀 2895·2019-08-26 18:36
閱讀 2193·2019-08-26 12:11
閱讀 811·2019-08-26 11:29