Is there a comprehensive widgets/components library for ELM which contains a (almost) complete set of widgets (ie in addition to the most common widgets: grids, datatables, calendars/datetime pickers, tabbers, toggle buttons and so on) and, maybe, supports some sort of i10n/i18n?.
I’d like to use ELM in production but I cannot find a complete library of widgets which could cover a basic use case for a standard application.
You can use any plain css library for styling if you want; I know Tailwind is popular with a lot of folks on Elm Slack. There’s also a port of Google’s Material Design to Elm. I’m not sure of it’s completeness, but it is actively maintained.
If you’re looking for something more Elm specific, there’s elm-ui for handling layout. Styling is then up to you, or you could use something like elm-ui-widgets or elm-ui-framework.
For i18n there are a few options if you don’t want to write your own. There’s elm-i18next, which is the Elm version of the i18next format. There’s this idea https://discourse.elm-lang.org/t/elm-ui-translate-proof-of-concept/5921if you’re using elm-ui, though I could see something similar being possible with elm/html as well. There’s also a web component I built for those that that would like to use Fluent translations https://github.com/wolfadex/fluent-web/.
There’s probably more too.
2 Likes
Have you seen this package?
Thanks for the suggestions.
I know elm-ui and and elm-ui-widgets and they seem very good.
Still I think some more complex components are missing. Maybe i could try to write my owns but this would be a hard task at least for me.
In general, I have the feeling that a complete library is not yet available.
If I had the crazy idea to write something on my own, could be web components the right way to implement it nowdays?
Have a look at elm-mdc as well. This is an Elm implementation of Google’s Material Components for the Web. It has a fair amount of components.
There is no easy answer. Each option has its own set of trade-offs.
Web components allow for invisible management of local state (accidental state to the user of the widget) but this might bring in troubles if the component gets accidentally destroyed and recreated as part of the virtualDOM update. There are ways to protect against this kind of accidental destruction/creation by using Html.Keyed.
Another option is to have the state explicitly handled in Elm. This is the approach that was taken by elm-bootstrap (look at the Dropdown for an example of this). Of course, if you UI is rather complex and has a lot of these components, your Msg custom type and update will grow to be very big.
1 Like
What pieces are missing from the various options for you to consider it complete? I know it’s common to use A web component wrapper for some complex items like calendars, but I’m having a hard time thinking of anything that doesn’t exist in Elm or would be too challenging to add. Not saying you’re wrong, just trying to understand what you need.
I’m pretty sure that someone could implement most widgets directly in ELM but I’m worried about some complex behaviours which could be hard for me to write in ELM.
Writing a production app, for me it means trying to focus on the application domain and trying to avoid rewriting a library of visual components as much as possible.
However elm-mdc seems quite promising.
Hi @gorgoroth, seeing that you are interested in elm-mdc and web components, please check out material-components-web-elm which is exactly that. 
Hi @wolfadex, regarding your curiosity about why one would prefer a web component rather than a pure Elm implementation of an UI widget*, I have found the following to be arguments for a web components approach.
Accidental state As @pdamoc mentioned any pure Elm implementation would have to explicitly handle accidental state should that requirement arise. An example for accidental state could be storing a Bool for whether your text field has focus or not, or storing an Int for the height of something.
Ports You might have to use ports for some tricky interactions that would make your widget API a lot more complicated than you want it to be. For example you might have to use ports to detect node initialization (maybe you have to measure something first render), to test whether a browser has a particular feature, or to determine whether your text flows from left to right or from right to left (to account for that in computations).
It is in my opinion difficult to quantify the impact of those arguments. After all there are a lot of CSS-only UI libraries that are doing a fantastic job! But I have encountered obstacles like that in the past. In fact, I would be very curious about writing web components in Elm, as means of abstracting accidental state and ports from an Elm library.
* well, I first read your post as if you were curious about exactly that. Now I am not so sure - I hope you don’t mind.
Sorry for any confusion. I’m fully in support of using web components with Elm and other languages/frameworks. I am the author of wolfadex/fluent-web after all . I was trying to say that if you can’t/don’t want to do it in Elm that web components are usually an easy alternative.
For example, I’ve seen people wrap calendars in web components for use in Elm. I also whipped up https://ellie-app.com/9dLFdVhYHQpa1 yesterday as an example for using the browser’s clipboard API. We’re even using web components at work for our future common UI pieces so they can be used across multiple frameworks!
Also, @aforemny, love the work you’ve been doing with getting material design into Elm 
!
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.