孩子與父母的溝通不發射

Question

我有個疑問。 我可以想到兩種子組件到父組件通信的方法。

標准方法：由於缺少更好的名稱，因此將其稱為標准方法。 它的什么是常用的。 它使用 @Output() EventEmitter 並發出事件。

替代方法：在這種情況下不使用發射。 相反，父組件的方法是直接從子組件調用的。

它可能不像在 <app-std-approach-child/> 中包含 (jsonStringEvent)="onJsonStringEvent($event)" 那樣酷

但是更簡單。 我假設它也更容易調試。

疑惑：為什么我沒有看到有人使用替代方法？

如果需要，請在此處參考代碼。 https://stackblitz.com/github/doubtasker/doubt1和https://github.com/doubtasker/doubt1 。

編輯：問題與主題無關。 它只是關於從孩子到父母的發射與直接從孩子調用父方法。 當孩子只有 1 個父母要與之交流時，我們應該使用 go 進行發射還是直接調用父母的方法就足夠了。

編輯：在我看來，如果子組件只需要將數據傳輸給那個父組件，他就可以使用方法調用。 如果開發人員擔心將來需要為他的子組件使用其他父組件，他可以在將來使用 emit 編寫時根據需要進行松散耦合。

這對我來說不是很有說服力。 但猜猜這就是它的全部。 您可以繼續進行一層又一層的松耦合，但最終目標不是松耦合。

在我看來，最有說服力（如果不是最有說服力的話）的觀點是網絡技術所說的話。 官方文件只提到這個- https://angular.io/guide/inputs-outputs#sharing-data-between-child-and-parent-directives-and-components @Output and Emitter。 這是因為我們這樣做的官方文檔。

要問的大問題是為什么官方文檔沒有說你也可以用更簡單的方法來做。

但是 cybering 確實表示直接方法調用也是一種可能的方法，並且在框架中可用。

最后，我最喜歡這條關於 cybering 的評論：您的方法是有效的，但僅限於子組件在沒有父組件的情況下存在沒有意義的場景。 （換句話說，您看不到子組件在另一個父組件中被重用）

感謝您的幫助。

Answer 1

您實際上可以使用組件注入作為在這些組件之間進行通信的一種方式，但您必須小心。 首先，在您的特定情況下，這種方法可能會導致循環引用，因為您將子組件導入父組件，並將父組件導入子組件。 您可以在這里看到類似的問題。

另一方面，這種方法在 parent 和 child 之間創建了強耦合，並且在具有復雜邏輯的大型項目中，這可能導致難以維護的代碼。

最簡單的場景可能是：

• 如果您出於某種原因在父組件上更改方法名稱，您應該在子組件中執行相同的操作。 如果您必須對父級執行完整的重構並且您正在使用其中的幾種方法，這可能是一場噩夢。
• 如果您只想在應用程序的另一部分重用您的子組件，那么如果不進行適當的重構，那將是不可能的，因為父組件和子組件之間沒有隔離。

出於這個原因，我認為@Output()方法是 go 更流行的方法，並且是官方文檔中提供的在父子之間共享數據的方法。

我希望這可以為您的問題提供明確的答案。

編輯：

您的方法是有效的，但僅限於子組件在沒有父組件的情況下存在沒有意義的場景。

我們編寫組件的主要原因之一是在代碼中重用它們，如果沒有適當的隔離，它們的可重用性是不可能的。 這會導致您使用其他方法，例如@Output 。

Answer 2

您可以使用依賴注入來獲取對父級的引用，這樣您就可以訪問所有公共字段和函數。

這是一個小例子： https://angular-ivy-lz6kgo.stackblitz.io

Answer 3

質疑任何事情總是好的。 由於 EJB 最佳實踐的日子經常被模仿，但當社區最終呼喚並嗅出復雜性時，確實會發生變化。 作者只是在詢問是否可以讓代碼更簡單，或者以更復雜的“發出”方式編寫代碼來處理未來可能永遠不會發生的變化——需要如此多的松散耦合。

Answer 4

請參閱https://angularconcepts.github.io/從那里訪問 emitconcept 鏈接。 我嘗試根據相同但修改過的代碼添加我的想法。

拉古