I was using elm-tailwind-modules a lot to build some UIs with TailwindCSS. In the process of building it, I ended up with a working HTML to Elm tool, so I went ahead and published it as a general tool that can be used with or without Tailwind/elm-tailwind-modules. I hope this can serve as a useful and robust resource for the community. It includes a robust end-to-end test suite, so it was very easy to make sure that lots of different types of input are handled correctly.
The commonly used HTML to Elm was a great tool, but had a few known issues and was still built with Elm 0.18. It turns out, I was able to make sure that none of those none issues happen in html-to-elm.com, so hopefully using this tool will make people’s workflows a little more seamless (less manual editing). It feels great when the code compiles the first time you paste it into your editor, so it’s worth going that extra mile.
Here are some of the features it includes:
UI
Configure import aliases and exposed values to use in generated code
Save import aliases/exposing preferences through localstorage
I like the idea of having really polished community resources, and I hope this can play that role for this particular problem. If you find any rough edges, I’d love to hear your feedback. Feel free to reach out in Slack or open a GitHub issue to discuss further.
I normally reach for HTML to Elm - Visual Studio Marketplace when I need to go from an example to elm. Haven’t had much problems, but might not have used it enough. The nice thing is, that you don’t have to leave your editor and don’t have to compile.
In general, the mappings of tags and attributes to the corresponding Elm functions isn’t comprehensive, and the fallback it uses yields invalid Elm syntax. It’s one of those quality of life things that makes for a much nicer experience when those edge cases are handled.
If somebody wanted to use the html-to-elm.com code and turn it into an editor plugin, I’d welcome that. Or I’d be open to a pull request to add that to the monorepo as well.
It also assumes unqualified imports for both HTML and SVG attributes and tags. But there are name collisions in those modules’ exposed values, and that can also lead to using invalid combinations like accidentally using Html.Attributes functions in an SVG context (which can cause runtime exceptions if they use a property under the hood).
The elm-review rule I published scans the module for imports and uses those in the generated code to figure out which import aliases and exposed values to use. And the web UI has a settings pane that lets you configure those.
I’m not sure if this is what you have in mind, but the pro version of elm-ts-interop includes a scaffolding tool that generates Elm types with Decoders/Encoders from TypeScript types. It’s quite handy! And it actually runs the TypeScript compiler API to derive all the types you export, so you can do sophisticated things, including even generating Elm Custom Types from TypeScript discriminated unions.
I need to get some more demos of it and some more information on the landing page, but you can see it in action in a few spots like here in this video tutorial: https://www.youtube.com/watch?v=FzCRbI4Ne6w&t=1137s.
I think there are more opportunities for handy little Elm utilities for this kind of thing as well, I’d be curious to hear if people have other thoughts on what utilities would be useful.
My API endpoint returns data using union types, e.g. { Success: true, nth: number } | { Success: false, Reason: "username already used" }.
When converting these typescript types that into Elm code, it would be more readable to use hand-picked intermediary type and type alias.
Also, Elm has more fine gain types (Int and Float) for numeric values.
So the conversion process may not be fully automated.
The web-based UI approach used by elm-ts-interop seems better fit.