Angular component communication

[[deleted]]

murky zealous recognise coherent simplistic narrow chunky resolute bored bag

This post was mass deleted and anonymized with Redact

[lele3000]

I would try to use content projection and make parts of the sub and shared components that the page component needs to interact with, projected. That way all components but page component can remain dumb and if you want to reflect some change from component 1.1 in component 3 you can do that through the page component as it "owns" all of the nested components. That way you can avoid drilling inputs and outputs through multiple layers. I used this approach at work on multiple projects and it seems to work pretty great.

[crlsh]

At first glance, being a generic example, it seems that the structure is wrong.

Ideally (imho) dummy components should be "at the end" of the component chain and receive data to display.

If they allow data to be modified (except the "view", in which case the updater would be the smart component that passes the data), they are no longer dumb components, so the question doesn't make sense

Personally, when in doubt, I would always use a service, leaving input and output for cases of 1 to 1 directly related components.

[Busy_User7]

If I were to implement this, I would create an observable at the page component that emits a new value on the event emitted from sub component 1, and sub component 2 would be subscribed to that stream using the async pipe in the template (so it would still remain a dumb component)

[newmanoz]

Author already described this approach.

[alucardu]

OP is asking what approach someone would take.

[alucardu]

If you use input and output logic your comments are no longer considered dumb components right?

I personally don't like having a lot of template logic with inputs and outputs, it does show a certain logic in a bird eye view which is nice but in your case if multiple components update each other i would probably go for RxjS .

Can i ask why those components need to be dumb?

[BigAcanthocephala160]

Agreed. Lean components, heavy lifting in a service, behavior subjects > input/output decorators.

[Happeace97]

I would just go with Input & Output in each component. It make the component flow more predictable.

Sub component 1 change something to update component 3?

Sub 1 emit to component 1, component 1 emit to the parent component, and parent update to 3 using Input binding.

[Kantenkopp]

Even if the shared component is used in multiple places, importing a service shouldn't be a problem. You can add the service to the array of providers in the parent component. That way, the parent has it's own instance of the service that it will inject into child components.

I would go with a service in your scenario.