In earlier versions we used actual JS imports, but this wasn't viable in older browsers. In order to have this be accessible via the client, I've elected to save these paths as JSON. Literally all you need is a string with the path. If your icons are uniform in construction, you don't need to store the width or viewbox data. For most single-color icon sets, the path will be a single string ( "M6 12.892v1.011c-2.564-."). The first step in this process is getting the actual path data for all the icons in your icon library. If you do try this, let me know if I have misspellings or bugs and I can try to correct them. Note: the code below is a simplified version of what we use and is mostly pseudo-code, but it should give you an idea of how the basic approach works. I managed to shuffle some things around and got it working for IE11 plus, and we've now been using this approach quite happily for sometime!īelow I'll go over how this home-rolled solution worked for us in the hopes it may be helpful to other folks. It didn't work in IE11, but it did enable any project, regardless of their technology to render icons with a custom html tag. icons! Another dev prototyped an icon component with path data I'd added to our shared icons library. We were using Stencil for our new design system, and many of the the components needed. ![]() Essentially it makes building web components feel more like using a modern framework like React. It doesn't have a runtime, per se, but rather includes some polyfills and a loader which intelligently load your web components on-demand at runtime. Stencil is a "framework" for building web components. Wouldn't it be better if everybody could use one helper and have it just work? Enter Stencil.js You would have to make: an Angular directive, an Ember component, a React Component, a Rails helper, and probably dozens of other "helpers" to cover all your bases. But how do you do this when you work with dozens of teams using every tech stack imaginable? When there isn't one single "Rails helper" for folks to use, things become much more complicated. This is great! The client doesn't need to load any icons and the developer doesn't need to remember the icon markup or path data. In the post, they give a peek at the Rails helper they use: "plus") %> There's a great 2016 blog post by GitHub outlining why you would go that route. Basically, you add SVG markup directly to your HTML file and lo, an icon appears: For that reason, most teams have moved to an inline-icon approach. This is a ludicrous amount of data to try to load in one file. At the time of writing the icon system I'm working with has 1,512 different glyphs available as part of the icon set. What's the problem with inline SVG?Ī while back it became clear that icon fonts and svg sprites were less than ideal. The solution we've developed is the next step in my icon journey. Recently I've been helping out with the DX for my company's extensive icon library. We've wandered through low fidelity gifs, elaborately Photoshopped png sprites, icon fonts (remember those?), SVG sprites, and finally inline SVGs. In the last ten years, developers have been on a quest to find the best way to implement icons in a digital product.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |