4 ms·
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 S
by iamleppert 9y ago
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.
- TheCoreh 9y agoIdeally this is applied as a webpack transform, so the asset is left as SVG, and only converted during the build process. Inlining the SVG as Base 64 in CSS is not that good, since it limits what you can do with it (basically setting it as a background). If you create an actual SVG tag within HTML (via React) you can then use CSS to style the strokes, fills, etc.
- rpastuszak 9y agoBase64-encoded SVGs have a terrible impact on performance on mobile, so I'd be careful with that. Saying that, the situation has improved in the past few years (mostly because of hardware, not browser optimisations afair)
- oelmekki 9y agoI 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.
- andreasklinger 9y agoagree most people who do inline styles (or any form of "my styling is written in the react file") do this afair we inline for the same reason i hope someone writes a good precompiler that allows efficient using def/use for (non changed) static inlining http://www.svgbasics.com/defs.html http://www.svgbasics.com/defs.html
- iamleppert 9y agoUmm, 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.
- deleted 9y ago[deleted]
- Sir_Cmpwn 9y ago>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. As valid as this seems on the surface, why can't transforming SVG into React be a build step where React is an intermediate artifact?
- tracker1 9y agoThe webpack option for this seems ideal for that even... I'd be far more interested in that than pre-transform steps.