child to parent communication without emitting-CodePudding

I have a doubt. I can think of two approaches for child component to parent component communication.

Standard approach: For want of a better name called it the standard Approach. Its whats is commonly used. It uses @Output() EventEmitter and emitting of the event.

Alternate approach: In this event emitting is not used. Instead Parent Component's method is directly invoked from child.

It may not be as cool looking as say having (jsonStringEvent)="onJsonStringEvent($event)" inside <app-std-approach-child/>

But is simpler. I am assuming its more straightforward to debug also.

The doubt:Why do I not see anyone using the alternate approach?

Please refer here for the code if needed. https://stackblitz.com/github/doubtasker/doubt1 and https://github.com/doubtasker/doubt1.

Edit: The question is not about Subject. Its only about emiting from child to parent vs directly invoking parent method from child. When there is only 1 parent to communicate to by the child should we go for emiting or is direct invoking of parent's method good enough.

Edit: It looks to me that if the child component needs to transmit data to that one parent only he can use the method invocation. If the developer is worried about needing to use some other parent in future for his child component he can for loose coupling as needed in future write using emit.

That is not very convincing to me. But guess thats all there is to it. You can keep doing layers and layers of loose coupling but the end goal in not the loose coupling.

The most compelling if not convincing point the way I see it is what cybering said. the official document mentions only this- https://angular.io/guide/inputs-outputs#sharing-data-between-child-and-parent-directives-and-components @Output and Emitter. Its because of the official documentation we do it that way.

The big question to ask is why did the official document not say that you could also do it in a simpler way.

But cybering did say direct method invocation is also a possible approach and is available in the framework.

CodePudding user response：

You actually could use component injection as a way to communicate betweeen those components but you have to be careful. In the first place in your particular case this approach could lead to a circular reference, since you are importing the child component into the parent, and the parent into the child. You could see a similar problem here.

In the other hand this kind of approach creates a strong coupling between parent and child, and in a large project with a complex logic this could lead to a hard code to mantain.

The simplest scenarios could be:

If you change a method name for some reason on the parent component, you should do the same in the child. This could be a nightmare if you have to perform a complete refactoring of the parent and you are using several methods from it.
If you want to reuse only your child component in another part of your app, that would be impossible without a proper refactoring because there is no isolation between parent and child components.

For this reasons I think that the @Output() approach is the more popular way to go and is the provided way to share data between parent and child in the official documentation.

I hope that this could provide a clear answer to your question.

EDIT:

Your approach is valid but is restricted to the scenario where it doesn't make sense for the child component to exist without a parent.

One of the main reasons we write components is to reuse them in our code, and their reusability is impossible without proper isolation. This leads you to use other approachs like the @Output.

CodePudding user response：

You can use the dependency injection to get a reference to the parent, with that you can access all public fields and functions.

Here is a small example: https://angular-ivy-lz6kgo.stackblitz.io

CodePudding user response：

Its always good to question anything. Since the days of EJB best practices were parroted so often but change does happen when community eventually calls out and smells through the complexity. The author is just asking if its good to keep code simpler or write it in a more complicated "emit" way to take care of future changes that may never happen - needing so much loose coupling.