CODEWITHSUNDEEP
ruby-on-railshotwire-railsturbo-frames
Christopher Oezbek
Christopher Oezbek

Reputation: 26473

Rails Turbo Frames without partial?

I am new to Rails Turbo Frames, so I might be thinking about this all wrong.

I do have the following turbo frames, on one of my index pages shows an event which has a boolean attribute scheduled.

<%= turbo_frame_tag dom_id(event, :toggle) do %>
  <%= button_to event_path(event), method: :patch, params: { event: { schedule: !event.scheduled } }, class: "toggle-btn" do %>
    <%= event.scheduled ? "cancel event" : "schedule event" %>
  <% end %>
<% end %>

When the button is pressed, the event instance is updated correctly, but Rails shows "Content Missing" because the patch call does not return html with a turbo_frame_tag itself (right?).

How do I remedy this in the most economic way? Is there a way to tell rails that the turbo frame tag content just needs to be re-rendered with the updated event instance?

Do I really need a custom patch route, which renders a partial in a matching turbo_frame_tag (essentially the same as already in the index page)?

I was hoping not to use Turbo Stream for such a simple task.

Upvotes: 0

Views: 114

Answers (1)

janpeterka
janpeterka

Reputation: 641

As @alex wrote in comment, the recommended way would be to redirect to the correct page after your patch is finished.

Why?
Turbo should be progressive enhancement. So, it's a good practice to first write your code as if there's no turbo. What should happen after the patch in that case? Probably redirect_to index_path (or possibly redirect_back_or_to index_path). So, in simple request-response app without Turbo, this behaves correctly.
When we add Turbo and use turbo-frame to the mix, we will get user enhancement - only content of the turbo-frame will be changed, and we didn't need to do much.

Turbo 8 gives us optional morphing, which allows basically the same behavior without adding turbo-frame. It's worth looking into, as it creates the effect (content updates without "hard refresh" for user) without any further dev work (you don't need to specify turbo-frame, you don't have to worry about Content missing).

You asked about most economic way. I'm not sure what you mean by that.
The recommendation above is most economic in dev work and maintenance, and as reasonably fast for user, but if you want/need minimize data send over wire (not usually the case), you will need to put some more work into this - probably you will want to utilize Turbo Streams, so your patch request returns turbo-stream response with only the new content for replacement. To lear more about Turbo streams, read the Turbo Handbook.

So, to summarize:

  1. First write the app as you don't have any turbo - simple redirects
  2. Then choose which Turbo feature you want to utilize - morphing (no additional code, most magic), turbo-frame replacement from full response (only adding one turbo-frame), turbo-stream response (least data transfer, most added code).

Hope this helps. For me, Turbo is really great in making nicely interactive UI without much work, and with zero custom JS, but it takes some time to understand how everyting works. I read the Handbook multiple times, and some things clicked only after doing them in real (and some didn't yet).

Upvotes: 2

Related Questions