Proper resource architecture with Hotwire8 and Morphing

In a plain old Rails app using Server-Side Rendering (SSR), the architectural approach for a standard resource is clear – you use a standard scaffold. Conceptually straightforward, but from a usability standpoint, it hasn’t been up to date for 13 years.

With Hotwire, Turbo Frames, and Turbo Streams, there was no real need to change the initial architectural approach, as one could build an application with a modern UX based on a previously generated scaffold. A technically perfect approach to this was demonstrated by Alexander Ruban with his Quotes App.

To generate a new record, the form is rendered via a Turbo Frame above the resource index. For in-place edit operations, Turbo Stream Actions are used. The architectural approach here is clear, as the required partials can simply be pushed asynchronously into the client, and rendered wherever desired.

What is unclear to me is, what an architectural approach for a resource design with Hotwire8 and Morphing might look like. The promise is that you “simply” build an SSR application in the backend, and the DOM is automatically, optimally updated in the frontend via Morphing.

But if I think about recreating Alexander’s Quotes App, I quickly reach the limits of a clean architecture (or my understanding). The user clicks the New button in the index and expects the form to be rendered above the index of records. This could still be solved by having the new partial simply render the index below it. The user lands on the /new route and is redirected to / after saving. That works but is everything but beautiful.

However, for implementing in-place editing, I could also send the user to /:id/edit for the edit action, render the index there below the form, and (complexly) render the corresponding record in an inline form. This works but is unsightly and falls apart if the user wants to edit multiple records simultaneously in the frontend – as possible with Alexanders demo.

Extending this approach further, one would need to completely replicate the functionality of modern SPA applications via SSR, and then let Hotwire handle the frontend update. This becomes impractical so quickly, that I assume I just haven’t understood the concept.

Can someone enlighten me - especially in relation to the above example?