How to only inject symbols that are in use about svg-sprite-loader HOT 17 CLOSED

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.

from svg-sprite-loader.

@wmertens you want something like this - https://github.com/webpack/style-loader#reference-counted-api?

from svg-sprite-loader.

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…

from svg-sprite-loader.

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:

• Create <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.
• Create <Sprite id={...}/> React component that makes a <svg><use .../></svg>.
  • It could have a noSvg attribute to just return the <use/> so it can be used inside <svg/>.
• Add refcounting API, and change the above components to use it. The output of the loader should be an object with:
  • .toString(): returns sprite id
  • .use(), .unuse(): to be called from the <Sprite/> component's constructor and ...WillUnmount
  • .Sprite: pre-bound <Sprite/>component

So 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?

from svg-sprite-loader.

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.

from svg-sprite-loader.

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.

from svg-sprite-loader.

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.

from svg-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.

from svg-sprite-loader.

@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?

from svg-sprite-loader.

@princed @kisenka ping

from svg-sprite-loader.

@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?

from svg-sprite-loader.

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?

from svg-sprite-loader.

@radiovisual

it is adding unused elements to the DOM

Just don't import unnecessary SVGs in your code

from svg-sprite-loader.

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.

from svg-sprite-loader.

@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.

from svg-sprite-loader.

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.

from svg-sprite-loader.

New loader version adds ability to specify custom runtime generator. Please check default generator and custom generator implementation example.

from svg-sprite-loader.