Directives: Reusable Behaviour Without New UI In short: A directive is a component without a template. It lets you attach behaviour to an element that already exists — no wrapper tags, no duplicated markup. Components combine a class, a template, and styles to own a piece of the screen. But what if you want to reuse a behaviour across five different components without adding a wrapper element anywhere? That is what directives are for. When a component is too much Three screens in the Dairy Logistics platform: 1. The collection centre intake screen, where an operator enters milk quality readings. 2. The tanker loading screen, where an operator enters truck capacity. 3. The farmer payout screen, where financial adjustments are entered. All three need the same behaviour: warn visually when a value crosses a threshold — a tank above 85% of capacity, or milk above 10°C. You could build a component, but then every consumer has to swap a plain for a custom tag and deal with form-control wiring just to get a colour change. That is a lot of ceremony for a CSS class. An attribute directive attaches the behaviour to whatever element is already there. Building the directive Here is , used across the app: Three details worth pausing on: The object, not decorators. Angular's best-practices guide is explicit: do not use or . Put host bindings and listeners in the object instead. It keeps everything about the host element in one visible place. , not . A very common mistake is to write an that reaches for and calls . It works, but you have taken over rendering by hand, made server-side rendering harder, and made the directive untestable without a DOM. A plus a host binding lets Angular do the DOM work. . lets consumers pass the main value through the selector itself, which reads better at the call site. How consumers use it Any element or component can adopt the behaviour by adding the attribute: No structural change. No new tags. Existing markup, smarter. A naming note: Angular's style guide asks for camelCase attribute selectors carrying your application prefix — , not . Listening to host events The same object handles events. Here is a directive that asks for confirmation before a destructive click: Composing with host directives Historically, a component that needed directive behaviour had to inherit from a base class. That gets brittle fast — one base class, one chance. lets a component absorb behaviours directly: Two rules people trip over: Inputs and outputs of a host directive are not exposed automatically. You list the ones you want to surface, optionally renaming them ( exposes it to consumers as ). The directive must be standalone — which, in Angular 22, every directive is by default. "But I thought a directive was just a component without a selector" Close, and the confusion is understandable, because Angular really does treat components as a special kind of directive internally. A component is a directive that has a template. But the difference that matters day to day is not the template — it is who owns the element . A component creates its host element. did not exist until you used the component; the component owns that tag, its styles, and everything inside it. A directive borrows an element somebody else created. is still a . The directive can add classes, listen to events, and read state, but it does not own the element and cannot replace its contents. That is why a directive is the right tool when the answer to "what should this look like?" is "like whatever it already looked like, plus a red border." And it is why you cannot use a directive when you need to introduce structure — new child elements, projected content, a distinct visual shape. Cheat sheet Requirement Component Directive --- --- --- Needs its own markup and DOM structure Yes No Needs encapsulated styles Yes Only via classes on the host Enhances an element that already exists No Yes Shares non-visual logic across unrelated elements No Yes Listens to host events Possible Ideal Should be composable into other components Rarely Yes — via Recap Directives add behaviour, not DOM. Reach for one when you need logic without new tags. Use the object. and are no longer recommended. Use with host bindings, not with . Let Angular touch the DOM. Compose with instead of class inheritance — and remember to list the inputs and outputs you want exposed. A component owns its element; a directive borrows one. That is the real dividing line. Next: where the code that has nothing to do with HTML should live.