Is your feature request related to a problem? Please describe.
Pressable does not expose onHover* callback props. Those are useful to enable richer web experience.
For example <select> allows you to highlight an option with either hover or keyboard arrow up/down. In order to replicate that behavior with a custom component, one would maintain an activeIndex of the highlight item. In pseudocode:
Component {
activeIndex = 0
onKeyboardUp = () => activeIndex -= 1
onKeyboardDown = () => activeIndex += 1
onHoverItem = (index) => activeIndex = index
return options.map(option => <Pressable onHover={onHoverItem} />)
}
See the desired behavior in react-select where both mouse and keyboard can highlight the items. (cursor disappears when the highlighted items are changed with keyboard arrow keys)

Describe a solution you'd like
Expose onHoverChange or all onHover* callbacks from Pressable.
I would like to submit a PR for this feature, if you greenlight it.
This feature adds more props, and thus weight to Pressable API, so I will understand if you reject this feature.
Describe alternatives you've considered
In the example above, have the children call onHoverItem when they receive hovered prop. This is a little bit awkward. In pseudocode:
<Pressable>
{({ hovered }) => {
useEffect(() => {
onHoverItem(index)
}, [hovered])
return <Item />
}}
</Pressable>
Alternatively, wrap Pressable with <Hoverable> component from Web Recipes
Additional context
N/A
Another issue I faced using onMouseEnter & onMouseLeave for handling the hover state on a autocomplete component like yours :
The cursor disappear because you type on an input, but it's still at the place where you leave it.
And if you want to manually handle a scroll on your item list to follow the activeIndex item in the scrolling list. The cursor will trigger onMouseLeave on the item where the cursor is (and onMouseEnter on the new item under your invisible cursor).
For now my workaround is to use an onMouseMove instead, but it's not good I think…
Having thought through this, i no longer believe this would be right idea.
Exposing hover callbacks is only a nice-to-have API. The use case described in the issue, can already be achieved in user land code. Straying off further from react-native's API unnecessarily adds more maintenance burden to this library.
The use case described in the issue, can already be achieved in user land code.
Not without reimplementing the entire hover behavior. These callbacks probably will be added to Pressable as RN Windows needs the same functionality.
I have what I think is a better API for behaviors but it deviates significantly from the RN API and there would need to be work on the RN side to implement native equivalents. That's not going to happen for some time yet
There is other use cases where the RN api has some limits with keyboard+mouse scenarios.
But as you say, I hope it will be discuss because of RN Windows, but those scenarios affect more directly the RN project considering iPadOS with the magic keyboard (that include a trackpad) and all hoverable buttons.
Most helpful comment
Not without reimplementing the entire hover behavior. These callbacks probably will be added to Pressable as RN Windows needs the same functionality.
I have what I think is a better API for behaviors but it deviates significantly from the RN API and there would need to be work on the RN side to implement native equivalents. That's not going to happen for some time yet