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

Remove SVG helpers? #206

Closed
markuswustenberg opened this issue Sep 20, 2024 · 4 comments · Fixed by #214
Closed

Remove SVG helpers? #206

markuswustenberg opened this issue Sep 20, 2024 · 4 comments · Fixed by #214
Milestone

Comments

@markuswustenberg
Copy link
Member

See comment at #196 (comment)

@markuswustenberg markuswustenberg added this to the v1 milestone Sep 20, 2024
@Nintron27
Copy link

I just ran into this project, and can't wait to dig into it more, so, take my comment with a grain of salt.

I use SVGs a ton, and personally I never render them out element by element in other templating languages I've used. I usually create them in some sort of design tool like Figma, and do one of two things:

  1. Add the internal structure of the svg (everything inside the tag) to something like an assets folder, then just render the SVG tag with it's attributes, and inject the internal structure of the SVG as a raw string. (in Gomponents case this may look something like the pseudocode g.El("svg", g.Attr(...)..., g.Raw({string from file})))
  2. Just paste the entire SVG into an assets folder, and create a little tool to inject classes into the class attribute leaving everything else untouched. (I will probably take this option when using gomponents).

So, for my 2 cents, I personally won't use the SVG helpers Gomponents provides but rather use g.El and g.Raw to create my own helper that just renders SVGs from an assets files, and optionally injects classes on it. This solution has covered 100% of my teams needs for using SVGs, and the only case I can think of it not covering, is dynamically changing the internal structure of an SVG, which is an extremely uncommon use case from my experience.

@markuswustenberg
Copy link
Member Author

@Nintron27, thank you for your input!

I've come to more or less the same realization: A lot of the benefits of gomponents are basically lost with the SVG parts, as I do the same as you: find an SVG somewhere or create one, then paste it into Raw and call it a day.

I only realized this when a kind developer opened #196, and I didn't want to merge it for some reason I wasn't entirely consciously aware of. I think you've explained why better than I could, so thank you for that.

With option two, would you like having an SVG helper element with the XML namespace etc. on it and inject only the inner parts, or does it not really matter?

markuswustenberg added a commit that referenced this issue Oct 3, 2024
Because the added value of having this was very small, and I don't want to confuse people about what's properly supported,
I've removed the SVG package. As #196 showed, there can easily be conflicts between HTML and SVG, and the rendering isn't
really set up for anything else than HTML.

It's still easy to create SVG elements: `html.SVG` exists in this repo, and the rest is often just a string that can be included using `g.Raw`.

Fixes #206
@Nintron27
Copy link

With option two, would you like having an SVG helper element with the XML namespace etc. on it and inject only the inner parts, or does it not really matter?

For me it probably doesn't matter, since I tend to just paste the entire SVG into an assets folder, add an empty class attribute to it, and then have a helper to inject classes into that class attribute. I may even just use Go's html/template ParseFiles() just for this one use to inject classes easier.

@markuswustenberg
Copy link
Member Author

Makes sense. Thanks for the answer!

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

Successfully merging a pull request may close this issue.

2 participants