摘要:幸運的是,組合易于理解。組件的組合是自然而然的。高效用戶界面可組合的層次結構,因此,組件的組合是一種構建用戶界面的有效的方式。這個原則建議避免重復。只有一個組件符合單一責任原則并且具有合理的封裝時,它是可復用的。
翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-...
原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的React組件非常有幫助。但因為篇幅實在太長,我對文章進行了分割,本篇文章重點闡述 組合和復用。因水平有限,文中部分翻譯可能不夠準確,如果你有更好的想法,歡迎在評論區指出。
更多文章可戳: https://github.com/YvetteLau/...
———————————————我是一條分割線————————————————
組合一個組合式組件是由更小的特定組件組合而成的。
組合(composition)是一種通過將各組件聯合在一起以創建更大組件的方式。組合是 React 的核心。
幸運的是,組合易于理解。把一組小的片段,聯合起來,創建一個更大個兒。
讓我們來看一個常見的前端應用組合模式。應用由頭部的 header、底部的 footer、左側的 sidebar,還有中部的有效內容聯合而成:
function Application({ children }) { return ({children}); } function Header() { return () } function Footer() { return () } function Sidebar({ children }) { return ({children}); } function Content({ children }) { return ({children}) } function Menu() { return (); } function Article() { return (); } function Label({ children }) { return<{children}>} const app = (); ReactDOM.render(app, document.getElementById("root"));
應用程序演示了組合如何構建應用程序。這種組織這樣組織代碼即富于表現力又便于理解。
React 組件的組合是自然而然的。這個庫使用了一個聲明范式,從而不會抑制組合式的表現力。
那么組合與單一責任以及封裝有什么聯系呢?讓我們一起看看:
單一責任原則描述了如何將需求拆分為組件,封裝描述了如何組織這些組件,組合描述了如何將整個系統粘合在一起。組合的好處 單一責任
組合的一個重要方面在于能夠從特定的小組件組成復雜組件的能力。這種分而治之的方式幫助了被組合而成的復雜組件也能符合 SRP 原則。
回顧之前的代碼片段,
將此職責分為四個子職責是有意義的,每個子職責由專門的組件實現,分別是
現在來看看組合的好處:通過子組件分別實現單一職責的方式,使
組合有可重用的有點,使用組合的組件可以重用公共邏輯,
例如,組件
const instance1 = (/* Specific to Composed1 code... */ /* Common code... */ ); const instance2 = (/* Common code... */ /* Specific to Composed2 code... */ );
代碼復制是一個不好的實踐(例如更改 Composed1 的代碼時,也需要去更改Composed2 中的代碼),那么如何使組件重用公共代碼?
首先,將共同代碼封裝到一個新組件中,如
首先,在新組件中封裝公共代碼。其次,
const instance1 = (); const instance2 = ( );
可重用的組件符合不重復自己(Don"t repeat yourself)的原則。這種做法可以節省你的精力和時間,并且在后期,有利于代碼維護。
靈活在 react 中,一個組合式的組件通過給子組件傳遞 props 的方式,來控制其子組件。這就帶來了靈活性的好處。
例如,有一個組件,它需要根據用戶的設備顯示信息,使用組合可以靈活地實現這個需求:
function ByDevice({ children: { mobile, other } }) { return Utils.isMobile() ? mobile : other; }{{ mobile: Mobile detected!, other:Not a mobile device}}
用戶界面可組合的層次結構,因此,組件的組合是一種構建用戶界面的有效的方式。
注:DRY 原則理論上來說是沒有問題的,但在實際應用是切忌死搬教條。它只能起指導作用,沒有量化標準,否則的話理論上一個程序每一行代碼都只能出現一次才行,這是非常荒謬的,其它的原則也是一樣,起到的也只是指導性的作用。
復用可重用的組件,一次編寫多次使用。
想象一下,如果軟件開發總是重復造輪子。那么當你編寫代碼時,不能使用任何已有庫或工具。甚至在同一個應用中你都不能使用已經編寫過的代碼。在這種環境中,是否有可能在合理的時間內編寫出一個應用呢?絕無可能。
此時應該到認識重用的重要性,使用已有的庫或代碼,而不是重復造輪子。
應用內的復用根據“不要重復自己”(DRY)原則,每一條知識都必須在系統中具有單一,明確,權威的表示。這個原則建議避免重復。
代碼重復增加了復雜性和維護工作,但沒有增加顯著的價值。邏輯更新迫使您修改應用程序中的所有重復代碼。
重復問題可以用可復用組件來解決。一次編寫,多次使用。
但是,復用并非毫無成本。只有一個組件符合單一責任原則并且具有合理的封裝時,它是可復用的。
符合單一職責原則是必須的:
復用一個組件實際上就意味著復用其職責
只有一個職責的組件是最容易復用的。
但是,當一個組件錯誤地具有多個職責時,它的復用會增加大量的開銷。你只想復用一個職責實現,但也會得到不必要的職責實現。比如,你只是想要一個香蕉,但是在你得到一個香蕉的同時,不得不被迫接受所有的叢林。
合理封裝的組件。隱藏了內部實現,并且有明確的 props ,使得組件可以使用與多種需要復用的場合。
復用第三方庫某個工作日,你剛剛收到了為應用增加新特性的任務,在撩起袖子狂敲代碼之前,先稍等幾分鐘。
你要做的工作在很大概率上已經被解決了。由于 React 非常流行以及其非常棒的開源社區,先搜索一下是否有已存在的解決方案是明智之舉。
查看 brillout/awesome-react-components ,它有一個可復用的組件列表。
優秀的第三方庫有結構性的影響,并且會推廣最佳實踐。以我的經驗而言,最有影響的當屬 react-router 和 redux。
react-router 使用了聲明式的路由來構建一個單頁應用。使用
redux 和 react-redux 引入了單向和可預測的應用狀態管理。可以將異步的和非純的代碼(例如 HTTP 請求)從組件中提取出來,從而符合單一職責原則并創建出 純(pure)組件 或 幾乎純(almost-pure)的組件。
這里是一份檢查清單可以確定第三方庫是否值得使用,:
文檔:檢查庫是否具備有意義的 README.md 文件和詳細的文檔
測試過的:可信賴庫的一個顯著特征就是有高的測試覆蓋率
維護:看看庫作者創建新特性、修改bug及日常維護的頻率
最后謝謝各位小伙伴愿意花費寶貴的時間閱讀本文,如果本文給了您一點幫助或者是啟發,請不要吝嗇你的贊和Star,您的肯定是我前進的最大動力。https://github.com/YvetteLau/...
關注小姐姐的公眾號,加入交流群。文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/106659.html
摘要:單元測試不僅涉及早期錯誤檢測。當組件的架構設計很脆弱時,就會變得難以測試,而當組件難以測試的時候,你大概念會跳過編寫單元測試的過程,最終的結果就是組件未測試。可測試性是確定組件結構良好程度的實用標準。可復用的組件是精心設計的系統的結果。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 本篇文章重點闡述可測試和富有意義。因水平有限,文中部分翻譯可...
摘要:編寫組件時要考慮的基本準則是單一職責原則。這些更改通常要求組件在隔離狀態下易于修改這也是的目標。解決多重責任問題需要將分割為兩個組件和。組件之間的通信是通過實現。更改的唯一原因是修改表單字段。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的React組...
摘要:組件可以處理其他組件的實例化為了避免破壞封裝,請注意通過傳遞的內容。因此,將狀態管理的父組件實例傳遞給子組件會破壞封裝。讓我們改進兩個組件的結構和屬性,以便恢復封裝。組件的可重用性和可測試性顯著增加。 翻譯:劉小夕原文鏈接:https://dmitripavlutin.com/7-... 原文的篇幅非常長,不過內容太過于吸引我,還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的Re...
摘要:函數式編程與面向對象編程編程的本質之劍目錄編程的本質讀到兩篇文章寫的不錯綜合摘錄一下復合是編程的本質函數式程序員在洞察問題方面會遵循一個奇特的路線。在面向對象編程中,類或接口的聲明就是表面。 函數式編程與面向對象編程[5]:編程的本質 之劍 2016.5.6 01:26:31 編程的本質 讀到兩篇文章,寫的不錯, 綜合摘錄一下 復合是編程的本質 函數式程序員在洞察問題方面會遵循...
摘要:刪除不必要的代碼。而簡化前的代碼包含的語法要素對于傳達代碼意義本身作用并不大。刪除不必要的代碼有時候,我們試圖為不必要的事物命名。例如,大多數情況下,你應該省略僅僅用來當做返回值的變量。你的函數名應該已經說明了關于函數返回值的信息。 原文地址 本文已在前端早讀課公眾號首發:【第952期】JavaScript代碼風格要素 譯者:墨白 校對:野草 1920年,由威廉·斯特倫克(Will...
閱讀 917·2021-11-24 09:38
閱讀 925·2021-11-23 09:51
閱讀 2938·2021-11-16 11:44
閱讀 1761·2021-09-22 15:52
閱讀 1626·2021-09-10 11:20
閱讀 1361·2019-08-30 13:47
閱讀 1291·2019-08-29 12:36
閱讀 3293·2019-08-26 10:43