可靠React組件設計的7個準則之終篇

jasperyang 發布于2019-08-26 10:56 / 1942人閱讀

摘要：單元測試不僅涉及早期錯誤檢測。當組件的架構設計很脆弱時，就會變得難以測試，而當組件難以測試的時候，你大概念會跳過編寫單元測試的過程，最終的結果就是組件未測試。可測試性是確定組件結構良好程度的實用標準。可復用的組件是精心設計的系統的結果。

翻譯：劉小夕

原文鏈接：https://dmitripavlutin.com/7-...

本篇文章重點闡述可測試和富有意義。因水平有限，文中部分翻譯可能不夠準確，如果你有更好的想法，歡迎在評論區指出。

盡管組合、復用和 純組件 三個準則閱讀量不高，不過本著有始有終的原則，當然我個人始終還是覺得此篇文章非常優質，還是堅持翻譯完了。本篇是最后 可靠React組件設計 的最后一篇，希望對你的組件設計有所幫助。

更多文章可戳: https://github.com/YvetteLau/...

———————————————我是一條分割線————————————————

如果你還沒有閱讀過前幾個原則:

可靠React組件設計的7個準則之SRP

可靠React組件設計的7個準則之封裝

可靠React組件設計的7個準則之組合和復用

可靠React組件設計的7個準則之純組件

可測試和經過測試

經過測試的組件驗證了其在給定輸入的情況下，輸出是否符合預期。

可測試組件易于測試。

如何確保組件按預期工作？你可以不以為然地說：“我通過手動驗證其正確性”。

如果你計劃手動驗證每個組件的修改，那么遲早，你會跳過這個繁瑣的環節，進而導致你的組件遲早會出現缺陷。

這就是為什么自動化組件驗證很重要：進行單元測試。單元測試確保每次進行修改時，組件都能正常工作。

單元測試不僅涉及早期錯誤檢測。另一個重要方面是能夠驗證組件架構是否合理。

我發現以下幾點特別重要：

一個不可測試或難以測試的組件很可能設計得很糟糕。

組件很難測試往往是因為它有很多 props、依賴項、需要原型和訪問全局變量，而這些都是設計糟糕的標志。

當組件的架構設計很脆弱時，就會變得難以測試，而當組件難以測試的時候，你大概念會跳過編寫單元測試的過程，最終的結果就是：組件未測試。

總之，需要應用程序未經測試的原因都是因為設計不當，即使你想測試這樣的應用，你也做不到。

案例學習：可測試意味著良好的設計

我們來測試一下封裝章節的兩個版本的組件。

import assert from "assert";
import { shallow } from "enzyme";

class Controls extends Component {
    render() {
        return (
            
                
                
            
        );
    }
    updateNumber(toAdd) {
        this.props.parent.setState(prevState => ({
            number: prevState.number + toAdd
        }));
    }
}

class Temp extends Component {
    constructor(props) {
        super(props);
        this.state = { number: 0 };
    }
    render() {
        return null;
    }
}

describe("", function () {
    it("should update parent state", function () {
        const parent = shallow();
        const wrapper = shallow();

        assert(parent.state("number") === 0);

        wrapper.find("button").at(0).simulate("click");
        assert(parent.state("number") === 1);

        wrapper.find("button").at(1).simulate("click");
        assert(parent.state("number") === 0);
    });
});

我們可以看到測試起來很復雜，因為它依賴父組件的實現細節。

測試時，需要一個額外的組件，它模擬父組件，驗證是否正確修改了父組件的狀態。

當獨立于父組件的實現細節時，測試會變得更加容易。現在我們來看看正確封裝的版本是如何測試的:

import assert from "assert";
import { shallow } from "enzyme";
import { spy } from "sinon";

function Controls({ onIncrease, onDecrease }) {
    return (
        
            
            
        
    );
}

describe("", function () {
    it("should execute callback on buttons click", function () {
        const increase = sinon.spy();
        const descrease = sinon.spy();
        const wrapper = shallow(
            
        );

        wrapper.find("button").at(0).simulate("click");
        assert(increase.calledOnce);
        wrapper.find("button").at(1).simulate("click");
        assert(descrease.calledOnce);
    });
});

良好封裝的組件，測試起來簡單明了，相反，沒有正確封裝的組件難以測試。

可測試性是確定組件結構良好程度的實用標準。

富有意義

很容易一個有意義的組件作用是什么。

代碼的可讀性是非常重要的，你使用了多少次模糊代碼？你看到了字符串，但是不知道意思是什么。

開發人員大部分時間都在閱讀和理解代碼，而不是實際編寫代碼。我們花75％的時間理解代碼，花20％的時間修改現有代碼，只有5％編寫新的代碼。

在可讀性方面花費的額外時間可以減少未來隊友和自己的理解時間。當應用程序增長時，命名實踐變得很重要，因為理解工作隨著代碼量的增加而增加。

閱讀有意義的代碼很容易。然而，想要編寫有意義的代碼，需要清晰的代碼實踐和不斷的努力來清楚地表達自己。

組件命名 帕斯卡命名法

組件名是由一個或多個帕斯卡單詞（主要是名詞）串聯起來的，比如：、、Application、

。

專業化

組件越專業化，其名稱可能包含的單詞越多。

名為的組件表示頭部有一個菜單。名稱表示位于側欄中的菜單項。

當名稱有意義地暗示意圖時，組件易于理解。為了實現這一點，通常你必須使用詳細的名稱。那很好：更詳細比不太清楚要好。

假設您導航一些項目文件并識別2個組件：和。僅基于名稱，您能否得出它們之間的區別？很可能不能。

為了獲取詳細信息，你不得不打開源文件并瀏覽代碼。字后，你知道從服務器獲取作者列表并呈現組件。

更專業的名稱而不是不會創建這種情況。更好的名稱如：，或。

一個單詞 - 一個概念

一個詞代表一個概念。例如，呈現項目概念的集合由列表單詞表示。

每個概念對應一個單詞，然后在整個應用程序中保持關系一致。結果是可預測的單詞概念映射關系。

當許多單詞表示相同的概念時，可讀性會受到影響。例如，你定義一個呈現訂單列表組件為：，定義另一個呈現費用列表的組件為：。

渲染項集合的相同概念由2個不同的單詞表示：list 和 table。對于相同的概念，沒有理由使用不同的詞。它增加了混亂并打破了命名的一致性。

將組件命名為和（使用 list）或和（使用 table ）。使用你覺得更好的詞，只要保持一致。

注釋

組件，方法和變量的有意義的名稱足以使代碼可讀。因此，注釋大多是多余的。

案例研究：編寫自解釋代碼

常見的濫用注釋是對無法識別和模糊命名的解釋。讓我們看看這樣的例子：

//  渲染 games 列表
// "data" prop contains a list of game data
function Games({ data }) {
    // display up to 10 first games
    const data1 = data.slice(0, 10);
    // Map data1 to  component
    // "list" has an array of  components
    const list = data1.map(function (v) {
        // "v" has game data
        return ;
    });
    return {list};
}

上例中的注釋澄清了模糊的代碼。，data, data1, v,，數字 10 都是無意義的，難以理解。

如果重構組件，使用有意義的 props 名和變量名，那么注釋就可以被省略：

const GAMES_LIMIT = 10;

function GamesList({ items }) {
    const itemsSlice = items.slice(0, GAMES_LIMIT);
    const games = itemsSlice.map(function (gameItem) {
        return ;
    });
    return {games};
}

不要使用注釋去解釋你的代碼，而是代碼即注釋。(小夕注：代碼即注釋很多人未必能做到，另外因團隊成員水平不一致，大家還是應該編寫適當的注釋)

表現力階梯

我將一個組件表現力分為4個臺階。組件在樓梯上的位置越低，意味著需要更多的努力才能理解。

你可以通過以下幾種方式來了解組件的作用：

讀取變量名和 props

閱讀文檔/注釋

瀏覽代碼

咨詢作者

如果變量名和 props 提供了足夠的信息足以讓你理解這個組件的作用和使用方式，那就是一種超強的表達能力。盡量保持這種高質量水平。

有些組件具有復雜的邏輯，即使是好的命名也無法提供必要的細節。那么就需要閱讀文檔。

如果缺少文檔或沒有文檔中沒有回答所有問題，則必須瀏覽代碼。由于花費了額外的時間，這不是最佳選擇，但這是可以接受的。

在瀏覽代碼也無助于理解組件時，下一步是向組件的作者詢問詳細信息。這絕對是錯誤的命名，并應該避免進入這一步。最好讓作者重構代碼，或者自己重構代碼。

持續改進

重寫是寫作的本質。專業作家一遍又一遍地重寫他們的句子。

要生成高質量的文本，您必須多次重寫句子。閱讀書面文字，簡化令人困惑的地方，使用更多的同義詞，刪除雜亂的單詞 - 然后重復，直到你有一段愉快的文字。

有趣的是，相同的重寫概念適用于設計組件。有時，在第一次嘗試時幾乎不可能創建正確的組件結構，因為：

緊迫的項目排期不允許在系統設計上花費足夠的時間

最初選擇的方法是錯誤的

剛剛找到了一個可以更好地解決問題的開源庫

或任何其他原因。

組件越復雜，就越需要驗證和重構。

組件是否實現了單一職責，是否封裝良好，是否經過充分測試？如果您無法回答某個肯定，請確定脆弱部分（通過與上述7個原則進行比較）并重構該組件。

實際上，開發是一個永不停止的過程，可以審查以前的決策并進行改進。

可靠性很重要

組件的質量保證需要努力和定期審查。這個投資是值得的，因為正確的組件是精心設計的系統的基礎。這種系統易于維護和增長，其復雜性線性增加。

因此，在任何項目階段，開發都相對方便。

另一方面，隨著系統大小的增加，你可能忘記計劃并定期校正結構，減少耦合。僅僅是是實現功能。

但是，在系統變得足夠緊密耦合的不可避免的時刻，滿足新要求變得呈指數級復雜化。你無法控制代碼，系統的脆弱反而控制了你。錯誤修復會產生新的錯誤，代碼更新需要一系列相關的修改。

悲傷的故事要怎么結束？你可能會拋棄當前系統并從頭開始重寫代碼，或者很可能繼續吃仙人掌。我吃了很多仙人掌，你可能也是，這不是最好的感覺。

解決方案簡單但要求苛刻：編寫可靠的組件。

結論

前文所說的7個準則從不用的角度闡述了同一個思想：

可靠的組件實現一個職責，隱藏其內部結構并提供有效的 props 來控制其行為。

單一職責和封裝是 solid 設計的基礎。(maybe你需要了解一下 solid 原則是什么。)

單一職責建議創建一個只實現一個職責的組件，并有一個改變的理由。

良好封裝的組件隱藏其內部結構和實現細節，并定義 props 來控制行為和輸出。

組合結構大的組件。只需將它們分成較小的塊，然后使用組合進行整合，使復雜組件變得簡單。

可復用的組件是精心設計的系統的結果。盡可能重復使用代碼以避免重復。

網絡請求或全局變量等副作用使組件依賴于環境。通過為相同的 prop 值返回相同的輸出來使它們變得純凈。

有意義的組件命名和表達性代碼是可讀性的關鍵。你的代碼必須易于理解和閱讀。

測試不僅是一種自動檢測錯誤的方式。如果你發現某個組件難以測試，則很可能是設計不正確。

成功的應用站在可靠的組件的肩膀上，因此編寫可靠、可擴展和可維護的組件非常中重要。

在編寫React組件時，你認為哪些原則有用？

最后謝謝各位小伙伴愿意花費寶貴的時間閱讀本文，如果本文給了您一點幫助或者是啟發，請不要吝嗇你的贊和Star，您的肯定是我前進的最大動力。https://github.com/YvetteLau/...

關注小姐姐的公眾號，加入交流群。

GPU云服務器云服務器深度學習的7個有效組件設計數據可視化7個數據類型終篇

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/106861.html

可靠React組件設計的7個準則之封裝

摘要：組件可以處理其他組件的實例化為了避免破壞封裝，請注意通過傳遞的內容。因此，將狀態管理的父組件實例傳遞給子組件會破壞封裝。讓我們改進兩個組件的結構和屬性，以便恢復封裝。組件的可重用性和可測試性顯著增加。翻譯：劉小夕原文鏈接：https://dmitripavlutin.com/7-... 原文的篇幅非常長，不過內容太過于吸引我，還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的Re...

yck 2019-08-26 10:40 評論0 收藏0
可靠React組件設計的7個準則之組合和復用

摘要：幸運的是，組合易于理解。組件的組合是自然而然的。高效用戶界面可組合的層次結構，因此，組件的組合是一種構建用戶界面的有效的方式。這個原則建議避免重復。只有一個組件符合單一責任原則并且具有合理的封裝時，它是可復用的。翻譯：劉小夕原文鏈接：https://dmitripavlutin.com/7-... 原文的篇幅非常長，不過內容太過于吸引我，還是忍不住要翻譯出來。此篇文章對編寫可重用和...

Amos 2019-08-26 10:43 評論0 收藏0
可靠React組件設計的7個準則之SRP

摘要：編寫組件時要考慮的基本準則是單一職責原則。這些更改通常要求組件在隔離狀態下易于修改這也是的目標。解決多重責任問題需要將分割為兩個組件和。組件之間的通信是通過實現。更改的唯一原因是修改表單字段。翻譯：劉小夕原文鏈接：https://dmitripavlutin.com/7-... 原文的篇幅非常長，不過內容太過于吸引我，還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的React組...

Charles 2019-08-26 10:39 評論0 收藏0
程序員練級攻略（2018）：前端 UI/UX設計

摘要：前端還有一個很重要的事就是設計。，中文版譯名為認知與設計理解設計準則。實驗室是布拉德弗羅斯特依照這個設計系統所建立的一套工具，可以前往的來試試。中文翻譯為流暢設計體系，是微軟于年開發的設計語言。微軟于年月日的開發者大會上公開了該設計體系。 showImg(https://segmentfault.com/img/bVbkgFI?w=1142&h=640); 想閱讀更多優質文章請猛戳Gi...

dongfangyiyu 2019-08-02 12:09 評論0 收藏0
關于PHP加解密之終扯到ECDH了（API安全加強篇三）

摘要：很明顯，非對稱加密的極大的消耗成了一種瓶頸。其中，利用非對稱加密的方案大概就是我前面說的那樣，偽代碼已經展示過了。其實，前面兩篇翻來覆去只為叨逼叨叨逼叨兩件事情：對稱加解密，典型算法有AES、DES、3DES等等非對稱加解密，典型的算法有RSA、DSA、ECDH等等但是，我知道大家最討厭在看這種文章的時候冒出來的一坨橢圓曲線、素數、質數等等這樣的玩意，反正看也看不懂，理解也...

lcodecorex 2019-07-01 12:45 評論0 收藏0