The Silent Engine Behind Remote-Driven Interfaces: Navix

In this interview, the questions are mine, the answers belong to Claude. Claude examined the project by reading only the source code, without any documentation. We shaped the resulting knowledge together.

Navix is a navigation library built for screens operated by remote control — TVs, set-top boxes, and similar devices. It has two separate implementations for React and Flutter, both built on the same core idea.

The fundamental problem is this: touch or mouse-driven navigation comes built-in for web and mobile apps. But a smart TV remote has only directional keys, enter, and back. In this environment, you need to manually manage which element is focused, where focus should move when a key is pressed, and which components on screen should be notified of that decision. Navix takes care of all of this.

To do so, it builds a tree structure. Every navigation component joins this tree as a node; the parent-child relationship tracks the layout order of components in the interface. When a key is pressed, the event first reaches the deepest focused node — if that node doesn't handle it, it bubbles up to the parent, then that parent's parent, all the way to the root.

Focus is always on a single active path within the tree. The InputManager layer converts raw keyboard events into platform-independent action names like left, right, enter, back, and play_pause. Input types such as long press and double press are also handled here.

In TV-like interfaces, the first instinct is usually: catch onKeyDown, manage focused state manually. This holds up on small screens, but falls apart the moment you have multiple nested navigation zones. Which component is focused? If there's a list inside a list, who should receive the key event? How do you ensure everything below a modal is closed off from focus? Where should focus go when a component is removed? Solving these in each component separately means repeated code and edge cases that break each other.

Navix binds focus management to the tree structure. Each component only knows what to do within itself; the tree resolves the rest. The practical implications:

• Focus trap works automatically. When a dropdown or video player panel opens, no other node in the tree can receive focus. Instead of implementing this by hand, the library provides it as a default behavior.
• Focus doesn't get lost when a component is removed. The tree automatically moves to the nearest valid sibling or parent.
• Keyboard input is abstracted. Samsung, LG, Apple TV remote keyCodes… all of them are mapped to common names inside InputManager. Application code has no knowledge of the platform.
• Ready-made components: horizontal/vertical list, paginated grid, expandable, dropdown, stepper, scroll, and MultiLayer for video players.
• The same model in React and Flutter. For teams targeting both platforms, the core concepts transfer directly.

Flutter had its own built-in solution. But that solution was fundamentally based on jumping to the next element with tab; where focus would land wasn't always predictable, and unintended jumps were inevitable. Defining a more precise policy was possible, but the cost was dozens of lines of configuration written separately for each component.

In Navix's hierarchical structure, direction is read directly from the structure. When the right key is pressed on the remote, where focus goes is already determined by the node's position in the tree. Decorative elements are excluded from focus, and components like PaginatedList handle navigation across hundreds of items without any extra code.