Open Related and click a link inside it.

The sidebar is a frame, and its links point at individual messages. Click one: Turbo tries to load /messages/1 into the sidebar, and that page has no sidebar frame. Content missing, again, but this time the fix isn't on the server.

The frame's links are meant to leave. Say so on the frame:

<%= turbo_frame_tag "sidebar", src: related_path, target: "_top" %>

Now every link inside drives the whole page. Flip it, click again.

The reverse: a link that isn't in the frame, but wants to drive it.

<a href="/messages/2/edit" data-turbo-frame="message_2">edit Tom's message</a>

There's a link like that above the list now. Click it: the edit form appears inside Tom's frame, though the link lives outside it. data-turbo-frame works on links, forms, and submit buttons, and takes a frame id, _top, or _self.

This is how a "New message" button in a header opens a form inside a frame at the top of the list, or how a form outside a frame refreshes one.

Frames don't touch the address bar. Unless you ask.

Click edit and look at the URL: still /messages. That's usually right. For pagination or tabs, though, you want Back to work and the URL to be shareable:

<turbo-frame id="message_2" data-turbo-action="advance">

Now a navigation inside the frame also pushes the frame's new URL into history. Flip it, click edit, and watch the address bar. Reload that URL and you get the edit page on its own, so the server has to render the whole page from the URL alone. It already does. That's what dual-purpose bought you.