如何減少反應道具通過的次數

Question

由於反應網絡應用程序變得複雜，一些組件具有數字道具，其可讀性較差，難以期望該組件做什麼，並且繁瑣地添加大量的道具類型檢查並將道具從最頂層的組件傳遞到底層。這主要是通過傳遞flux/redux行爲和商店從上到下傳遞的結果。

有沒有減少通過的道具數量的好方法？

有兩個解決方案我認爲，這是不完美的：

1. 與傳播運營商{...}道具道具通行證。這確實減少了編寫一些道具和道具類型檢查，但是命名可能有衝突，所以動作/商店的名稱應該是唯一的。另一個缺點是要特別注意道具通過或不要避免副作用。

2. 用一個容器直接將組件的行爲/存儲包裝到組件中，以自組織形式包裝組件。例如，可以使用react-redux的connect()。這比解決方案＃1更清潔和簡單，但如果組件由於Redux錯誤而包含容器，則很難編寫組件測試。錯誤的 一個例子是

Invariant Violation: Could not find "store" in either the context or props of "Connect(Header)". Either wrap the root component in a <Provider>, or explicitly pass "store" as a prop to "Connect(Header)".

Answer 1

你描述的兩種方法以及它們的利弊相當不錯。我會爲你所說的添加一些設計考慮因素。

方法＃2是我的首選方法。減少通過組件的道具數量可以避免複雜性。有許多方法可以測試組件，而不會觸發那個錯誤，但我認爲值得自己單獨的堆棧溢出問題，誠實。現在，我只是說看看淺層渲染，並考慮你是否真的需要在這裏進行單元測試與集成測試。如果您也將在Selenium之類的東西中創建自動化測試，那麼可能也可以用作集成測試。

方法＃1可以通過嚴格使用PropTypes來驗證正在傳遞的內容來改進。將PropTypes檢查放在只傳遞...道具的中間組件上是合理的，但最終組件（實際使用道具而不是僅僅傳遞的組件）應該有非常嚴格的PropTypes聲明。使用形狀而不是對象。使用ArrayOf而不是Array，基本上把所有的機會都放在你的PropTypes聲明中。

關於您對名稱衝突的擔憂，有時候會將道具組合爲一個對象的成員，並將該對象作爲單個道具傳遞。如果道具在概念上是相關的或者具有單個目標組件，則這是有道理的。我仍然非常喜歡只有更多的容器組件（方法＃2），因爲它導致更少的信息流過道具。爲嵌套成員的對象編寫好的PropType需要更多的時間，併產生警告消息，這些消息需要更長的時間才能排除故障。

在開始使用Redux/Flux後，人們有時會忘記.state，有些純粹主義者喜歡通過商店發送和接收所有內容。無狀態組件聲明的優雅使我更加偏向反對向組件添加.state。但.state非常適合追蹤動畫和工具提示可見性等短暫事物。並非所有東西都需要在商店中並通過道具傳遞。