A static page is a document; an interactive page is an application. Event binding is the mechanism that turns your templates into living interfaces.
1The Callback Pattern
Event binding creates a 'reaction' to a user action. When an event occurs (like a click, a hover, or a keystroke), Angular executes the expression you provided. Usually, this expression is a call to a method in your component class. This keeps your template clean and moves the complex logic where it belongs: in your TypeScript code.
2The $event Payload
Sometimes simply knowing that an event happened isn't enough. You might need to know which key was pressed or the current value of an input field. Angular provides a reserved variable called $event that contains the standard DOM event object. By passing this into your method, you gain full access to the event's properties and the element that triggered it.
3Step-by-Step Breakdown
While data binding projects data TO the view, Event Binding listens for actions FROM the view. It's how we make our apps interactive.
We use parentheses to bind to an event, like (click). When the event happens, Angular calls the method we specified in our class.
You can listen to any DOM event: (mouseover), (keyup), (submit), and more. It follows the standard JavaScript event names without the 'on' prefix.
Checkpoint: What is the correct syntax to listen for a 'click' event in an Angular template?
- →[click]
- →(click)
- →{{click}}
Sometimes you need details about the event, like which key was pressed. We use the special '$event' variable to pass this data to our method.
In Event Binding, data flows from the View (HTML) to the Logic (TS). It's the opposite of Property Binding.
Checkpoint: In Event Binding, which special variable name is used to access the DOM event object?
- →e
- →event
- →$event
Excellent work! You can now send data to the view AND listen for user actions. In the next chapter, we'll combine both for Two-Way Binding!
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1`(click)` on a Native Interactive Element Comes With Free Keyboard Support
Binding `(click)` to a real `<button>` inherits the browser's default Enter/Space keyboard activation for free; binding the same `(click)` to a `<div>` gets none of that, and requires manually added `(keydown.enter)`/`(keydown.space)` handlers plus `tabindex` and a `role`.
2Event Bindings Should Never Be the Only Way to Trigger Critical Actions Behind a Mouse-Only Event
`(mouseenter)`/`(mouseleave)` bound tooltips or menus are inaccessible to keyboard and touch users entirely unless paired with an equivalent `(focus)`/`(blur)` binding for keyboard users.
SEO Implications
- 1
Content Revealed Only via Event Bindings Isn't Present in Initial Server-Rendered HTML
If primary content only appears after a `(click)` handler runs (e.g., an accordion that starts collapsed with content not in the DOM until expanded), crawlers evaluating the initial render may never see it — consider whether critical content should be visible by default instead.
- 2
Event-Driven View Changes Without Real Navigation Create Unlinkable States
A `(click)` handler that swaps displayed content without updating the URL via the Router means that specific view has no unique, shareable, bookmarkable, or indexable URL — use route-based navigation for any state that should be independently linkable.
Best Practices
Prefer Binding to Semantic Events Over Generic Ones Where Available
Use `(submit)` on a `<form>` rather than `(click)` on its submit button — this correctly captures Enter-key submission from any field in the form, not just an explicit click on the button.
Always Call `event.preventDefault()` Explicitly When Overriding Default Browser Behavior
Binding `(submit)` on a form without calling `$event.preventDefault()` still triggers a full browser page reload/navigation alongside your handler — an easy-to-miss bug since it may not be obvious in a fast local dev environment.
Frequent Bugs
A form's submit handler runs, but the page also fully reloads immediately after.
The `(ngSubmit)`/`(submit)` handler never called `event.preventDefault()` (or wasn't passed the `$event` object at all), so the browser's native form submission still occurs alongside the Angular handler, causing a full page reload.
A custom clickable element built from a styled `<div>` with `(click)` works with a mouse but is completely unusable via keyboard.
Native elements like `<button>` get keyboard activation (Enter/Space) automatically; a `<div>` does not. Either switch to a real `<button>` styled to match the design, or add `tabindex="0"`, `role="button"`, and explicit `(keydown.enter)`/`(keydown.space)` bindings to replicate native behavior.
Real-World Examples
Accessible Form Submission With Event Binding
A login form binds to the semantic `(ngSubmit)` event rather than a button's `(click)`, correctly handling both mouse clicks and Enter-key submission from any field, while explicitly preventing the native page reload.
<form (ngSubmit)="onSubmit()">
<input name="email" ngModel>
<button type="submit">Log In</button>
</form>