CODEWITHSUNDEEP
ruby-on-railshotwire-railsruby-on-rails-7
richleenyc
richleenyc

Reputation: 129

Best practice: Ok to render Turbo Stream response only? Or always include standard HTML response?

Is it best practice to keep both format.html and format.turbo_stream responses in the respond_to block for ALL controller responses? Is there any scenario where it is safe to only include a turbo_stream response?

The Hotwire documentation states:

It’s good practice to start your interaction design without Turbo Streams. Make the entire application work as it would if Turbo Streams were not available, then layer them on as a level-up. This means you won’t come to rely on the updates for flows that need to work in native applications or elsewhere without them.

The same is especially true for WebSocket updates. On poor connections, or if there are server issues, your WebSocket may well get disconnected. If the application is designed to work without it, it’ll be more resilient.

I am assuming this means we should always have non-Turbo Stream responses, error-handlings, etc. as a fallback?

I successfully implemented Turbo Streams in one of my #index pages. I have a table with rows representing each model in the collection, with action buttons in each row that would let the user update the model. Previously, the buttons linked to separate #edit form pages, and then the standard CRUD flow for #show, error handling, etc. Now with Turbo Streams the user can update rows without leaving the #index table view. It's terrific. I'm was hoping to get rid of the old view pages, but wondering if I need to keep them around as a fallback.

Upvotes: 9

Views: 2810

Answers (1)

aidan
aidan

Reputation: 1795

TLDR: there is no "best practice" that applies to all possible controller actions. It depends on your desired interaction. If you only want to update part of your page, use Turbo. If you want a full-page reload, use HTML. Is it valid to have both? Absolutely. Are there scenarios where you should use only one? Absolutely.

Let's start with a important clarification: Turbo does not supersede HTML or JSON responses from your server. Turbo, HTML, and JSON responses are three different things, and they support different types of server/client interaction. Turbo is sort of meant to replace JSON responses that feed into single page apps, but AFAIK no one writes Turbo inside of a React application.

So what's the Hotwire documentation talking about?

The Rails community generally encourages doing HTML-first design as a best practice because it can help to achieve progressive enhancement/graceful degradation (which are very important).

Examples

An example which includes both: You build a basic user profile/settings page, where user can update their email. This would be handled by something like UsersController#update, and can absolutely have both a Turbo and HTML response.

  • Turbo response sends an update just for the form element, updating the UI in-place
  • HTML response renders the whole page, not just the form element. If your user can't get WS to connect, when they submit the form they can still get an appropriate page update.

A Turbo-only example: You build a page to show all team members. That page itself is likely rendered as a full-page HTML response, in a different controller action, typically UsersController#index. When a user updates their email, perhaps you want propagate this update to the list of team members so other users see it in real-time.

  • Either in UsersController#update or in User model class, you can broadcast Turbo responses (not in scope for this question) to anywhere in your app, including this index page. The Turbo response would update just the one row of the user who updated their email.
  • There is no equivalent HTML response for this. Any user without WS connection just has to refresh the page to see this update.

Upvotes: 6

Related Questions