Confusion related to halogen

I’m new to the purescript ecosystem, and I see a lot of people using different things. Halogen seems cool, but everyone seems to use a different version for some reason and I can’t find a good place to learn it.

What is the best way to learn haolgen and what version of It sould I look into?

This might help: http://www.github.com/jordanmartinez/learn-halogen

Basically, v4 is the latest “stable” release. However, some changes were made in v5 (not yet officially released only because the docs haven’t been updated, but it’s otherwise used in production) that make things significantly cleaner/better than the v4. However, I’m not sure whether the rest of the ecosystem has caught up to v5 yet.

So, I’d recommend learning v5 rather than v4.

4 Likes

Thanks, I’m going to take a look at that repo!

Unrelated to the question but that type-level programming repo was amazing, didn’t think I’ll ever meet the author anywhere online:)

Hmmm, I’m building a project which uses a lot of svg, is there any way to render sbg with halogen 5?

Welcome!
Please share any feedback you have about your experience learning the language. There’s still lots of work to do with making PureScript more approachable, such as providing better direction for getting started with frameworks. I’d like to know what other areas are in need of more attention.

There’s also a more concise halogen guide that was very recently updated for v5. It may be nice to eventually unify both guides. Let us know if you have any feedback about what elements of either guide you find helpful or if any areas could be improved. For authors who already know the language and frameworks, it can be tough to detect any gaps in the material, so critique from beginners is very important for improving documentation quality.

Looks like there’s an out-of-date dependency. Is it time for us to fork the unmaintained halogen-svg to purescript-contrib so we can apply this PR to update to halogen v5 that’s been pending for 4 months?

Hey, so about learning the language, having prior fp-ts & f# & basic haskell knowedge made learning purescript pretty trivial, the harder part is actually learning how to use different libraries.

One of the pain points with purescript was interop. Parcel not allowing purescript out of the box is somewhat annoying, the ts interop is sometimes working but the fact the declarations are generated in the output folder makes using it alongside the webpack loader for purescript nearly impossible.

The vscode extension is good enough, but type hints for local definitions in do-notations / let-in & where statements would be a nice addition.

Overall I’m pretty happy with the purescript experience, the most pain comes from the tooling, not the language itself.

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 :slight_smile:

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 :wink:

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 :wink:
  • 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 :wink: :smile:

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

Good to know!

I’ve opened an issue in the original repo to see what the author says.

1 Like

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