Skip to content
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

Bug: renderToStaticMarkup throw warning about SVG PascalCase and camelCase naming #18258

Closed
BiosBoy opened this issue Mar 9, 2020 · 9 comments

Comments

@BiosBoy
Copy link

BiosBoy commented Mar 9, 2020

React version: 16.12.0

Error: Warning: <linearGradient /> is using incorrect casing. Use PascalCase for React components, or lowercase for HTML elements.

The current behavior

Any SVG-inside node(LinearGradient, feDropShadow, etc), that should be in PascalCase/camelCase inside HTML indeed, throw me a warning above through React's import { renderToStaticMarkup } from 'react-dom/server' renderToStaticMarkup method.

I use renderToStaticMarkup to parse and then insert its DOM inside global HTML (don't ask me why :) ) on client-side, not SSR.

The expected behavior

Should not throw any warnings and render SVG-in tags in PascalCase without any efforts and tears in fact.

Thanks.

P.S.
I saw this report, but it seems like it doesn't fix for some reason #10415 ...

@BiosBoy BiosBoy added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Mar 9, 2020
@threepointone
Copy link
Contributor

could you make a codesanbox version or a git repo that demonstrates this issue?

@BiosBoy
Copy link
Author

BiosBoy commented Mar 10, 2020

@threepointone hi!

Here you go https://codesandbox.io/s/reactsvgtestapp-sh7b.

Well, it works in a bit different way on codesandbox, but the error can be spotted anyway. Just on the page load please open the console directly in the browser (instead integrated one) and reload the page.

So you will found the error about inconsistent SVG nodes naming on the first render like on the screenshot below: https://imgur.com/a/C9MpF3Y. The funny think on the codesandbox it disappears on the second rerender, which doesn't make a trick inside my project.

Thanks.

@BiosBoy
Copy link
Author

BiosBoy commented Mar 10, 2020

So that console error thrown when we try to insert the < linearGradient /> or < feDropShadow /> or so on tag not in the <svg /> directly, but in inside one of the deepens of its tree nodes. Like:

  const shadow = (
    <feDropShadow {...} />
  ) 

  const testFilter = (
     <filter {...}>
       {shadow}
     <filter />
  )

  document.querySelector('.svg > defs') += renderToStaticMarkup(testFilter) // error in the console!

@dfltr
Copy link

dfltr commented Mar 17, 2020

I had a quick look at this one, and as far as I can tell the error is being thrown because getIntrinsicNamespace() tests specifically for an <svg> tag at the top level, so an orphaned <linearGradient> (or any other camelCase SVG child) is assumed to be in the HTML namespace. Because it's assumed to be in the HTML namespace, it fails the naming convention test for HTML elements, hence the error.

The test could be expanded to cover the 32 valid SVG child tags that have camelCase names, which would make getIntrinsicNamespace ~653 bytes longer, but that would also result in lowercase SVG children, hyphenated children, and camelCase children all going through slightly different code paths for validation.

I'm still new around here so I'm not sure what the general policy is on balancing edge cases vs. library size vs. consistency so let me know.

@BiosBoy
Copy link
Author

BiosBoy commented Mar 30, 2020

Any updates yet? :(

@rachelnabors
Copy link

This is currently unsupported. SVG is its own spec with its own DOM. Lumping its SVG DOM elements with HTML DOM elements is problematic in a number of ways.

A workaround would be to wrap your element in <svg> and then extract it from the output. Hope that helps!

@BiosBoy
Copy link
Author

BiosBoy commented Jul 19, 2020

Hmm, let me check this possibility...

@rachelnabors
Copy link

Going to close this because it's unsupported, but if the workaround works, do please share here :)

@BiosBoy
Copy link
Author

BiosBoy commented Nov 11, 2020

A workaround would be to wrap your element in and then extract it from the output. Hope that helps!

Seems like this is a truly workaround for now. Worked for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants