-
Notifications
You must be signed in to change notification settings - Fork 794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using dash-case attributes in JSX #1374
Comments
Agreed. In fact, it seems that a lot of camelcase attributes don't work at all. I thought I could make use of a React SVG to JSX converter, but found that the camelCasing of attributes like |
The typescript does not support name spaced attribute syntax currently: microsoft/TypeScript#7411 A better way is to write a preprocessor to do that. such as like markdown. return (```pug
svg
use(xlink:href="....")
```)
return ```xhtml
<svg><use xlink:href="..."/></svg>
``` ` |
Thank you for opening the issue. However, at this time we've decided to not implement this feature. If more requests are made we'll reevaluate then. Thanks. |
Stencil version:
I'm submitting a:
[x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://stencil-worldwide.herokuapp.com/ or https://forum.ionicframework.com/
Current behavior:
If you're supposed to use camelCase on attributes in JSX, why does dash-format work almost all of the time? We built an entire demo site for our components using other components. The demoed components are output in their render methods via JSX. But we've been using dash-format for those attributes all along and it worked fine (actually copied from some static HTML demo pages way back). But there's one case where things do not work:
If you just use a one-word prop/attribute or no camelCase in the prop, everything works as expected as far as the prop assignment goes.
Expected behavior:
If you're going to still support dash-format for attributes in JSX, then this should still work, as every other case seems to. This would be nice so we don't have to demo two different scenarios for usage in our component docs.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: