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
Comments
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. 👍 |
Would love to see the ability to extend the built-in SVG support for icon sets in the future using something like 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 |
It's something I'm really looking forward to. ❤️ The main problem with importing via What will importing SVG files look like? ---
import HomeIcon from '~/icons/home.svg?component'
---
<HomeIcon class="icon" /> |
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
.svg
files 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 havexmlns
andxmlns:xlink
andversion
attributes. These are not needed in HTML5 and we can automatically drop them to save a few bytes..svg
import remains unchanged.svg
components in frameworks without inlining them into the client side JavaScript.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.<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/json
supportunplugin-icons
support? Making this as seamless as possible would be awesome but supporting local.svg
files is a good place to start.The text was updated successfully, but these errors were encountered: