Based on the feedback, I updated the post with one more approach based on the idea from <a href="https://news.ycombinator.com/item?id=26554476#26556540" rel="nofollow">https://news.ycombinator.com/item?id=26554476#26556540</a>. The second approach avoids Rails UJS in favour of Turbo Frame.<p>Of course there are even more ways how to do this kind of thing. Keep sharing!
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.<p>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.<p>In the end the markup was very simple and is very reusable (StimulusJS v1):<p><pre><code> <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>
</code></pre>
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.
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.
I'm happy I don't have to deal with these paradigms day to day anymore:<p>- 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)<p>- PHP style templates that trigger database queries inline, making them difficult and eventually impossible to optimize<p>- Scattering view code across random places instead of writing view code with its corresponding view logic in the same file/component<p>- Wiring up functionality to templates by targeting selectors<p>- Manually setting innerHTML for dynamic functionality<p>- 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)<p>- Not being able to customize behavior because you're locked into Rails design limitations
Does anyone use Live Preview / Live Views in Phoenix, but in production with a B2C product?<p>I'm a bit skeptical of Rails performance with the method the author details here, given that Ruby is much, much slower than Elixir.<p>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.
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.
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:<p><pre><code> document.querySelector("input").addEventListener("input", e => { document.querySelector("p").innerHTML = `<strong>${e.target.value}</strong>` });
</code></pre>
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?