turbo-streams

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.

Counters (likes, votes, bookmarks) are classic UI glue. I keep the counter itself in a small partial with a stable id and update it via turbo streams on create/destroy. The controller can render a turbo_stream.replace of the counter plus (optionally)