Personally, I think someone should just submit a PR and update Halogen itself to have SVG elements just like how it has all the other HTML elements.
It’s not hard to do. Just tedious and takes time.
1 Like
Did you mean my reference repo? If so, there’s more than just type-level programming there, haha 
1 Like
Oh, yea, someone gave me a link to that folder some time ago so I thought it was the only thing in there
I’d prefer to have this as a separate project still, but now we have a purescript-halogen org, so it could live in there and we’d keep it up to date if someone does the initial work 
Could you explain why? I’ve never understood why you don’t want the SVG elements inside of that repo. If we do that, a new user is going to learn halogen, then try to do something with SVG, and discover that such elements are not there when all other elements are. It comes off as a bit of a surprise and unnecessary thing.
This approach would make sense if one wanted to submit a PR doing the basic SVG stuff but not implementing everything. Then that library could be incrementally added to until it does cover enough things. At that point, I could see it merged into the main Halogen one.
Ah… Yeah, there’s a lot more to it than that. There’s the “short overview” table of contents and then there’s the “long way-more-detail-than-you-wanted” table of contents. I think I need something in-between as I don’t know whether people can actually find anything in it (although one could use the GitHub search on that repo).
1 Like
Also, if that’s the route you’re going to go with, could you create that PR? Adding basic SVG support isn’t too hard.
There’s a couple of reasons:
- It’s not that common a use case as far as I’m aware. I think I’ve maybe seen 4 or 5 people asking about it. Obviously there could be more people who aren’t publicly talking about it, but that’s all I have to go off.
- I/we don’t use SVG, and I can’t think of a situation in the forseeable future in which we would be, so have no real knowledge about what would be required to do it well or the ability to make informed comments about it.
- It increases the surface area of the API and becomes another thing to document, and as I’m sure you’re aware documentation is a bit of a problem for me
- In an ideal world, the HTML elements & properties would not be part of the core Halogen library either. I don’t like the fact we have to make breaking changes to the whole library to accommodate relatively small corrections in there. I can see that happening a lot in the early days of SVG inclusion until the bumps get ironed out through repeated real world usage.
If I was to break out the existing HTML elements & props, I’d probably do it like -argonaut: have purescript-halogen just exist to bundle up the individual libraries that make it a batteries included kinda thing… in that situation it could include the hypothetical SVG stuff too. That way at least making breaking changes to the less stable parts of the library means people could pull it in piecemeal if they need changes that have been made in HTML or SVG without having to wait for a new major release.
I’m sure you’re aware documentation is a bit of a problem for me
What? It’s the first I’ve heard of it 
There’s a couple of reasons…
Ok, thanks for pointing those out. They make sense and I agree with those reasons.
If I was to break out the existing HTML elements & props…
That doesn’t sound like it would be too hard to do. Just a bit of copying and pasting (though I guess the “bower registry is down” problem might delay that). How high of a priority would this be for you? What I/others could do is create a separate repo that does the SVG stuff and another repo for the HTML elements currently in the halogen repo. Once those repos are mature, I could transfer ownership to the purescript-halogen GitHub organization. Then via a breaking change (v6? v7?) reconfigure these libraries into halogen-core, halogen-html, and halogen-svg variants.
At Statebox, we’ve been using our own fork statebox/purescript-halogen-svg, which includes some animation related functionality. We haven’t gotten round to consolidating it with other forks yet, but I think having an SVG lib live under the purescript-halogen org would be a great improvement, if only so people would know where to look. I believe kwohlfahrt, the author of the original repo, would be up for that as well, although I’m not sure how responsive he’d be.
3 Likes
So I read the discussion and tbh I’m ok with any of the solutions as long as it supports svg, now the question is, since I need to use svg pretty soon, should I try using halogen or use something like react-basic which seems to already have svg support? (As I said I’m new to the ecosystem so I’m not sure which one would be the best for my usecase)
For context, you can already use SVG right now in Halogen, even without that above library. However, you would have to write the boilerplate code that makes it work. For example, see this file.
The benefit of React is that it already has an ecosystem you could hook into via FFI. And it has hooks, which Halogen does not yet have.
1 Like
Hey, so I started playing with your learn-halogen repo, the first 2 folders were pretty easy to understand, but the 3rd one starts using a bunch of unexplained stuff which makes it really confusing, it would be great to have an in depth explanation of how inputs and atuff works
In addition to Jordan’s tutorial, I used Thomas Honeyman’s Real World Halogen app as a learning tool.
It’s well designed and well documented.
1 Like
Mind pointing out what that ‘unexplained stuff’ is? I have no idea how I could help you (e.g. what you did understand, what you didn’t, where you started to experience that confusion, what types you did understand, which you didn’t, etc.).
I had mostly problems with the slot system stuff and queries, had no idea what those are… I eventually read the small official guide and looked trough the real life app, and now I understand it, thanks anyways, the repo was pretty cool but sometimes the code doesnt speak for itself
svg not working so well
Glad you figured it out!
For those interested in updating the SVG library / writing a new one, see my comment in another thread