Support XML Elements

[maragudk]

Support XML Elements

[markuswustenberg]

I'm playing with an implementation here: https://github.com/maragudk/gomponents-xml/pull/1

Not sure how I'm going to keep code duplication down, but maybe it doesn't matter. Or maybe I should just incorporate it in this repo… (I'm thinking out loud.)

[markuswustenberg]

Hi @tgrosinger . Hmm, yeah, the library is really geared towards HTML5 use, but I've hit the use case before. I have an SVG package in the repo which would potentially hit the same issue.

Maybe I could consider making an XML package that renders slightly differently, I'll think about that. I would think it would have more or less the same API, without the HTML-specific parts, and probably no helpers, so it would be pretty easy to implement.

[tgrosinger]

It's not very clean at all, but this change did fix the issue for me: https://github.com/tgrosinger/gomponents/commit/b8a83564c297b77523b7944ad5c97fbb1329ca13

I think if renderChild were exported it would be much easier to reduce the duplication. Then I might suggest creating an xml package as a sibling to the svg and html packages.

[tgrosinger]

Alternatively, this might also relate to #124 and possibly moving where the void element checking occurs and moving it out closer to the specific element type. That might be harder to do without changing the API though.

[markuswustenberg]

@tgrosinger Both good points. For me, it's important that the focus of the library is HTML, and having something like XML support is nice, but not central to it.

I don't want to pollute the public API with XML-specific stuff that would confuse other users, but maybe I can pull the rendering logic into an internal package and thus have it available both from the xml and core package. That would also clean up the svg package, which similarly doesn't have void elements.

That actually seems like a feasible solution. I'll play around with it when I get some time, hopefully next week.

[tgrosinger]

Sounds great. Thank you very much for looking at this!

[markuswustenberg]

@tgrosinger I played around with this a bit, but quickly ran into problems with import cycles when pulling out the rendering logic. I'm not currently sure about a path forward without breaking the API (not an option), exposing rendering logic in the API (not a huge fan of that, since the focus is definitely HTML and would be totally irrelevant to those consumers), or duplicating a lot of code (also not a huge fan of that). I'll think about it some more, and suggestions are also welcome. 😊