Summary
Let's support importing and using .svg files as Astro components.
Background & Motivation
Users have reported that .svg files are currently difficult to use—this is a problem we should provide an optimized solution for. Working with .svgs doesn’t need to be difficult or bloat your client-side JavaScript.
The Astro team has discussed and experimented with an "icon" primitive since before Astro v1.0 shipped. Now that we have shipped 3.0 with full astro:assets support, I firmly believe all of the pieces are in place to finally make this happen.
Goals
- Allow users to import and render local
.svg files as if they were an Astro component
- Allow passing props onto the root
<svg> element while overriding the existing props
- Automate best practices for to minimize performance footguns
- Including many inlined
<svg> on a page can hurt browser parsing performance. We can automatically reduce the number of nodes by using <symbol> and <use>.
- Inline
<svg> often have xmlns and xmlns:xlink and version attributes. These are not needed in HTML5 and we can automatically drop them to save a few bytes.
- Support this in a backwards-compatible way, meaning the current public interface of an
.svg import remains unchanged
- Stretch: support rendering
.svg components in frameworks without inlining them into the client side JavaScript
- Creating framework components for
.svg icons is an anti-pattern. It’s a terrible idea that bloats your JavaScript and creates all sorts of headaches for HMR and clientside performance in production.
- If we provide a great
<Icon> component for each supported framework, we’ll make it easy for users to avoid this anti-pattern. It’s so common now because there aren’t many other good solutions.
Non-Goals
- Future:
@iconify/json support
- Future:
unplugin-icons support? Making this as seamless as possible would be awesome but supporting local .svg files is a good place to start.
Summary
Let's support importing and using .svg files as Astro components.
Background & Motivation
Users have reported that .svg files are currently difficult to use—this is a problem we should provide an optimized solution for. Working with .svgs doesn’t need to be difficult or bloat your client-side JavaScript.
The Astro team has discussed and experimented with an "icon" primitive since before Astro v1.0 shipped. Now that we have shipped 3.0 with full astro:assets support, I firmly believe all of the pieces are in place to finally make this happen.
Goals
.svgfiles as if they were an Astro component<svg>element while overriding the existing props<svg>on a page can hurt browser parsing performance. We can automatically reduce the number of nodes by using<symbol>and<use>.<svg>often havexmlnsandxmlns:xlinkandversionattributes. These are not needed in HTML5 and we can automatically drop them to save a few bytes..svgimport remains unchanged.svgcomponents in frameworks without inlining them into the client side JavaScript.svgicons is an anti-pattern. It’s a terrible idea that bloats your JavaScript and creates all sorts of headaches for HMR and clientside performance in production.<Icon>component for each supported framework, we’ll make it easy for users to avoid this anti-pattern. It’s so common now because there aren’t many other good solutions.Non-Goals
@iconify/jsonsupportunplugin-iconssupport? Making this as seamless as possible would be awesome but supporting local.svgfiles is a good place to start.