摘要：編寫組件時要考慮的基本準則是單一職責(zé)原則。這些更改通常要求組件在隔離狀態(tài)下易于修改這也是的目標(biāo)。解決多重責(zé)任問題需要將分割為兩個組件和。組件之間的通信是通過實現(xiàn)。更改的唯一原因是修改表單字段。

翻譯：劉小夕
原文鏈接：https://dmitripavlutin.com/7-...

原文的篇幅非常長，不過內(nèi)容太過于吸引我，還是忍不住要翻譯出來。此篇文章對編寫可重用和可維護的React組件非常有幫助。但因為篇幅實在太長，我不得不進行了分割，本篇文章重點闡述 SRP，即單一職責(zé)原則。

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

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

我喜歡React組件式開發(fā)方式。你可以將復(fù)雜的用戶界面分割為一個個組件，利用組件的可重用性和抽象的DOM操作。

基于組件的開發(fā)是高效的：一個復(fù)雜的系統(tǒng)是由專門的、易于管理的組件構(gòu)建的。然而，只有設(shè)計良好的組件才能確保組合和復(fù)用的好處。

盡管應(yīng)用程序很復(fù)雜，但為了滿足最后期限和意外變化的需求，你必須不斷地走在架構(gòu)正確性的細線上。你必須將組件分離為專注于單個任務(wù)，并經(jīng)過良好測試。

不幸的是，遵循錯誤的路徑總是更加容易：編寫具有許多職責(zé)的大型組件、緊密耦合組件、忘記單元測試。這些增加了技術(shù)債務(wù)，使得修改現(xiàn)有功能或創(chuàng)建新功能變得越來越困難。

編寫React應(yīng)用程序時，我經(jīng)常問自己：

如何正確構(gòu)造組件？

在什么時候，一個大的組件應(yīng)該拆分成更小的組件？

如何設(shè)計防止緊密耦合的組件之間的通信？

幸運的是，可靠的組件具有共同的特性。讓我們來研究這7個有用的標(biāo)準(本文只闡述 SRP，剩余準則正在途中)，并將其詳細到案例研究中。

當(dāng)一個組件只有一個改變的原因時，它有一個單一的職責(zé)。

編寫React組件時要考慮的基本準則是單一職責(zé)原則。單一職責(zé)原則(縮寫：SRP)要求組件有一個且只有一個變更的原因。

組件的職責(zé)可以是呈現(xiàn)列表，或者顯示日期選擇器，或者發(fā)出 HTTP 請求，或者繪制圖表，或者延遲加載圖像等。你的組件應(yīng)該只選擇一個職責(zé)并實現(xiàn)它。當(dāng)你修改組件實現(xiàn)其職責(zé)的方式（例如，更改渲染的列表的數(shù)量限制），它有一個更改的原因。

為什么只有一個理由可以改變很重要？因為這樣組件的修改隔離并且受控。單一職責(zé)原則制了組件的大小，使其集中在一件事情上。集中在一件事情上的組件便于編碼、修改、重用和測試。

下面我們來舉幾個例子

實例1：一個組件獲取遠程數(shù)據(jù)，相應(yīng)地，當(dāng)獲取邏輯更改時，它有一個更改的原因。

發(fā)生變化的原因是：

修改服務(wù)器URL

修改響應(yīng)格式

要使用其他HTTP請求庫

或僅與獲取邏輯相關(guān)的任何修改。

示例2：表組件將數(shù)據(jù)數(shù)組映射到行組件列表，因此在映射邏輯更改時有一個原因需要更改。

發(fā)生變化的原因是：

你需要限制渲染行組件的數(shù)量（例如，最多顯示25行）

當(dāng)沒有要顯示的項目時，要求顯示提示信息“列表為空”

或僅與數(shù)組到行組件的映射相關(guān)的任何修改。

你的組件有很多職責(zé)嗎？如果答案是“是”，則按每個多帶帶的職責(zé)將組件分成若干塊。

如果您發(fā)現(xiàn)SRP有點模糊，請閱讀本文。
在項目早期階段編寫的單元將經(jīng)常更改，直到達到發(fā)布階段。這些更改通常要求組件在隔離狀態(tài)下易于修改：這也是 SRP 的目標(biāo)。

當(dāng)一個組件有多個職責(zé)時，就會發(fā)生一個常見的問題。乍一看，這種做法似乎是無害的，并且工作量較少：

你立即開始編碼：無需識別職責(zé)并相應(yīng)地規(guī)劃結(jié)構(gòu)

一個大的組件可以做到這一切：不需要為每個職責(zé)創(chuàng)建組成部分

無拆分-無開銷：無需為拆分組件之間的通信創(chuàng)建 props 和 callbacks

這種幼稚的結(jié)構(gòu)在開始時很容易編碼。但是隨著應(yīng)用程序的增加和變得復(fù)雜，在以后的修改中會出現(xiàn)困難。同時實現(xiàn)多個職責(zé)的組件有許多更改的原因。現(xiàn)在出現(xiàn)的主要問題是：出于某種原因更改組件會無意中影響同一組件實現(xiàn)的其它職責(zé)。

不要關(guān)閉電燈開關(guān)，因為它同樣作用于電梯。

這種設(shè)計很脆弱。意外的副作用是很難預(yù)測和控制的。

例如， 同時有兩個職責(zé)，繪制圖表，并處理為該圖表提供數(shù)據(jù)的表單。 就會有兩個更改原因：繪制圖表和處理表單。

當(dāng)你更改表單字段（例如，將 修改為 時，你無意中中斷圖表的渲染。此外，圖表實現(xiàn)是不可重用的，因為它與表單細節(jié)耦合在一起。

解決多重責(zé)任問題需要將 分割為兩個組件： 和

。每個組件只有一個職責(zé)：繪制圖表或處理表單。組件之間的通信是通過props 實現(xiàn)。

多重責(zé)任問題的最壞情況是所謂的上帝組件（上帝對象的類比）。上帝組件傾向于了解并做所有事情。你可能會看到它名為 、 、 或 ，代碼超過500行。

在組合的幫助下使其符合SRP，從而分解上帝組件。(組合（composition）是一種通過將各組件聯(lián)合在一起以創(chuàng)建更大組件的方式。組合是 React 的核心。)

1.2 案例研究：使組件只有一個職責(zé)

設(shè)想一個組件向一個專門的服務(wù)器發(fā)出 HTTP 請求，以獲取當(dāng)前天氣。成功獲取數(shù)據(jù)時，該組件使用響應(yīng)來展示天氣信息：

import axios from "axios";
// 問題: 一個組件有多個職責(zé)
class Weather extends Component {
    constructor(props) {
        super(props);
        this.state = { temperature: "N/A", windSpeed: "N/A" };
    }

    render() {
        const { temperature, windSpeed } = this.state;
        return (
            

                
Temperature: {temperature}°C
                
Wind: {windSpeed}km/h
            
        );
    }

    componentDidMount() {
        axios.get("http://weather.com/api").then(function (response) {
            const { current } = response.data;
            this.setState({
                temperature: current.temperature,
                windSpeed: current.windSpeed
            })
        });
    }
}

在處理類似的情況時，問問自己：是否必須將組件拆分為更小的組件？通過確定組件可能會如何根據(jù)其職責(zé)進行更改，可以最好地回答這個問題。

這個天氣組件有兩個改變原因：

componentDidMount() 中的 fetch 邏輯：服務(wù)器URL或響應(yīng)格式可能會改變。

render() 中的天氣展示：組件顯示天氣的方式可以多次更改。

解決方案是將 分為兩個組件：每個組件只有一個職責(zé)。命名為 和 。

組件負責(zé)獲取天氣、提取響應(yīng)數(shù)據(jù)并將其保存到 state 中。它改變原因只有一個就是獲取數(shù)據(jù)邏輯改變。

import axios from "axios";
// 解決措施: 組件只有一個職責(zé)就是請求數(shù)據(jù)
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
            });
        });
    }
}

這種結(jié)構(gòu)有什么好處？

例如，你想要使用 async/await 語法來替代 promise 去服務(wù)器獲取響應(yīng)。更改原因：修改獲取邏輯

// 改變原因: 使用 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
        });
    }
}

因為 只有一個更改原因：修改 fetch 邏輯，所以對該組件的任何修改都是隔離的。使用 async/await 不會直接影響天氣的顯示。

渲染 。后者只負責(zé)顯示天氣，改變原因只可能是視覺顯示改變。

// 解決方案: 組件只有一個職責(zé)，就是顯示天氣
function WeatherInfo({ temperature, windSpeed }) {
    return (
        

            
Temperature: {temperature}°C
            
Wind: {windSpeed} km/h
        
    );
}

讓我們更改，如不顯示 “wind:0 km/h” 而是顯示 “wind:calm”。這就是天氣視覺顯示發(fā)生變化的原因：

// 改變原因: 無風(fēng)時的顯示
function WeatherInfo({ temperature, windSpeed }) {
    const windInfo = windSpeed === 0 ? "calm" : `${windSpeed} km/h`;
    return (
        

            
Temperature: {temperature}°C
            
Wind: {windInfo}
        
    );
}

同樣，對 的修改是隔離的，不會影響 組件。

和 有各自的職責(zé)。一種組件的變化對另一種組件的影響很小。這就是單一職責(zé)原則的作用：修改隔離，對系統(tǒng)的其他組件產(chǎn)生影響很輕微并且可預(yù)測。

1.3 案例研究：HOC 偏好單一責(zé)任原則

按職責(zé)使用分塊組件的組合并不總是有助于遵循單一責(zé)任原則。另外一種有效實踐是高效組件(縮寫為 HOC)

高階組件是一個接受一個組件并返回一個新組件的函數(shù)。

HOC 的一個常見用法是為封裝的組件增加新屬性或修改現(xiàn)有的屬性值。這種技術(shù)稱為屬性代理：

function withNewFunctionality(WrappedComponent) {
    return class NewFunctionality extends Component {
        render() {
            const newProp = "Value";
            const propsProxy = {
                ...this.props,
                // 修改現(xiàn)有屬性:
                ownProp: this.props.ownProp + " was modified",
                // 增加新屬性:
                newProp
            };
            return ;
        }
    }
}
const MyNewComponent = withNewFunctionality(MyComponent);

你還可以通過控制輸入組件的渲染過程從而控制渲染結(jié)果。這種 HOC 技術(shù)被稱為渲染劫持：

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實踐，我建議您閱讀“深入響應(yīng)高階組件”。

讓我們通過一個例子來看看HOC的屬性代理技術(shù)如何幫助分離職責(zé)。

組件 由 input 輸入框和按鈕 save to storage 組成。更改輸入值后，點擊 save to storage 按鈕將其寫入到 localStorage 中。

input 的狀態(tài)在 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 (
            

                

Save to storage