-
Notifications
You must be signed in to change notification settings - Fork 148
Considering declarative focus #85
Comments
What about separating focus/navigation from the renderer and only handling adding and removing focusable children in a tree data structure passed to the renderer? |
I like this idea. I personally do not like the navigation being at the renderer level.
I'm drafting some interfaces for it. Any idea? |
To simplify stuff I use context in React to pass down the parent focusKey to its children right now and compute a new value representing the absolute path like /app/menu/0, having a nested structur of focusable components from app to menu to menu item 0. Focus path is also passed via context down to every focusable child and on update when focus path changes entered/focused states are computed and passed to the wrapped component. To decide if the component was entered/focused you can then just compare paths, focused being a perfect match and entered being a partial match from beginning. Would be nice to get rid of context and do updating entered/focused states of focusable elements somehow in the rendering itself. |
Navigation separated from renderer and become a single package. I'll close this issue, any other enhancement or update, will make more sense open on https://github.com/react-tv/react-tv-navigation. |
Have you considered doing declarative focus handling like Netflix devs explained here
https://medium.com/netflix-techblog/pass-the-remote-user-input-on-tv-devices-923f6920c9a8
I like the approach that you define a focusKey for every focusable element and use a focusPath to define what should be focused. Rendering and focusing are decoupled and you can request focus after mounting and apply the focusPath to you elements. They use HOCs to set states like entered/focused based on the focusPath and the focusKey of the element and removed using element.focus().
The text was updated successfully, but these errors were encountered: