Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Built-in SVG components #699

Open
natemoo-re opened this issue Sep 13, 2023 · 3 comments
Open

Built-in SVG components #699

natemoo-re opened this issue Sep 13, 2023 · 3 comments

Comments

@natemoo-re
Copy link
Member

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
Copy link

gvkhna commented Sep 13, 2023

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
Copy link

stramel commented Oct 12, 2023

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
Copy link

azat-io commented May 7, 2024

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" />

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Stage 2: Accepted Proposals, No RFC
Development

No branches or pull requests

4 participants