我的應用場景

• 通常我會通過高階元件去優化之前老專案寫的不好的地方，比如兩個頁面UI幾乎一樣，功能幾乎相同，僅僅幾個操作不太一樣，卻寫了兩個耦合很多的頁面級元件。當我去維護它的時候，由於它的耦合性過多，經常會新增一個功能(這兩個元件都要新增)，我要去改完第一個的時候，還要改第二個。而且有時候由於我的記性不好，會忘掉第二個... 就會出現bug再返工。更重要的是由於個人比較懶，不想去重構這部分的程式碼，因為東西太多了，花費太多時間。所以加新功能的時候，我會寫一個高階元件，往HOC裡新增方法，把那兩個元件包裝一下，也就是屬性代理。這樣新程式碼就不會再出現耦合，舊的邏輯並不會改變，說不定哪天心情好就會抽離一部分功能到HOC裡，直到理想的狀態。

• 另一種情況就是之前寫過一個元件A，做完上線，之後產品加了一個新需求，很奇怪要做的元件B跟A幾乎一模一樣，但稍微有區別。那我可能就通過II的方式去繼承之前的元件A，比如它在didMount去fetch請求，需要的資料是一樣的。不同的地方我就會放到HOC裡，儲存新的state這樣，再通過劫持渲染，把不同的地方，新增的地方進行處理。但其實這算Hack的一種方式，能快速解決問題，也反映了元件設計規劃之初有所不足(原因比較多)。

• Container解決不了的時候甚至不太優雅的時候。其實大部分時候包一層Container元件也能做到差不多的效果，比如操作props，渲染劫持。但其實還是有很大區別的。比如我們現在有兩個功能的container，新增樣式和新增處理函式的，對Usual進行包裝。

高階元件最大的好處就是解耦和靈活性，在react的開發中還是很有用的。

兩種形式

屬性代理

引入裡我們寫的最簡單的形式，就是屬性代理(Props Proxy)的形式。通過hoc包裝wrappedComponent，也就是例子中的Usual，本來傳給Usual的props，都在hoc中接受到了，也就是props proxy。

反向繼承

反向繼承(Inheritance Inversion)，簡稱II，本來我是叫繼承反轉的...因為有個模式叫控制反轉嘛...
跟屬性代理的方式不同的是，II採用通過 去繼承WrappedComponent，本來是一種巢狀的關係，結果II返回的元件卻繼承了WrappedComponent，這看起來是一種反轉的關係。
通過繼承WrappedComponent，除了一些靜態方法，包括生命週期，state，各種function，我們都可以得到。