Closed shirakaba closed 2 years ago
Hi,
hmm, to me it looks like you might use older version (or branch) where this is not present. This happens because your wrapped component gets mounted before its withFocusable
HOC is able to call addFocusable
. In order to compensate for this we have a small hack that allows you to set focus on non-existent components here, and then this components will be picked up here after it is mounted. That was the main reason why we decided to allow manual setFocus
on any component even if it doesn't exist or has focusable=false
.
Closing due to inactivity. We have also released a new hook based version of this library here: https://github.com/NoriginMedia/Norigin-Spatial-Navigation
Describe the bug
I have a class component, DismissButton, which needs to steal focus as soon as it mounts. The use-case is an error popup that appears and steals the spatial navigation focus to one of its buttons (such as "Dismiss" or "Retry"). Here is how I've written it:
As you can see, DismissButton has its own
componentDidMount()
method in which it callsthis.props.stealFocus()
, but at this moment, it appears that DismissButton has not been registered infocusableComponents
. Registration (byaddFocusable()
) happens only during thecomponentDidMount()
lifecycle method added to the DismissButtonFocusable HOC by therecompose
library.To my understanding, DismissButton mounts before the HOC, and thus the order is:
If I wrap
DismissButton.componentDidMount()
's call tosetFocus()
in a timeout, then it succeeds.For some reason, there is no such problem in the "Menu" class component in the repo's sample app, though:
https://github.com/NoriginMedia/react-spatial-navigation/blob/master/src/App.js#L145
I'm wondering if I'm missing something.