Integrate Elm on Rails 7

Learn
1

Hi folks, I would like to ask you for advice to integrate Elm with the new Rails 7, I’m completely new to Elm but I’m very interested.

2 Likes
2

Hi Macpapo,

Welcome to the the world of Elm.

I haven’t used Rails since [about] version 4, but it shouldn’t be a problem for you. I use elm with an Elixir/Phoenix (FP version of Rails) backend these days, but from what I remember there shouldn’t be much difference.

Elm compiles to JS, so simply build your Elm app and load it into Rails as though it is just another JS file.

I’ve just got home from a night out, so maybe some current Rails devs can offer you better advice, but it really shouldn’t be a problem if I remember Rails correctly.

3

Thanks paulh,
being new I am very pleased that someone answered the question so quickly.

4

Mate, don’t worry about that, this is one of the best communities around. I’m sure someone with more Rails experience than me will help you out further.

Might be worth you mentioning what your Rails experience is though, so that Rails devs have an idea on how best to help you.

5

I don’t think it’s compatible with the newer rails philosophy pushing hotwire/turbo et al.

If you use rails to build classic server rendered apps without turbo, then you can use No Red Ink’s approach of building one Elm app per rails page (if I understand their architecture correctly).

I would consider using rails API only along with regular elm application. You just need to decide how to pass csrf token to elm.

6

I’m a junior developer with Rails but I really appreciate it, I’ve always enjoyed ruby but I still have a hard time figuring out how to use the asset pipeline. I discovered Elm by watching a Rails conf and since then I am very excited about Elm and would like to use it. According to DHH, the new Rails should have a more minimal approach with JS and give more possibilities for customization.

1 Like
7

:bulb: I would suggest an alternative way of thinking, which is to use HTMX. HTMX allows you to build upon REST (Hypermedia) so you can stick to using HTML over the wire instead of having to translate your JSON APIs back into HTML via Elm.

Don’t get me wrong, I love Elm and think it’s one of the best frontend languages we have but if you can avoid the entire JSON to HTML translation, you’ll save yourself a ton of time and reduce a lot of maintenance.

I have a demonstration which showcases using Hanimi + HMTX to great effect. You can also clone and play with the source code if you like as well. The original project skeleton was built using the Hanamismith Ruby gem.

8

There’s nothing to be gained by “integrating” Elm and Rails 7, keep them separated. Create a repo and project for the Elm frontend, I suggest one of the webpack elm starter kits. Create another repo for the Rails 7 project that can respond to API requests.

9

This is a great advice. So should I create with Rails only the part of Api and not the views?

10

Very interesting, I will definitely delve into it.

11

Originally that’s what I did, I created a Rails --api-only project. Eventually, I decided I wanted an admin section so I converted the app back to regular rails with views.

My advice is to just create a regular rails app that also supports API (which is just a default rails app)

1 Like
12

Our Rails application has 30 or so individual Elm applications that run as Browser.elements and interact with our API. We store the Elm code in its own directory in our mono rep. It has with its own build system which is just a Makefile that generates the JS file which is uploaded as part of our deploy process.

The Elm applications are bound to a DOM element with optional Flags passed. We do not use any single page apps.

Here is a gist with a Rails helper we use:

This works with we how we compile our Elm apps, which is a collection of applications complied into one elm.js file.

But you should be able to take this and apply it to your system.

elm "#my_div", "MyElm.App", {flags: true, myData: 123 }

MyElm.App would be a Module with a main of a Browser.element type.

main : Program Flags Model Msg
main =
    Browser.element
        { init = \flags -> init flags
        , view = view
        , update = update
        , subscriptions = subscriptions
        }

type alias Flags = { flags: Bool, myData: Int }

Hope this helps.

1 Like
13

I played with the latest rails stack a few months ago.

My conclusion? It’s not very practical to introduce Elm, if the objective is to also keep the default frontend stack (stimulus + turbo).

You can have a look at my explorations, here: GitHub - benjamin-thomas/hot_elm: Rails integration with Elm + Hotwire + Stimulus demo

In short:

The Elm files are located here.

The Elm view “component” is bootstraped here: app/views/static_pages/hello_elm.html.erb

So maybe that’ll give you a few ideas (my setup here remains subpar).

I didn’t dig any further because I’m less and less interested in rails.

14

I agree with this. It’s worth noting that Elixir Phoenix + LiveView uses this model to the extreme (in a good way). Since this concept is baked into the framework, I’d say it’s worth a look too (for simple UIs).

2 Likes
15

I still find rails API to be an interesting option with the 200k gems available mostly aligned around one framework, even if some are losing maintainers. My ranking of mainstream backend stacks for use in early stage startups is roughly: 1. Python (many packages, but community split between django, flask, fastapi), 2. Go (basic type system, many packages, large standard library), 3. Ruby, 4. Rust (exciting type system, smaller, growing number of packages with increasing web polish).

16

I think Rails is on another level, Django isn’t even closer.

1 Like
17

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