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?
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.
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.
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.
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).
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.
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.
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