This is doing little more than providing a wrapper around svgo, which is doing all the real work.<p>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.
Let's not forget, sometimes when you need some really basic functionality, you don't <i>have</i> 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:<p><a href="https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d97d" rel="nofollow">https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d...</a><p>Despite it's simplicity, it has yet to fail me.
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?)
Doesn't `react-svg-loader`[0] do the same?<p>[0] <a href="https://github.com/boopathi/react-svg-loader" rel="nofollow">https://github.com/boopathi/react-svg-loader</a>
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).<p>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.
<a href="https://gitlab.com/gjjones/svg-to-react" rel="nofollow">https://gitlab.com/gjjones/svg-to-react</a>