Bringing the Scene to Life with Navix Lifecycle

What happens when Navix's component library goes beyond navigation? In this post we start from the demo app and look at how lifecycle events give components a life of their own — questions are mine, answers belong to Claude reading only the source code.

In Navix, every component manages its participation in the focus tree and its focus state through a handful of lifecycle events: onRegister, onUnregister, onFocus, onBlurred. They may look like ordinary callbacks, but looking at how the demo uses them changes the picture.

MediaCard is the clearest example. The moment onRegister fires — meaning the card enters the visible area — a caching simulation begins. The card is not yet focused, the user isn't there; but content is quietly being prepared. When onFocus arrives, if the cache is ready playback starts immediately; if not, it drops into a pending state and kicks in once the cache completes. When onBlurred arrives, playback stops. When onUnregister fires — meaning the card leaves the visible area — all timers are cleared and state resets.

All of this works without any external coordinator. NavixPaginatedList only renders cards and registers them in the focus tree; it has no knowledge of what's happening inside them. Each card manages its own lifecycle.

The core lifecycle events are onRegister, onUnregister, onFocus, onBlurred, and onEvent. Combined with props like focusOnRegister and disabled, they open up quite a wide space.

onEvent is the most flexible. Every key press first reaches the deepest focused node; if that node returns true, the event is considered consumed and doesn't bubble up. This lets any component intercept whichever key it wants, run its own logic, and leave the rest to the tree.

focusOnRegister is a small but practical prop. The moment a component registers in the tree, it pulls focus to itself. Instead of manually managing where the first focus lands in a modal or newly opened screen, this prop is enough.

disabled is not just a visual flag. It's tied to the canReceiveFocus mechanism; a disabled node cannot receive focus, and focusNext and focusPrev automatically skip it.

Where's the limit? Lifecycle events operate at the component level; there's no central event listener spanning multiple components. For one component to directly track another's focus state, they need to communicate through a shared parent. This is an intentional design decision: each component carries its own responsibility, the tree coordinates the whole.

At first we tried controlling events from outside — tracking which card was visible from the parent component and passing it down as a prop seemed reasonable. But as the demo grew, this approach became messy with every new feature. Eventually it became clear that caching and playback responsibility needed to stay entirely inside the card. onRegister took ownership of entering the visible area, onFocus of focusing, onBlurred and onUnregister of cleanup. Only one thing needed to be coordinated externally: the card says what it wants, how that's fulfilled is no longer the card's concern.

The component's lifecycle events only communicate the request; determining how the request is fulfilled is the application's responsibility. In a real scenario a central manager steps in: this layer decides how many items can be cached simultaneously and which get priority. The component reports its cache request to the manager on onRegister, passes its playback request on onFocus, and cancels on onUnregister. The manager then queues these requests with the device's resources in mind. This way, while components keep the scene alive, how much load builds up in the background stays under control.