DEV Community

Discussion on: React to Elm Migration Guide

Collapse
 
jesterxl profile image
Jesse Warden • Edited

I'm going to answer your shareability separately because my experiences here may be unique and not applicable to many.

I'm a developer. I've never been good at CSS, and I don't plan on getting much better. This means I use a lot of component & CSS frameworks. Examples include Bulma & Bootstrap for personal work. For professional work, almost every large company I've worked at recently has 1 to many design systems. This means there are teams dedicated to working on both the atoms, colors, components, documentation, and tooling. Some are focused on React or Angular, while others target all. Some recently even have Lit or other Web Component support, doing their best to be framework agnostic.

So this provides some new challenges. How do you approach building components in Elm, then? This is a complicated, and nuanced area.

Typically, you'll use Elm.

There is a rise recently in kids loving elm-ui, but that reminds me of the days of Flash developers ignoring the tidal wave of CSS coming, so I ignore it.

I love elm-css so you can use the compiler to ensure your CSS is correct, but first off, why am I writing a lot of CSS with a design system, and second, I'm not smart enough to leverage it yet.

Third, there is some growth process that many Elm devs seem to want to create encapsulated components, so utilize Html.map so they can have their own update, model, etc. This is frowned upon in the Elm community, but some dig it?

Lastly, I've seen some success putting an Elm API on top of already built Web Components, specifically the Material Design ones. This cat wrote an Elm API on top of the MDC web components. This means you get to use raw JavaScript classes with guaranteed compile time types. This is NOT trivial work, either. I've used multiple versions of these, and seen how the author has changed the API over time to be more "Elm like" and easier to use. While I respect it, it makes me wonder if it's better to just code everything in Elm, but... I'm not sure. I'd have to build my own component library to know. Based on reading some of the source code of many web components, it seems a lot of the work is in CSS land, so perhaps this is a viable approach for Enterprises who already have many design systems.

In terms of share ability, :: shrugs ::. Most components are just functions. Some functions are easy to share if you already have the ability to make the inputs. However, if your components require specific types, then those need to be easy to create as well. So nothing unique here; same challenges you'd have in TypeScript of "creating re-usable code".

As a surviving ex-Flash & Flex developer, my gut says writing API's atop Web components is probably prudent for the long term of obeying web standards which always win and ensuring your Elm components will work in newer versions of Elm.