Pressable: focus-visible support

[Rhysjc]

Is your feature request related to a problem? Please describe.

Pressable focus styles are applied when the element is focused with a mouse. This is not the UX we usually want in web apps and CSS :focus-visible will allow focus styles to be applied only when the element should be visually focused, e.g., after keyboard interaction.

Describe a solution you'd like

An additional state field focusVisible to be forwarded to Pressable children and styles

<Pressable
  style={
    ({ focusVisible }) => [ focusVisible && styles.focused ]
  }
/>

[necolas]

Not at the moment

[Rhysjc]

Is there any way to override the default :focus-visible style that gets applied?

[walidvb]

@Rhysjc I have a stylesheet to reset some styles to what i want. To do that, I added a folder with an empty index.native.js and a index.web.js which only contains require('./globals.css')

Hope this helps!

[Freddy03h]

Hi! I'm curious about the possible paths. What are you planning for the focus-visible scenario?

Do you plan to mimic the browser :focus-visible in Pressable ? (I don't know if it's possible to detect if the focus came from mouse or keyboard btw). And, if it's doable, do you think Pressable should only keep the focused state and react according to the new behavior or do you plan to add a new state focusedVisible ?

Thank you.

[necolas]

focus-visible would also needed for elements other than Pressable. If we added props like onVisibleFocus and onVisibleBlur, or onFocusVisibleChange, then in principle every element could use this behavior. My preference would be to have a hook useFocusVisibility that can be used with any element, but that would alter the exports API and there is still some concern internally about whether React Native could implement a hook like this.

I think web and windows/macos have a similar problem, which is that the RN API design itself is problematic. We have to either alter core APIs or create new core APIs, then figure out if RN will be able to adopt them, or deal with inconsistencies in the future if RN adds a similar API without awareness of the APIs we already added in the forks. My preference is for behavior to be added via hooks, which means core prop APIs don't need to be extended and users don't have to juggle inconsistent type interfaces. But there's no progress internally yet, so I'm not sure how to proceed here.

[Freddy03h]

Very instructive answer, thank you!

Do you know where we can follow those type of discussions ? Or simply know if they're publicly available? I try to watch discussions on react-native-community/discussions-and-proposals but I don't see nothing about hovered and focused state on react-native.

This discussion about Handling platform specific properties opened by react-native-windows match what you're saying about RN API design.

Many of the wanted API discussed on this issue are manly related to Mouse and Keyboard inputs. For now this need doesn't exist on react-native-(ios/android) but with iPad and the keyboard, it should be. Currently, there is no hovered on react-native but I hope it will coming, and will match what you've done on Pressable in react-native-web.

Also, do you know if there is a plan to 'extract' RN API design decisions from react-native itself? react-native-ios and react-native-android should be at the same consideration level than web, windows and macos. And maybe, find a name for this API+Component design other than react-native?

I say that because it's still confusing to explain what is react-native-web to many developers, they don't really understand the advantages, other than the way to share code with a react-native mobile app. react-native is to tied to ios and android, they see RN like the equivalent of react-dom, they don't see the API design, so for them it's seem over-engineering (and it's very hard to convince someone once he think it is).

Sorry I'm a little off topic ^^'

When I started RN development, I was feeling that I'm doing web development, in a browser just invented, without legacy concern. And those discussions about platforms and implementations make me thinking that it should be the decision of a kind of react-native consortium, like W3C …

[necolas]

I agree but nothing is public and there is as yet no commitment internally to resolving these issues

[steida]

@Freddy03h RNfW is: awesome CSS-in-JS, improved "DOM" components, fixed interactions for mobile&touch devices, and a lot more. I would ask them how to solve the "hover on touch" issue, key navigation with a click, etc. RNfW is simply a better API for browsers. It makes sense even without native apps support.