Turbo link inside frame not updates browser history and url

1

Hi there. I’m trying to get familair with Turbo and am running into an issue. Maybe someone can help me with this.

When I navigate using a normal link (outside a turbo-frame), a Turbo visit is performed. The content is loaded via turbo and the browser history and url are updated.

When I navigate using a normal link, inside a turbo frame, a Turbo visit is performed, but the browser history and url are not updated. I have the following setup and use the link in the second turbo-frame (box2).

<turbo-frame id="main-container">
    <turbo-frame id="box1">
        <!-- content here -->
    </turbo-frame>

    <turbo-frame id="box2">
        <a href="/orders/12345">Load new data in main-container using Turbo</a>
    </turbo-frame>
</turbo-frame>

With adding target="_top" a full reload will be initiated and that’s not what I want. With data-turbo-frame=“main-container” the browers history is still not updated.

1 Like
2

Frames do not update the browser history by design. I was also surprised by this when I was first exploring Turbo Frames. I think my surprise was based on assumptions/expectations instilled by previous experience with client side routers in React and Ember.

It’s a different way of thinking. The mental model I’ve established, is that urls represent “screens” of my application, and frames represent different pieces that make up that screen. I think this falls inline with the Turbo Handbook’s description of decompose with Turbo Frame. If it warrants a URL change, it represents another screen in my application.

1 Like
3

Worth noting that there’s a PR being considered to allow frames to change the URL: Optionally update URLs on Frame navigation and stream responses by bfitch · Pull Request #167 · hotwired/turbo · GitHub

1 Like
4

Thanks for the clear explanation danott. I can follow your mental model, but the model I had in mind was the story of DHH where he explained how they made Basecamp fast. In my words, they load the whole page once and further on navigate through turbo requests. When loading a screen (url) you don’t need to re-load the javascripts and layout again.

5

Interesting dan, what’s the possible downside of this? because the PR is being considered.

6

I’m not sure there are any downsides per se. The open questions are about whether this functionality should exist.

My initial reaction — not that it’s up to me if this makes it in or not — was the same as danott’s, that you shouldn’t use frames to update the URL. But lots of people on here and also on GitHub have run into this issue quite a bit, with a few different use cases. It is, at the very least, worth considering imo.

7

you can use this to get the desired behavior

2 Likes