Componentsintermediate
Smart and Presentational Components
Explain the smart/container vs presentational/dumb component pattern and why it improves testability and reuse.
The smart/presentational split (also called container/presentational) isn't an Angular-specific API — it's an architectural convention borrowed from the broader component-based UI world — but Angular interviews ask about it because it's one of the clearest ways to demonstrate you can structure an application beyond just making individual components work.
A restaurant kitchen (smart component) handles sourcing ingredients and cooking, while the plating station (presentational component) just arranges whatever it's handed beautifully — swap kitchens and the plating station still works the same way.
Key Concepts
1
A presentational component only knows about its @Input()s and @Output()s; it renders what it's given and emits events for what happens, with zero knowledge of services, stores, or where its data came from. A smart component, by contrast, injects services, subscribes to observables or reads signals from a store, and passes the resulting data down to one or more presentational children, translating their output events into calls back into services.
@Input()@Output()
2
The payoff is testability and reuse: a presentational component can be tested with plain inputs and spied-on output handlers with no DI setup at all, and it can be reused in completely different feature contexts since it has no hidden dependencies. Smart components, meanwhile, concentrate all the messy orchestration logic in one place, making it easier to reason about where side effects happen.
3
A sharp interview answer acknowledges the trade-off: not every component needs this split, and forcing it onto trivial components adds indirection for no benefit — it earns its keep specifically in larger features with real data-fetching and business logic.