If you're wiring keyboard events inside Angular components using @HostListener, your architecture is already leaking.
You're modelling a global problem as local logic.
It might feel clean.
keydown. A few conditionals. A call to element.focus().
That approach works until your application grows beyond simple forms.
Because keyboard navigation isn’t component logic. It’s application infrastructure.
Most Angular applications are solving it at the wrong layer.
The problems don’t show up immediately. They appear gradually as your application grows in complexity.
As layouts become reusable, state becomes dynamic, and different parts of the UI need to coordinate with one another. Focus starts behaving inconsistently. Keybindings become duplicated. Edge cases multiply. And what once felt simple quietly turns into fragile coordination logic scattered across your components.
The Real Problem: Focus Is Global State
At its core, the issue is not about arrow keys or event handlers. It’s about state. Only one element can be focused at a time.
Navigation depends on where you are now.
Boundaries matter.
Direction matters.
Rendering may be asynchronous.
The DOM can change underneath you.
That’s not local behaviour. That’s global state.
@HostListener('keydown', ['$event'])
onKeydown(e: KeyboardEvent) {
if (e.key === 'ArrowDown') {
// move focus
}
}
This pattern assumes that focus is a local concern. It isn’t. Focus is shared across your entire application, which means modelling it locally is where the cracks begin to appear.
This is usually the point where devs try to "improve" their keyboard handling.
They centralise listeners.
Introduce shared services.
Experiment with CDK utilities.
Layer abstractions on top of abstractions.
The intent is good, but most of these solutions are still built on the same assumption — that focus can be modelled locally and coordinated later.
Why Common Approaches Break Down
Once focus is treated as local behaviour, every solution is working uphill. Over time, most Angular applications adopt variations of the same approaches. I’ve implemented all of them myself.
They solve pieces of the problem — but not the whole.
None of them establish a coherent, application-wide model for focus.
And that’s where the strain starts to show.
HostListeners Everywhere
Each component handles its own key events. It starts simple: listen for keydown, check the key, move focus. But as soon as navigation crosses component boundaries, logic becomes duplicated, behaviour drifts, keybindings are hard-coded in multiple places, and testing global navigation becomes difficult. It works until coordination between components becomes necessary.
Global document Key Listeners
To reduce duplication, devs often move keyboard handling to the document level which feels cleaner at first. But focus context becomes implicit, boundary rules harder to deal with and coupling becomes hidden rather than removed. Centralising event handling is not the same as centralising state.
Angular CDK Focus Utilities
Angular CDK provides excellent utilities such as FocusKeyManager. They are powerful within a single component, but they are not intended to orchestrate focus across multiple component trees, mixed layout structures, or global shortcut scopes. They solve component level focus well, but they stop at component boundaries.
Toolkit-Specific Keyboard Behaviour
UI libraries provide built-in keyboard behaviour. That’s useful, until your application mixes toolkits or introduces custom components. Each toolkit optimises for its own components, but your application needs consistency across everything. The more toolkits you combine, the more fragmented focus behaviour becomes.
None of these approaches are fundamentally flawed. They simply assume that focus can be managed locally and coordinated later. In practice, that assumption is where the cracks start to appear.
The Missing Insight
The issue isn’t that we lack better event handlers.
It’s that we’re modelling the wrong thing.
Keyboard navigation is usually treated as a reaction to key presses — a series of conditionals responding to events.
But focus isn’t an event.
It’s state.
And state needs a model.
Once you recognise that focus is shared application state, the question changes.
Instead of asking:
What should happen when ArrowDown is pressed inside this component?
You ask:
What is currently focused — and what is the next valid focus target?
That shift is subtle, but it’s architectural.
Navigation stops being a collection of event handlers and becomes a system of state transitions.
And state transitions can be determined, constrained, configured, and composed.
Components stop orchestrating focus themselves.
They participate in a broader model.
Where This Starts to Break
Consider something simple.
You switch tabs and immediately try to focus a field inside the newly activated panel.
Or you navigate to a route and attempt to set focus to a specific control.
Or a shortcut triggers navigation and should land on a precise target.
In many applications, this works most of the time.
Until it doesn’t.
The focus call runs before the element exists.
Or before Angular has finished rendering.
Or before change detection has stabilised.
And suddenly, focus is lost.
Not because the code is incorrect, but because the model assumes immediacy.
Most keyboard systems treat element.focus() as a guarantee.
In modern applications, it isn’t.
The Focus Acknowledge Pattern
The breakthrough was separating intent from confirmation.
Instead of assuming focus happens immediately, treat it as a managed transition.
First, the system expresses an intent to focus a specific target.
Then, when that target becomes available, it acknowledges the focus.
Only then is the transition considered complete.
This small shift changes the model.
Focus is no longer a hopeful DOM call.
It becomes an explicit state transition.
This pattern survives async rendering, handles lazy-loaded content, prevents race conditions, avoids lost focus, and works across component boundaries.
It treats focus like state not like a side effect.
Many focus systems struggle here, not because they are poorly written, but because their model assumes immediacy.
Once you separate intent from acknowledgement, the system becomes resilient.
Introducing Focusly
After implementing this model repeatedly across real applications, it became clear that this wasn’t just a technique.
It was a missing layer.
That’s what led me to build Focusly.
Focusly is an Angular library that models focus explicitly.
It treats focus as shared state, navigation as directional transition, and key handling as configuration — not component logic.
Instead of wiring listeners and coordinating focus manually, components simply declare their position within a navigation context.
Focus orchestration lives where it belongs: at the application layer.
A Minimal Example
<div>
<button focusly [focuslyRow]="0" [focuslyColumn]="0">Save</button>
<button focusly [focuslyRow]="0" [focuslyColumn]="1">Cancel</button>
</div>
No key listeners.
No manual focus coordination.
The layout is declared.
The engine handles navigation.
Explore Further
If this way of thinking about focus resonates with you, you can explore the project here:
GitHub Pages: https://mad-vx.github.io/focusly/]
GitHub: [https://github.com/mad-vx/focusly]
Live Demo: [https://mad-vx.github.io/focusly/focusly-demo/browser/]
StackBlitz Live Demo: [https://stackblitz.com/edit/focusly-demo]
Documentation: [https://mad-vx.github.io/focusly/focusly-docs/]
I’d love to hear how you’re currently handling keyboard navigation in your Angular applications and whether this architectural shift feels useful in your context.
Top comments (0)