
Transform SVG into React components - BafS
https://github.com/smooth-code/svgr
======
iamleppert
This is doing little more than providing a wrapper around svgo, which is doing
all the real work.

This is generally a poor use of SVG as well, if your use of SVG is for static
assets, don't transform all your SVG into react, leave it as SVG where it can
be easily manipulated and editing by the plethora of tools that can work
directly with SVG, previewed in the browser, etc. If you need you can inline
the SVG into your CSS via a base64 URI, etc.

~~~
oelmekki
I love adding my svg as react components, actually. It makes it easy to
conditionally toggle parts of it, change text, manage colors, etc.

Of course, if you just want to use the svg doc as a static icon, then yes by
all mean, a plain file will do. But given the (very small) size of a svg file,
caching it as a single resource may not be that useful.

~~~
iamleppert
Umm, you should be doing that with CSS. Basically what this means is whenever
your application code changes, it busts the cache on all your SVG assets if
you use this method.

The only use-case for using SVG with something like react is for data
visualization where you are programmatically building up and updating a SVG
DOM based on some data.

A good example of this is a flow-chart graph/tree UI done in SVG that is
generated from a nested data structure. Its unlikely these elements would be
expressed as static assets in the first place.

Even still I would be cautious in using SVG in this way for all but the least
trivial things, as react has been optimized to diff HTML structures, not SVG.
I'd like to see, for example, how it handles SVG cascade transforms for
instance. Its usually not efficient to alter the SVG DOM by inserting/removing
nodes, because the layout rules and semantics of SVG is different than HTML.

------
debaserab2
Let's not forget, sometimes when you need some really basic functionality, you
don't _have_ to reach for a module that maybe does a lot more than what you
need. For example, the last time I needed svg inlined into a web app I was
working on, this is the quick component that I whipped up:

[https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d...](https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d97d)

Despite it's simplicity, it has yet to fail me.

~~~
hex13
besides - if you generate your SVG programmatically you can just return them
in your render function:

function Foo(props) { return <svg> <circle cx="10" cy="10" r="100" /> </svg> }

------
askmike
This does exactly what I have been doing manually for at least ~15 times in
the last week. If only I saw this a few weeks ago.. (It's easy / not lot of
work, but why if we can automate?)

------
photonios
Doesn't `react-svg-loader`[0] do the same?

[0] [https://github.com/boopathi/react-svg-
loader](https://github.com/boopathi/react-svg-loader)

~~~
Klonoar
I'd done this awhile ago with [https://github.com/ryanmcgrath/react-
iconpack](https://github.com/ryanmcgrath/react-iconpack) (haven't touched it
in literally forever, at least insofar as time is considered in the JavaScript
world - probably doesn't work now), too. Never caught on for whatever reason,
but was fun to hack together.

I do feel like (and I think another commenter somewhere in here noted this)
that actually fully converting SVGs to JS has a lot of detriments in terms of
ability to edit and such, so the loader approach is better.

~~~
photonios
Another approach which I use at work is to use `postcss-inline-svg`[0]. This
allows you to "import' the SVG from your CSS and then customize it. For
example, you might want the icon in a different color:

    
    
        background: svg-load('myicon.svg', fill=blue);
    

The SVG would then be inlined into the CSS instead of the HTML.

[0] [https://github.com/TrySound/postcss-inline-
svg](https://github.com/TrySound/postcss-inline-svg)

------
leeoniya
"Your scientists were so preoccupied with whether or not they could, they
didn’t stop to think if they should."

------
gjjones
Super cool to see other people using this pattern! People here are bringing up
great points about the implications of this pattern. Our motivation to use
this pattern was when replacing grunticon generating multiple colors of our
SVGs during a build step. The grunticon step added a 1min+ to the feedback
loop on seeing CSS changes(could have fixed this directly, lots of missed
details in this story).

This simple script allowed us to quickly move past the problem during a
rewrite to React, and solve more correctly when that system was a priority.
[https://gitlab.com/gjjones/svg-to-react](https://gitlab.com/gjjones/svg-to-
react)

------
josteink
If I can have only one question, it would no doubt be “why”?

~~~
abritinthebay
We do this at my work - it allows easy programmatic inclusion.

We wouldn’t do it if browsers weren’t a buggy mess with the USE tag though
(Chrome in particular is a dumpster fire of SVG bugs).

~~~
tehno
Yeah, USE tag is pretty buggy across browsers.

Also, sometime you just need to inline SVG, for example if you want some icon
path fill color to change on mouse-over. Easy with inline SVG and CSS rule.
Can't really do that (well) with external .svg.

~~~
abritinthebay
We actually had a nice system for that... but again: browser bugs :(

Until browsers collectively get off their asses with SVG (most of these bugs
are _years_ old in their big trackers) using React for SVGs is a good
workaround.

~~~
Already__Taken
They won't because it seems like they might as well forge ahead with CSS
additions and drop an entirely separate renderer. That's what happened to the
SVG Animations.

Of course it's not like svg will get removed so Why fight it...

~~~
abritinthebay
It seems they stop work as soon as a feature hits SVG - CSS Animation, Canvas,
WebGL... all have open SVG bugs. Some years old.

------
peterchau
Amazing.

~~~
avitzurel
HN is really aware of these type of comments. An account created 47 minutes
ago. A single comment on this post.

