turbo-streams

Admin toggles (published/unpublished, featured/unfeatured) are a perfect Hotwire use case: server-rendered state, instant UI update. I render the toggle as a partial inside a frame, and the update action responds with a turbo stream replacing that fra

For forms with multiple fields, I like an error summary at the top. With Turbo Streams, you can update just the summary target when validation fails. This is helpful when the form is long and the user might not see inline errors immediately. The serve

Turbo Stream updates are easiest when every meaningful element has a stable id. Rails’ dom_id helper makes this painless: dom_id(@post) yields post_123, and dom_id(@post, :header) yields header_post_123. I use this pattern throughout Hotwire UIs so I

After a successful inline create, I usually want to clear the form. You can replace the whole form partial, but sometimes you want to preserve other state (like which field was focused) and simply reset values. A clean Hotwire approach is a custom Tur

For a notifications dropdown, I keep the list server-rendered and let Turbo Streams keep it fresh. The dropdown content sits in a turbo_frame_tag (so you can also navigate to a full notifications page), and the unread badge is a separate small target

A good Hotwire endpoint responds to both Turbo and non-Turbo clients. Use respond_to and render a turbo stream that prepends the new record and updates flash/errors, while keeping an HTML fallback for crawlers, redirects, and manual testing.

Flash updates are common enough to deserve a first-class stream action. Defining a custom turbo-stream action keeps views tidy: instead of repeating turbo_stream.update, you can write <turbo-stream action="flash">.

A “follow” button usually needs two updates: the button label/state and the follower count. Turbo Streams make this trivial because one server response can carry multiple DOM operations. I render both UI pieces as partials with stable targets (dom_id(

Sometimes you want to “redirect” from a turbo stream response (especially for Turbo Native flows). Returning a stream that updates a frame to include a turbo-visit shim keeps behavior consistent across clients.

Drag-and-drop reorder can be fancy, but the core is: user triggers a reorder action, server persists positions, and the UI updates. For simpler UIs, I skip drag-and-drop and use up/down buttons. Each click POSTs to a move_up action, updates position,

Instead of sprinkling custom JS for notifications, I treat flash as UI state and render it via Turbo Streams. When a create/update succeeds, the controller responds to format.turbo_stream and the template uses turbo_stream.replace to swap the flash co

When updates can happen from multiple places, model-level broadcasts keep the UI consistent across tabs without sprinkling stream logic in controllers. Use after-commit hooks so broadcasts only occur once the write is durable.