Releasing elm-widgets and elm-theme

Show and Tell
1

Hello folks! Happy new year to all of you. :tada:

I’m glad to release two libraries that I hope will be useful to you in your upcoming elm projects.

elm-widgets is a collection of stateless and themable view elements that you can use to speed up your application development.

elm-theme is the library used to theme your elm-widgets in various ways, including using multiple themes on the same page and with support for dark mode. elm-theme will also be used to theme elm-book in its next version.

We also released elm-theme-tailwindcss so you can easily use your theme values through tailwindcss.

I plan on continuing to improve the documentation for these libraries in the upcoming weeks since there is a lot that can be done on that front. I’m also excited to receive any issues or PR’s so we can build this together :slight_smile:

Cheers!

17 Likes
2

Thanks for releasing this!

I’m viewing the book on the phone right now and it looks great. I like how I can use the native controls.

Here’s a not so great overflow behavior I saw, maybe you want to fix it:

IMG_20230101_224920
IMG_20230101_2249201080×1241 101 KB

Looking forward to playing with the widgets once back on my laptop :slight_smile:

1 Like
3

Thank you for the release @georgesboris! Since watching your Elm meetup talk I couldn’t wait to see all the ways in which you “use the platform”. Definitely a lot of ideas and best practices to steal for our own styleguide :innocent:

One thought: I wonder whether “Type-safe inputs and outputs” is a good idea. It sounds good, and it’s usually the first thing an Elm developer tries, but IMHO it leads to surprising behaviour and user’s inability to write certain values using keyboard:

As far as I can tell, the best practice there is to hold the raw string and let user manipulate that raw string. I couldn’t find blogposts or articles on this theme although I could swear @joelq has written something about it :see_no_evil:

Anyways, you can imagine a form for a float where you hold the Float (or Maybe Float) in the model instead of the String. You can’t write “0.5” into this form (Ellie):

Whereas if you were holding the raw string in the model, it would be just fine (at the expense of you having to parse at view-time instead of at update-time, or holding both raw input and the parsed value in the model at the same time).

I suppose the time input in elm-widgets is suffering from a similar issue, although I haven’t tried to debug it in detail.

3 Likes
4

Thanks for the feedback! I’ll update the docs and use W.Container to change the layout on mobile :grin:

5

yep! this is exactly what I’m doing on other widgets like W.InputInt and W.InputFloat but I thought the date/time ones were working based on the numeric values of the input. I’ll debug but maybe this will cause a v2 faster than I expected :sweat_smile: - we’ve been using the date one at work for a while now but the time one is indeed less battle tested.

1 Like
6

Really interesting ways of solving these problems!

Am I understanding correctly that you can’t test these components (or larger views that use these components) through elm-program-test? Because elm-program-test can’t simulate what the browser does.

7

Good point! I would imagine this would be the case for things like the togglable modal but for inputs they wouldn’t be any different from regular inputs? How does elm-program-test handle an input with a onInput attribute?

8

Yes. I was thinking of the modal widget, and other elements (I haven’t delved into those yet) that work similarly outside of Elm’s msg/update cycle.

9

You’re probably thinking of this tweet thread. I should probably turn that into a blog post :thinking:

Also of possible interest is this musing on treating forms as values to be parsed:

2 Likes
10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.