close
[不知理解是否正確，先記錄]
https://medium.com/@maxheiber/no-need-for-dependency-injection-in-react-components-641182760aaa
恩... Angular 說他的重點就是 Dependency Injection，React則說你根本不需要DI... @@
Angular的範例，DI主要用途在於將Component中的Dependencyt抽離，優點主要有反應需求變更跟便於測試。大部分用途有以下三種：
1. 抽離商業邏輯
2. 抽離後端API調用
3. 在組件中放另一個組件
[抽離商業邏輯]
不需要，因為商業邏輯根本不應該出現在介面組件中。參考Wiki: "Separation of Concerns" 的敘述。
[抽離API調用]
在React Component中，可將資料的載入與變更等事件處理透過props開放，雖然這並非常見的作法，但不代表他不理想。也就是說，Component只負責在不同的時機點觸發事件，而後續動作則由引用Component的應用程式決定。
透過Virtual Dom提供的機制，在資料更新時，Component自然會被通知並更新，因此Component不需要有自己的State，另一方面，Component介面中引發的資料變更，不應該由Component自行處理該邏輯，而是委派給應用程式，再由應用程式進行資料處理，以及必要的Virtual Dom資料更新。
[在組件中放另一個組件]
這段比較看不懂，大概是在講不管是Angular、React或Vue都提供了自訂組件，甚至是自訂標籤來代表組件的做法，因此在組件中放另一組件並非問題。
子組件的相依注入問題應該是在介面單元測試上，在介面的單元測試中，對於子組件內容並不在意，透過相異注入可mock子組件，然後替換成易於檢查的版本。
在React無法將已經定義的子組件臨時替換掉，但是可以利用Shallow Rendering Helper來限制Component只render一層，如此一來就比較好驗證介面顯示是否正常。
原則上React的Component是期望以Stateless、Logic-less的思維來進行，因此如果設計正確的話，測試階段就不只需要關注介面的設定是否正確即可。
------------------------
剛看到Angular的DI介紹時，覺得很不錯，架構上就考慮到了許多問題，不過當下順手查了一下React怎麼做時，才又發現一個重點，在做好State規劃的前提下，介面本身就不會帶太多邏輯，甚至有了Data-Binding的機制後，開發過程中就幾乎沒有View的邏輯要處理了，這時候在介面層的確也不需要再做DI了。
不過DI相對於後續要做Unit-Test是很重要的一個觀念，雖然設計上有點"搞鋼"，但是對於品質控管有很大的貢獻。
話說以前寫網頁程式是最簡單最好入門的了，現在有那麼多新的Framework，引入了各種良好的設計後，開發確實變得簡單了，但進入門檻卻也同時提升了。
話說回來，一篇文章就讓我省了半年的時間，真是划算阿... XD
#這只是筆記
#不寫點筆記我會睡著
全站熱搜
留言列表
