@Input/@Output vs shared service for Angular component communication

Learning goals

• Who really owns the state?
• Does the communication match the component tree?
• Is this just communication or real shared feature state?
• Where will the next developer understand the flow faster?

Key decisions to discuss

• Pick a direction for this exact prompt, not the universal winner.
• State the trade-off that matters most for this scenario.
• Name when another option becomes the better answer.
• Keep the explanation grounded in concrete constraints.

Evaluation rubric

• Strong answers tie the recommendation to the prompt.
• Good tradeoff reasoning explains downsides, not just upsides.
• The answer should show when the recommendation stops being right.
• Follow-up pressure should not break the argument.

Constraints / Requirements

• Which direction would you defend for this prompt, and how would you explain when the other option is…
• Fits best when the data flow already matches the component tree and the parent is the…
• Fits best when several components need a shared feature state or coordination that no single parent…

Options on the table

Use @Input() and @Output(): Fits best when the data flow already matches the component tree and the parent…
Use a shared service: Fits best when several components need a shared feature state or coordination that no…

Common pitfalls

• Arguing from preference instead of prompt constraints.
• Pretending one option is always the winner.
• Ignoring the main downside of the chosen direction.
• Failing to explain when the alternative becomes stronger.

Related questions

• Async pipe vs manual subscribe for Angular UI dataFree
• Route resolver vs fetch in ngOnInit for Angular page dataPremium
• Pure pipe vs component method in an Angular templatePremium
• Reactive forms vs template-driven forms for a growing Angular workflowFree