這些簡單的提示將幫助您構建易于測試，更新和超級靈活的React應用程序。編寫出色的代碼并不一定很復雜。不幸的是，我們經常在構建應用程序時沒有考慮它們將如何演變以適應未來的變化。

　　這些技術將如何成為救命稻草

　　以下是一些常見的場景，在這些場景中，這些小技術將證明是救命稻草：

　　易于測試。

　　適應未來的更新。

　　業務邏輯的分離。

　　可預測的數據流。

　　編寫面向未來的組件

　　在編寫組件時，請始終記住以下拇指規則：

　　UI 組件應始終不知道網絡請求、業務邏輯或應用狀態。

　　組件應該像純函數一樣編寫。它只是意味著，當提供相同的道具時，它應該始終呈現相同的數據。

　　有關編寫出色組件的詳細指南。查看本指南。

　　使用 HOC 使進化變得簡單

　　反應高階組件 (HOC) 是接受組件并返回組件的組件。

　　在編寫 HOC 時，請始終記住以下拇指規則：

　　總是喜歡創建那些不創建任何道具的HOC。如果您的 HOC 需要創建道具，請始終確保它不會創建多個道具。

　　當該行為由應用中的多個組件或所有組件使用時，請使用 HOC。

　　確保該組件可以在沒有 HOC 的情況下工作。組件不應創建與 HOC 的依賴關系。

　　組件可以直接包裝在 HOC 中，而無需向其添加其他邏輯。

　　為干凈的代碼構建應用

　　切勿在單個位置混合視圖呈現問題、數據處理和數據提取?；旌纤袞|西將導致意大利面條式建筑，并且將來會變得痛苦。

　　始終使組件盡可能愚蠢。組件應始終在給定相同狀態的情況下呈現相同的內容。

　　Flux 體系結構允許你為應用創建可預測的數據流。在此體系結構事件中，偵聽器偵聽用戶輸入處理程序和網絡請求處理程序等內容。當事件偵聽器獲取它們時，它會將操作調度到存儲。僅當調度操作時，狀態才會更新。

　　在以下場景中使用基于通量架構的庫，如反流、Redux 等：

　　該組件使用網絡請求或設備 API。

　　具有通用的應用程序狀態。

　　該組件需要與應用的其他部分共享的業務邏輯或數據操作邏輯。

　　使用通量架構不僅可以讓您構建高度靈活的 UI 組件，還可以將業務邏輯等內容與組件分開。它將允許您輕松遷移到不同的數據獲取技術。可預測的單向數據流將使你的應用易于調試和測試。

　　將化簡器視為應用的核心，將調度程序視為適配器。與其在組件中混合業務邏輯，不如將它們放在 Redux(或您正在使用的任何內容)中，并使用操作創建者觸發狀態更改。