Smart TV Navigation with React

This requires to create another nested level in JSX, as well as introducing this wrapper in render functions. Another way is to use HOC (higher order component):

We went with the second one and we are using recompose to create the HOC.

So now when we have a focusable component, what is the minimal functionality that this component needs to be enhanced with?

First of all it needs to have a focused state to indicate when it is focused. Also each focusable component needs to have some focusKey to identify it. In order to navigate between focusable components, something needs to store global state of the current focused component on the screen. We didn’t want to have any navigation logic inside the components. Each focusable component needs to be registered in come global system and report it’s own coordinates on mount. As well as delete itself from this system on unmount. So the next step is to create the global system or service to keep the list of all focusable components and manage the state of current focused component.

Centralized Navigation Logic

Spatial Navigation service is keeping the focus key of currently focused component. It also serves as a Storage for all focused components on the screen. Since we are not handling any navigation logic in the components, this logic is implemented in the Service (centralized). The navigation logic itself is quite straightforward. When user presses the directional key, Spatial Navigation Service is trying to find the best candidate to be focused next in that direction, based on the shortest distance between the currently focused item and potential target item. The algorithm itself is quite advanced and inspired by this implementation.

The Service also provides an interface for any focusable component to imperatively set focus to any other component, or onto itself.

Each focused component needs to be connected to the Service. It might be done either via React Context API or by passing some kind of reference of the component to the Service. Initially we implemented it with the Context, e.g. wrapping the whole App into another HOC that served as the Context Provider:

Each component was subscribed to the Context and whenever the current focus key is changed, each focusable component compares the new focused key with its own focus key to determine if it’s focused now. This approach didn’t work well for us, because each focusable HOC on the screen needs to re-render in response to Context update. It doesn’t mean that each wrapped component needs to re-render though, if the focused state didn’t change for it. However on low-end devices it caused performance issues, because React tree reconciliation caused by HOC updates still takes time. In the end we went with more imperative approach. Instead of Context, the Spatial Navigation Service gets access to each component’s state handlers (created by withStateHandlers recompose HOC), for example onUpdateFocus. When focusable component is mounted, it passes the reference to this handler to the Service. This way we ensure that only two components will be updated at a time: the one that got new focus, and the one that lost focus:

Focusable Tree

Even though each focusable component reports its own dimensions and position on the screen, the UI on the screen is not linear, it has certain hierarchy. We can have focusable elements inside scrolling lists or other wrappers/containers, so relying only on the global coordinates on the screen to measure the distance is not enough:

Menu item focus based on shortest distance by global coordinates

In this case when we try to navigate to the left, the next element according to the global coordinated is one of the menu items, but the expected would be to focus the next left element in the scrolling row, which is out of the screen (marked with dashed border).

In order to improve this, we have to structure our UI into a Focusable Tree. We can make scrollable lists as focusable components, or even the whole page. In the example above we can make Menu as focusable (green border) as well as the scrollable list (blue border).

If we restrict the directional logic to prioritise sibling components first, the system will focus the next item in the scrollable list (so we can scroll to it afterwards):

Next left item gets focused based on the distance inside parent wrapper

But what if there is no good candidates to be focused amongst siblings anymore? This can be solved via delegation of the directional action to the parent focusable component:

Left navigation gets delegated to the scrollable list (blue border) and then performed from its edge to the closest sibling, which is the Menu (green border)

In this scenario the system attempts to focus the sibling element to the left, but there is none. It delegates the “left” action to the parent list component, which then attempts to focus its sibling to the left, which is the Menu.

But focusing the Menu itself is not really enough. Intuitively we expect it to focus some Menu Item. This is done via down-tree propagation:

 

Menu that got focused in the previous example automatically propagates focus to the first child item

Even though it sounds complicated with the up-tree and down-tree propagation, you don’t have to worry about it since this is all done automagically by the Service.

Putting all together

 

Here is an example of a simple implementation with the Menu, Menu Items and Scrollable List with Items inside:

 

 

Example of Directional navigation with up-tree and down-tree focus delegation

Debugging

In the real world scenario something might go wrong, the focus might jump somewhere where you don’t expect it to jump, or disappear for some reason etc. To make it easy for you to understand what’s happening we have implemented two debug modes: