There’s a couple of ways you can do it. It depends on if you want to allow multiple modals at the same time. I chose the simpler option of only allowing one modal.
I initially render an empty turbo frame, (and a turbo stream tag too) within my layout file:
<%= turbo_frame_tag "modal" %>
<%= turbo_stream_from online_newsletter %>
I then have a button somewhere that kicks off the modal:
<%= link_to 'Add Article', [:new, :admin, online_newsletter, :article],
data: { turbo_frame: 'modal' } %>
The server then responds with something like the following:
<%= turbo_frame_tag "modal" do %>
<div class="modal is-active" data-controller="modal">
<div class="modal-background"></div>
<%= form_with model: article, scope: :article, url: [:admin, online_newsletter, :articles],
class: 'modal-card', data: { action: 'turbo:submit-start->modal#beginSubmit turbo:submit-end->modal#handleSubmit' } do |form| %>
<!-- modal content, form fields etc... -->
<footer class="modal-card-foot">
<button class="button is-success" data-modal-target="submitButton">Add</button>
<button class="button" data-action="click->modal#deactivate" type="button">Cancel</button>
</footer>
<% end %>
</div>
<% end %>
No magic required up to this point as when you render the view (with no layout) wrapped in that turbo_frame_tag it just replaces the contents of that turbo frame. I think you can even render a layout if you want and Turbo will ignore it.
The next part is just some wiring up with stimulus though you can probably achieve a result without it. I use stimulus to basically delete the modal element from the page which ‘closes’ it. You could return a response with an empty turbo_frame_tag which would have the same effect. Using stimulus allows you to do more fancy things like prevent from submission unless conditions are met, and prevent the closure of the modal with a warning about unsaved content and so on. This is my modal controller:
import { Controller } from "@hotwired/stimulus"
export default class extends Controller {
static targets = ['submitButton']
connect() {
document.documentElement.classList.add('is-clipped')
}
deactivate() {
this.close()
}
beginSubmit() {
this.submitButtonTarget.classList.add('is-loading')
this.submitButtonTarget.disabled = true
}
handleSubmit(event) {
this.submitButtonTarget.classList.remove('is-loading')
this.submitButtonTarget.disabled = false
if (event.detail.success) { this.close() }
}
close() {
document.documentElement.classList.remove('is-clipped')
this.element.remove()
}
}
I’ve trimmed it up a bit as I have extra stuff for disabling submit if trix attachments are still uploading and also some stuff to track if the form has had edits (in which case it won’t let the user close the modal or leave the page without saving or acknowledging).
Here’s my controller action for create:
def create
respond_with article do |format|
if article.save
format.turbo_stream { }
Turbo::StreamsChannel.broadcast_append_to online_newsletter,
target: 'articles', html: render_to_string(partial: 'online_newsletters/article')
else
format.html { render 'new', status: :unprocessable_entity }
end
end
end
I’ve tried to clean that up a bit but basically I wanted to broadcast my updates to everyone working on the newsletter, so I use a Turbo Streams channel to do that. You could just as easily render out a turbo streams append HTML tag to only update the current user’s page. In that case you’d do that inside of format.turbo_stream { }. In the error scenario rails just renders the form again with the errors outlined and the modal appears to update with this new content. It’s seamless enough that it just looks like some javascript has updated the particular fields to add error states but in reality the whole modal has been replaced.
Some caveats to the above:
I hope that helps. I did find it took quite a while to get my head around all the differences @chris31 described, especially because the documentation isn’t overly user friendly, but once I had things settled in my mind it was quite easy to do some pretty powerful things with very little javascript.