I have been deep in the rabbit hole creating custom components that are native bridges. On some controls I have new style definitions. I want the adopters of the components to use them like first class citizens and not end up in proptype hell.
The last hurdle I have (everything works great with exception to this) is StyleSheet.create(). I have found no way to register the new style property types with StyleSheet. It also appears that if there was a way, it would introduce a race condition. If a style was imported before the component was it would fail.
What are your thoughts on the introduction of vendor prefixes. StyleSheet would skip validation of any prefixed property. To illustrate:
React View:
let styles = StyleSheet.create({
body: {
flex: 1,
backgroundColor: '#fff'
}
});
Cinecove View:
let styles = StyleSheet.create({
body: {
flex: 1,
backgroundColor: '#fff', // used if thrown in to a react view
'-cine-backgroundColor': 'linear-gradient(to bottom right, red, rgba(0,0,0,0))'
}
});
In the above example StyleSheet would skip validation of '-cine-backgroundColor' and that style would be ignored by any component not understanding it. Working just like vendor prefixes in the browsers. It allows for these properties to be stored where they belong, in the stylesheet... because this is just a bad experience:
render() {
let { '-cine-backgroundColor' as bg, ...otherStyles } = styles.body;
return (
<CineView styles={{...otherStyle}} backgroundColor={{bg}} />
);
}
This is already working (it's just StyleSheet that is in the way)
render() {
return (
<CineView styles={{ flex: 1, backgroundColor: '#fff', '-cine-backgroundColor': 'linear-gradient(to bottom right, red, rgba(0,0,0,0))' }} />
);
}
Any suggestions, comments? Really would like to see this or another solution happen here. Willing to add it myself to the framework.
Thanks
Another alternative I can think of is to defer style validation after modules initialization using something like setImmediate this way you can register the custom style props with StyleSheetValidation.addValidStylePropTypes and it would avoid the require order race condition. This also allow validating your custom style props.
cc @vjeux @brentvatne
The style vs props is super confusing and our stance so far has been: if it is exists in the CSS spec then put it in style otherwise make a prop.
In your case this is tricky because this is a CSS style but you want to implement it as a custom extension and it's not part of the core API. We haven't really figured out a good way to solve this problem unfortunately :(
agree and it's why I thought of vendor extensions. By allowing them and ignoring them it:
StyleSheetValidation.addValidStylePropTypes could because the developer could attempt to overwrite an existing style.-react- could be reserved.StyleSheet in favor of something like react-native-extended-stylesheetI really feel it's important that developers are able to use 3rd party components in the same manner they use native ones. If someone adds some non-css variant, let the community chastise them rather than closing it off completely.
I think the solution I'd prefer to see here to the specific example given is to add support for linear-gradient to the backgroundColor style of View, rather than create a vendor prefix to get around it not existing currently.
As for the general issue of vendor prefixes, I think they are useful in a world where multiple platforms implement the same property slightly differently while experimenting, in order to give the app developer a way to ensure they can get the behaviour they want on each platform despite different APIs / behaviours. I don't think this is really the case for React Native, and if it is, we should change the properties behave the same, and we can do it at a faster pace than web browsers.
So, I'm not personally in favour of adding vendor prefixes to React Native. As a side note, If we were to do it, I think that rather than using the -vendor-prefix we should make it play more nicely as a JS object key, so propertyNameVendor (eg: somePropIOS, consistent with what is already done for components) or vendorPropertyName.
I'm not against adding support for new styles, though -- @janicduplessis' suggestion should work. With this, you could name the styles whatever you want, so if you'd like to do vendor prefixes then that is possible. What do you think @victoriafrench?
@facebook-github-bot label Icebox
Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/request-for-comment-stylesheet-vendor-prefix
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.
@facebook-github-bot close
@charpeni tells me to close this issue. If you think it should still be opened let us know why.
Most helpful comment
I think the solution I'd prefer to see here to the specific example given is to add support for
linear-gradientto thebackgroundColorstyle ofView, rather than create a vendor prefix to get around it not existing currently.As for the general issue of vendor prefixes, I think they are useful in a world where multiple platforms implement the same property slightly differently while experimenting, in order to give the app developer a way to ensure they can get the behaviour they want on each platform despite different APIs / behaviours. I don't think this is really the case for React Native, and if it is, we should change the properties behave the same, and we can do it at a faster pace than web browsers.
So, I'm not personally in favour of adding vendor prefixes to React Native. As a side note, If we were to do it, I think that rather than using the
-vendor-prefix we should make it play more nicely as a JS object key, sopropertyNameVendor(eg:somePropIOS, consistent with what is already done for components) orvendorPropertyName.I'm not against adding support for new styles, though -- @janicduplessis' suggestion should work. With this, you could name the styles whatever you want, so if you'd like to do vendor prefixes then that is possible. What do you think @victoriafrench?