from Hacker News

Live previews with Rails and Stimulus 2

by nilsandrey on 3/23/21, 1:02 PM with 49 comments

• by strzibny on 3/23/21, 7:47 PM

  Based on the feedback, I updated the post with one more approach based on the idea from https://news.ycombinator.com/item?id=26554476#26556540. The second approach avoids Rails UJS in favour of Turbo Frame.

  Of course there are even more ways how to do this kind of thing. Keep sharing!

• by rolae on 3/23/21, 3:56 PM

  Nice. I did something similar recently with an iFrame where you have a form for configuring customer sites and it displays the preview in an iFrame.

  I had to throw in some debouncing and special handling for hidden inputs, as changes to hidden inputs do not trigger a change event on the form.

  In the end the markup was very simple and is very reusable (StimulusJS v1):

          <div data-controller="iframe-preview" data-iframe-preview-url="<%= preview_path(@letter) %>">
            <form data-target="iframe-preview.form">
               <textarea name="body">My letter</textarea>
           </form>
           <iframe data-target="iframe-preview.iframe">
          </div>
  

  This is when StimulusJS becomes really nice, when you can compose behavior in your markup with some simple data attributes. I did not think at first that I would need this controller in other places, but a couple of weeks later, I actually needed it, and was able to reuse the controller without modification for another use case.

• by yuppiepuppie on 3/23/21, 2:29 PM

  As someone who is only vaguely familiar with Rails and doesnt really know anything about stimulus, it would be nice to have a "What this looks like" section with a gif of what the user sees. Otherwise, I dont know what this article is talking about. Im interested as there is probably some application to my daily work, but a wall of code and words doesnt tell me much very quickly.

• by Igor_Wiwi on 3/23/21, 2:30 PM

  good to see Rails dev related posts on HN again:)

• by 023984398 on 3/23/21, 1:32 PM

  This is cool but its not using hotwire (turbo frames / turbo streams)

• by stevebmark on 3/23/21, 8:20 PM

  I'm happy I don't have to deal with these paradigms day to day anymore:

  - Making everything go through a "controller" instead of well designed clients and APIs. Mixing rendering, redirection, ajax handling as well as page serving as well as business logic all into a "controller" is painful. ("Models" and the spaghetti design patterns they come with are even worse)

  - PHP style templates that trigger database queries inline, making them difficult and eventually impossible to optimize

  - Scattering view code across random places instead of writing view code with its corresponding view logic in the same file/component

  - Wiring up functionality to templates by targeting selectors

  - Manually setting innerHTML for dynamic functionality

  - Dealing with rails "turbo" anything, which is not useful in a real world application, and dangerous (we've had production outages because of trying to use turbolinks)

  - Not being able to customize behavior because you're locked into Rails design limitations

• by shay_ker on 3/23/21, 6:02 PM

  Does anyone use Live Preview / Live Views in Phoenix, but in production with a B2C product?

  I'm a bit skeptical of Rails performance with the method the author details here, given that Ruby is much, much slower than Elixir.

  I'm curious if even Elixir folks deploy Live Views in consumer-facing apps. But I can totally see it being used for admin interfaces or internal applications, for sure.

• by lucidone on 3/23/21, 4:52 PM

  Would be great to see a paragraph or two about how to write tests for this functionality. Testing has been my pain point regarding front end development with Rails. Compelling tech all the same and a great article.

• by jack_riminton on 3/23/21, 2:28 PM

  Would be great if you could add a small video/gif of this

• by kaleidawave on 3/23/21, 5:36 PM

  The post is well written but I don't see the point in this when you can achieve the same in 145 bytes of JS (vs 80kb of stimulus) and avoid a trip to the server:

    document.querySelector("input").addEventListener("input", e => { document.querySelector("p").innerHTML = `<strong>${e.target.value}</strong>` });
  

  Reusing the logic could be done if the server was node or through compiling the formatter to wasm. I struggle to see how Hotwire makes things simpler and has comparable speed to a SPA?