Closed wmertens closed 7 years ago
@wmertens you want something like this - https://github.com/webpack/style-loader#reference-counted-api?
Yes I suppose that can be used for it.
I just realized that #32 and that refcount API can be implemented in a backwards compatible way by not returning a string id, but an object that returns the id for .toString()
and .valueOf()
, and also has .use()
, .unuse()
and .viewBox
…
Ok, I'm starting to need this, so I'd like your thoughts on the proper approach. This is what I think needs to be done:
<Sprites/>
React component that returns the <svg/>
with all the sprites (instead of using document.write
). Add a query flag useSprites: true
to the loader to enable it.<Sprite id={...}/>
React component that makes a <svg><use .../></svg>
.
noSvg
attribute to just return the <use/>
so it can be used inside <svg/>
..toString()
: returns sprite id.use()
, .unuse()
: to be called from the <Sprite/>
component's constructor
and ...WillUnmount
.Sprite
: pre-bound <Sprite/>
componentSo example usage would be
import {Sprite, Sprites, initSprites} from 'svg-sprite-loader'
import star from './star.svg'
…
const App = () => {
initSprites() // only needed for server side rendering
return (<div>
<Sprite id={star}/><Sprite id={star}/><Sprite id={star}/>
<Sprites/>
</div>)
}
or with the pre-bound Sprite:
import {Sprites, initSprites} from 'svg-sprite-loader'
import {Sprite: Star} from './star.svg'
…
const App = () => {
initSprites() // only needed for server side rendering
return (<div>
<Star/><Star/><Star/>
<Sprites/>
</div>)
}
Thoughts? I realize this is only for React, so maybe the components should be in a separate repo?
With the loader-returns-object approach, the <symbol/>
source can be part of that object, so that it can be passed to <Sprites/>
via .use()
.
That way, any implementation is possible, and the loader is only responsible for creating the symbol from the .svg file.
Continuing the thinking: Make a react-sprite-loader
which exports <Sprites/>
and initSprites()
apart from being a webpack loader, and which expects objects with id
and symbol
(the symbol source as a string) as input.
Tell webpack to chain it with svg-sprite-loader, something like:
{
test: /icons\/.*\.svg/,
loaders: ['react-sprite', 'svg-sprite?object&loadOnly'],
}
and in the code
import {Sprites, initSprites} from 'react-sprite-loader'
import Star from './icons/star.svg'
const Component = (props) => (
<div>
<Star/><Star/><Star/>
</div>
)
const App = (props) => {
initSprites() // only needed for server side rendering
return (
<div>
<Component/>
<Sprites/>
</div>
)
}
So then svg-sprite-loader would only need to return plain objects with id
and symbol
(and viewBox
). The id
could be a hash of the symbol, which would cause de-duplication.
I'd like to @princed answered your question, because I am not good in React. But I fully agree with suggestion to return object (or class instance) from sprite-loader.
Actually we use a bit different approach like described in the very end of the README, so icon component doesn't have to require all the icons.
I don't think we should have something react specific. We'd better have common SSR solution.
And we could use counting API to remove inactive defs from DOM, however it could lead to more complex code due our workarounds.
@princed how does that work? All the icons are required statically, no? And then they all get added to the DOM, even when they are not in use?
@princed @kisenka ping
@wmertens Yes, all the svgs are required statically in components that use icon component. And yes, all the required svgs get added to the DOM, even when they are not in use.
Why does it actually concern you?
And yes, all the required svgs get added to the DOM, even when they are not in use.
This is a concern for me, because it is adding unused elements to the DOM. The projects I work on try to avoid dumping unused data to the DOM to keep the DOM/templates clean and lightweight. Also, in certain situations, SVG's can come with security risks, so in a paranoid world: it's best to limit SVG's to only those you require.
I think that many of the ideas presented by @wmertens are really great, and I think providing a react-specific loader option is a cool idea, or breaking the react-ready component out to it's own repo.
And we could use counting API to remove inactive defs from DOM, however it could lead to more complex code due our workarounds.
Does this style-loader-like solution seem appropriate to you?
@radiovisual
it is adding unused elements to the DOM
Just don't import unnecessary SVGs in your code
And we could use counting API to remove inactive defs from DOM, however it could lead to more complex code due our workarounds.
Does this style-loader-like solution seem appropriate to you?
@wmertens @radiovisual I've just wanted to be sure that it's way to go for you. Because I'd rather keep this loader framework-agnostic despite we use React for our products too.
@princed , I am all for an option that keeps things framework agnostic, but lets you easily drop into a React environment when needed. Sounds good to me, so I like @wmerten's react-style-loader
idea.
I'm just curious why some may want to deal with this stuff manually although no one does the same with styles from style-loader.
New loader version adds ability to specify custom runtime generator. Please check default generator and custom generator implementation example.
when using style-loader, the loaded modules determine the css.
However, with sprite-loader, the common use is to have an Icon component that renders a component based on a list of glyphs. This means that when you load the Icon component, all the glyphs get injected in the file.
I would like to know the best technique so that only active glyphs are loaded, specifically for React ≥v0.14.
How about a singleton
<Sprites/>
component that you put somewhere in your app, which renders the current<symbol/>
set, and then instead of<use href…
you use<Sprite id={…}/>
which, behind the scenes, updates theSprites
element based on refcounting inconstructor
andcomponentWillUnmount
.Furthermore, since you can put the sprites at the bottom of the page (proof), I believe that will also solve server side rendering since it will be stringified after all the icons were referenced.