Built-in SVG components

[natemoo-re]

• Accepted Date: 2023-09-12
• Reference Issues/Discussions: Rendering `.svg` files as components #667
• Author: @natemoo-re
• Champion(s): @natemoo-re
• Implementation PR:

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.

[gvkhna]

Please support promise imports, like src={import(‘file.svg’)}. Please, thank you!

+1, “ provide a great component for each supported framework”. I still don’t know how to in-line svg files with react/vite, always very brittle, end up copy pasting. 👍

[stramel]

Would love to see the ability to extend the built-in SVG support for icon sets in the future using something like @iconify/json.

I also think that framework support would be a good Goal. We get lots of questions about how to use icons within frameworks. Typically this has been solved using slots

[azat-io]

It's something I'm really looking forward to. ❤️

The main problem with importing via <Fragment set:html={HomeIcon} /> is the inability to use CSS classes with inlined SVGs.

What will importing SVG files look like?

---
import HomeIcon from '~/icons/home.svg?component'
---

<HomeIcon class="icon" />

[abdo-spices]

when need it to convert repeated SVGs to be use symbol like astro-icon

[Gismogy]

It's something I'm really looking forward to. ❤️

The main problem with importing via <Fragment set:html={HomeIcon} /> is the inability to use CSS classes with inlined SVGs.

What will importing SVG files look like?

---
import HomeIcon from '~/icons/home.svg?component'
---

<HomeIcon class="icon" />

I was actually more thinking for its own tag like Picture has its own picture tag.
Might that be a idea?

[cxa]

Before this builtin component is out, and if you don't like to save svg copies inside places like src/icons with astro-icon, you can try https://github.com/cxa/astro-inline-svg:

---
import Svg from "@cxa/astro-inline-svg";
import sunRiseSVG from "lucide-static/icons/sunrise.svg?raw";
---

<Svg raw={sunRiseSVG} class="sun-rise" stroke-width={1.5} />