Comments (15)
I actually would like to make this easier by sticking an array in the config file that lets you specify which icons you are actually using, stripping out the ones you aren't, and caching that on disk somewhere, but not sure when I'll have a chance to play with it.
What I'm personally doing currently is just manually deleting the icons I'm not using from my spritesheet. I keep a complete one in the same folder for reference, and copy the icons back in if I need them. Little bit of manual work but simple as hell still.
from blade-icons.
Why don't you use a gulp flow for this? I just build my sprites in my gulp build step. I think this feature would be a bit over the top for this package.
Also, you would have many different sprites (one per page). If you use the inline
option you can also use individual icons and have no additional requests.
from blade-icons.
Because not everybody knows enough to delve into gulp? or want to include extra dependencies etc, when a pre-existing dependency (blade-svg) could do it, which would make it a much easier and more flexible for people to handle files in their own way?
You'd have just the 1 spritesheet at the top of the template. Imagine if you had a spritesheet with 30 individual images in it. But Page X only needs 1 image. You'd include them all for that 1 image. By having a dynamic spritesheet you'd be able to only include that 1 sprite into the page. Allowing it to be used multiple times without adding extra page bloat. (not worried about extra requests as thats irrelevant to this package?)
I'm not saying there are not other ways to solve this issue, I'm just saying it would provide an easier way for users to get the benefits of non-static spritesheets resolving code bloat whilst keeping an easy singular files setup.
from blade-icons.
You are addressing the optimisation of svgs, which to me, is not part of this package. It allows you to do the optimisation in any way you want.
- Using inline will mean no extra requests
- Building a sprite yourself will mean one request
Including the entire sprite in every page if you only need one should not be an issue:
- Its a couple kb
- You should make it cachable by the browser, so it is only 1 request entirely, which is better than 1 request per each page.
It would make this package very complex because:
- do you create the sprite every time, or only if it does not exist?
- how do you track if svg icons have been updated?
I see what you are talking about, but I don't personally think it is the right approach. However, its of course up to Adam in any case.
from blade-icons.
I'm not suggesting you actually generate a .svg I'm just suggesting that it almost hoists all the requirements to the top e.g you have hundreds of .svg in your library, but you only need the 2 from the template
/resources/img/icons
/resources/img/icons/one.svg
/resources/img/icons/two.svg
/resources/img/icons/three.svg
/resources/img/icons/tick.svg
/resources/img/icons/cross.svg
<body>
@spritesheet();
@icon('cross') //adds the cross.svg to memory for later
@icon('tick')
just generates what is effectively like
<body>
<svg>
<defs>
foreach( $usedIcon as $icon )
<g id=" $icon->basename ">
$icon->xml
<g>
</defs>
</svg>
<svg>
<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#cross"></use>
</svg>
<svg>
<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#tick"></use>
</svg>
So it only dumps out the definitions of the icons used in the template, almost like how @section
and @yield
works
So
- No you don't create the sprite every time, as there is no sprite to create
- You dont need to track if the svg icons have been updated
from blade-icons.
But why is this better than just using the inline
method?
from blade-icons.
Saves you having the whole XML dumped on the page several times for the same icon
from blade-icons.
Yeah, well I think this is really not an issue. But that is a personal opinion. Lets just see what Adam thinks.
from blade-icons.
I'm looking at this at the moment, and at first glance what about passing a name to the spritesheet helper?
you could then define different sheets for your pages. i use grunt-svgstore to generate the sheet but that cold be change to a command and just like adam mentioned have an array of used icon in groups?
from blade-icons.
@OwenMelbz
here a quick hack on what you say on the icon factory
use Symfony\Component\DomCrawler\Crawler;
private $icons;
private $config = [
'build' => false,
];
public function __construct($config = [], $filesystem = null)
{
$this->icons = Collection::make();
}
public function spritesheet()
{
if ($this->config['build'] && !$this->icons->isEmpty()) {
$svgs = $this->icons->map(function ($item, $key) {
$crawler = new Crawler($this->getSvg($item));
$svg = $crawler->filter('svg')->html();
return sprintf('<symbol viewBox="0 0 1792 1792" id="%s"><title>%s</title>%s</symbol>', $item, $item, $svg);
});
return new HtmlString(
sprintf('<div style="display: none;"><svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">%s</svg></div>', $svgs->implode(' '))
);
}
return new HtmlString(
sprintf('<div style="display: none;">%s</div>', file_get_contents($this->spritesheetPath()))
);
}
public function icon($name, $class = '', $attrs = [])
{
if (is_array($class)) {
$attrs = $class;
$class = '';
}
$attrs = array_merge([
'class' => $this->buildClass($class),
], $attrs);
$mode = $this->renderMode();
if ($mode == 'sprite' && $this->config['build']) {
$this->icons->push($name);
}
return new Icon($name, $mode, $this, $attrs);
}
from blade-icons.
ps just added the main parts that changed
from blade-icons.
I can only upvote for requested feature. There completely no point to include all your svg on page, while it uses only few. If it's hard to implement automatic way to check which images was requested, at least there should be way to setup it somehow using settings.
from blade-icons.
Is this something that you all still would like? I think passing an array of icon names to the sprite sheet helper as a second argument might be of use.
Btw, please also check out the PR that I made for the next version: #50
from blade-icons.
Well, with HTTP2 (and Let's Encrypt) there isn't really a need for spriting anymore.
from blade-icons.
After consideration and gathering from the feedback so far I've decided to remove sprite sheet support in the next version.
from blade-icons.
Related Issues (20)
- Cannot register icon set HOT 3
- Re-use icons HOT 4
- Installation with Sage 10 theme HOT 2
- Unknown Blade component HOT 1
- Dramatic performance difference between blade component and blade helper HOT 8
- How Can I Use "wire:click" with @svg Syntax? HOT 3
- "defer" attribute fails HOT 4
- php artisan icons:cache Does not work on vapor as vapor do not have those write access to those dir HOT 1
- Duplicate attibutes HOT 3
- Svg by name "home" from set "default" not found HOT 3
- Helper mistakes a blade component for an svg HOT 5
- Icons in subdirectories and `Unable to locate a class or view for component` HOT 7
- JavaScript code is not working for getting icon from JS - 'return <svg><use href="#icon-my-custom-hash"></use></svg>' HOT 1
- Error after installation HOT 7
- Bit confused on install instructions -- icons not showing up HOT 4
- Website Demo: Unable to Retrieve Icons through Search HOT 1
- Icon search is broken on the web site HOT 1
- How to download initial svg files into the correct folder? HOT 1
- Can't use blade-uit kit icons in laravel 11 HOT 2
- How to overwrite settings from a third party icon set?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blade-icons.