rails

Memoization is useful, but it should be scoped. Memoize within the instance/request, never globally. This is a simple way to avoid repeated expensive DB reads inside a view render.

Sorting is a great candidate for Turbo Frames: clicking “Newest” shouldn’t reload your whole page shell. I wrap the list in a frame (e.g., id='results') and make sort links target that frame. The controller reads params[:sort] and applies an order sco

If you have a queue table, avoid races by selecting and updating in one statement. Postgres UPDATE … RETURNING is the simplest building block for a correct custom queue / maintenance pipeline.

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(

Slug generation is deceptively racy under concurrency. Use a unique index plus retry with a suffix. Keep it deterministic and fast; don’t query in a loop without bounds.

Turbo Drive is great for internal navigation, but I disable it for external links or pages that should do a full reload (third-party auth, docs). data-turbo='false' is the simplest switch: it tells Turbo not to intercept the click, so the browser hand

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.

If you’re using importmap, a clean Stimulus setup matters: it keeps controllers discoverable and avoids mystery load order bugs. I pin @hotwired/turbo-rails and @hotwired/stimulus, then use controllers index discovery to register everything. The payof

In Hotwire apps, I still use Rails’ RESTful routes heavily. For destructive actions from a link, data-turbo-method='delete' is the cleanest approach: you keep semantic links where appropriate and let Turbo perform the method override. I usually pair i

Sometimes you need “only one runner globally” (backfills, refresh jobs). A Redis mutex with TTL avoids deadlocks if the process dies. It’s not perfect, but it’s a solid pragmatic tool.

You’ll eventually hit non-200 responses or network flakiness. Hook Turbo events to log failures (and optionally show a toast). This is a pragmatic production addition that helps debugging without adding heavy tooling.

Presence is often more about “who is here now” than perfect accuracy. Use Redis sets with expiries updated by pings. This keeps the system simple and operationally understandable.