React-native-web: Custom props not being passed to react components

[th317erd]

The problem
Custom props are not being passed to "native" components. React specifies that any lower-case prop will automatically be passed as an attribute to the DOM. This is not happening in react-native-web. All custom props are being stripped.

How to reproduce
Attempt to pass any all lower-case prop to a "View" or "Text" component (i.e. tooltip="hello")
Simplified test case: Not needed

Steps to reproduce:

1. Attempt to pass a lower-case prop to a component

Expected behavior
Prop should be passed as an attribute to the DOM like it does in React.

Environment (include versions). Did this work in previous versions?

• React Native for Web (version): 0.10.0
• React (version): 16.7.0
• Browser: Google Chrome: 72

[paularmstrong]

Fully custom props are not intended to work. Only those that are part of the react-native API and some necessary whitelisted HTML-only attributes are supported.

[necolas]

You can use setNativeProps as an escape hatch but arbitrary props are not accepted on the elements

[th317erd]

This is a poor decision, and it makes your library less useful. Such support IS part of React, and because it is a supported feature in React such props are just ignored in React Native. You are attempting to do something outside of the support of React and React Native, and it is causing issues. Why?

[necolas]

I'd appreciate it if your comments could avoid accusations and the combative tone. You're talking to me like you think I'm an idiot.

This framework isn't meant to provide all the functionality of the DOM / React DOM. React Native is much stricter in that way. React DOM will print warnings for unknown props added to DOM elements, so what is it that you're expecting?

[th317erd]

@necolas , I am sorry your feelings were hurt. I am not sure why you feel I am attacking you. Maybe assume positive intent next time? I am simply stating some things I feel are facts:

Fact 1: As of React 16, lower-case or unknown prop names ARE passed to the DOM: https://reactjs.org/blog/2017/09/08/dom-attributes-in-react-16.html
Fact 2: React Native DOES NOT complain about these types of props... any prop it doesn't recognize that is all lower-case gets ignored completely by React Native without warnings (I just tested this to confirm, RN 0.58). If the prop isn't all lower-case than you will get a warning.
Fact 3: This behavior _is_ outside of the normal behavior of React and RN
Fact 4: This is useful, custom attributes are used for a lot of good reasons, and removing them altogether limits the usefulness of your library, doesn't align with React or RN, and doesn't align with web standards

Now, I would call that a poor decision. If that is insulting I am sorry, it isn't meant to be. I obviously don't understand all the iterations or why this decision was made, which is why I asked why this was done. If there is a good reason I don't understand, then obviously there is a good reason. I will never know if you just get insulted, all up in a huff, and don't answer my questions.

I am trying to contribute and help with this effort. That won't be very easy, and I won't be very inclined to help out if you always assume every question I ask is coming from a place of bad intent, or that you think I am calling you an idiot. If you wish to continue to infer such negativity from statements I believe to be true, and questions I ask in earnest, then I am not sure there is anything I can do to help you with that. In short: Your attitude, or the attitudes you perceive (born of assumptions) of others in the community who wish in earnest to help out are not my problem. I am just asking a simple question here... and I am still asking. Why was this decision made when React and React Native both don't behave the way you say they do? Is this an attempt to support older versions of React/RN? If so would it be possible to just have a >=16 release of this module? Is there something else I am missing? Could you please work with me to better understand this?

[necolas]

Reflect on how you talk to others. In the meantime…

React Native DOES NOT complain about these types of props... any prop it doesn't recognize that is all lower-case gets ignored completely by React Native without warnings

Are you saying React Native will currently forward those props to the underlying native node?

[th317erd]

@necolas I am not sure I understand your question. They show up in the DOM inspector with react-dev-tools tool (though this probably doesn't mean a lot as this is just a 2nd renderer for React). I also don't understand why this is a concern. They might be needed in the web (i.e. tooltips, data attributes, or other things that are needed for web development, but that don't matter for mobile), and as long as they don't cause harm on the RN side then why not include the functionality? If you are asking if they show up in the native node as in the iOS/Android native nodes across the bridge then I am not sure, and I also don't understand why this would matter.

[th317erd]

@necolas Is this still a no? I have a branch with the change waiting to submit a PR, but I didn't want to submit it until I got a definite answer from you.

[necolas]

Yes, it's a no.

1. We're currently considering strictly typing React Native's components and that would prevent passing of arbitrary props onto View.
2. A lot of React Native components (in core and public) forward all their props to View, because it is currently expected that most of them will be ignored and NOT forwarded to the host element. Allowing arbitrary props to pass through to the DOM would reintroduce the problem of React Native components props ending up in the DOM (e.g., FlatList props like data).
3. The data-* and aria-* props are currently special-cased and allowed through, but this is doable because they are essentially namespaced in a way that arbitrary props are not.
4. If you're using a 3rd party library that needs a prop like tooltip in the DOM, I suggest not using View. The React DOM components can still be used, or the unstable createElement API in this library which does not place restrictions on props.