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

Allow control of second argument for iconToSVG #125

Open
charlie-hadden opened this issue Jul 7, 2023 · 7 comments
Open

Allow control of second argument for iconToSVG #125

charlie-hadden opened this issue Jul 7, 2023 · 7 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@charlie-hadden
Copy link

Hi there,

I'm trying out v1 - so far it's working well for me aside from one issue. I see that here, you call iconToSVG providing only one argument:

const renderData = iconToSVG(iconData);

This causes default width and height attributes to be set on the SVG, which is something which I don't want for my use case. Iconify does provide a way to avoid this using the second argument to iconToSVG, but there's no way to control that. An alternative solution would be to pass the width and height to the Icon component, but because of the typescript types for the props, I can't see a way to clear the attributes without having to work around a type error.

Aside from the dimensions, there are also some other parameters in the customization options which look useful. I'd love to see some way of controlling that parameter. Perhaps by exposing it as an optional prop on the Icon component, and maybe even setting defaults in the integration config, if that's possible.

Thanks!

@stramel
Copy link
Collaborator

stramel commented Jul 10, 2023

Thank you for filing this issue! I can look into adding the a way to pass the additional parameter. Would it cover your use-case to allow unset or auto in the height/width properties?

@stramel stramel added the enhancement New feature or request label Jul 10, 2023
@stramel stramel added this to the v1 milestone Jul 10, 2023
@charlie-hadden
Copy link
Author

Thanks for taking a look at this one. For my particular use case, passing unset in the height property would be sufficient, yes. I do think that the 1em height that gets set is probably a good default too, but I think that's a breaking change from the v0 version of astro-icon, so might be worth a note in the changelog.

@stramel
Copy link
Collaborator

stramel commented Jul 14, 2023

@charlie-hadden Can you provide an icon that you're testing and what you would expect it to be? That will help me ensure I get a good resolution for this.

@stramel stramel self-assigned this Jul 14, 2023
@charlie-hadden
Copy link
Author

I've taken a bit more of a look into this, and set up a bit of a demo/writeup here https://github.com/charlie-hadden/astro-icon-reproduction/blob/unset-height/src/pages/index.astro. If you spin up that project locally then you should be able to see the behaviour I'm talking about.

I also poked around with the astro-icon source a little, and handling the transformation options (vFlip, hFlip, rotate) would require a little extra work than I initially thought. Because they modify the SVG, the caching for icon reuse would need to be updated as otherwise the transformations applied to the icon on its first use would also apply to all later uses of the same icon. I do think that would be a nice feature to have though.

If the decision is to only support the sizing use case, then I think expanding the type for the sizing props to number | "auto" would be enough.

Do check out the demo I put together though - there are some bits which were a little easier to explain with an example. If more complete control of those options and sizing is something which this project is interested in then I'd be happy to put together a PR for it.

@fflaten
Copy link

fflaten commented Dec 22, 2023

If the decision is to only support the sizing use case, then I think expanding the type for the sizing props to number | "auto" would be enough.

Related #163

@natemoo-re
Copy link
Owner

Sorry about that PR @charlie-hadden! If you're still interested in this, I'm definitely on board with supporting this. Maybe under a transform object prop?

@charlie-hadden
Copy link
Author

@natemoo-re no worries! I can take a look at creating a new PR after the holidays if nobody gets to it before me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants