# Using \`advance\` turbo action to update the query string only, not the path? **URL:** \ **Category:** General\ **Created:** [April 21, 2023, 10:50am UTC](https://discuss.hotwired.dev/t/using-advance-turbo-action-to-update-the-query-string-only-not-the-path/4988 "2023-04-21T10:50:03Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![bebbs](https://avatars.discourse-cdn.com/v4/letter/b/ecae2f/32.png) [@bebbs](https://discuss.hotwired.dev/u/bebbs)\ **Post date:** [April 21, 2023, 10:50am UTC](https://discuss.hotwired.dev/t/using-advance-turbo-action-to-update-the-query-string-only-not-the-path/4988/1 "2023-04-21T10:50:03Z")
Hello, I’m looking for advice on structuring turbo frames and a form so that I can filter some results, and store the state in the query string, **without** affecting the path of the current page. We have a couple of routes and turbo frames for a result filtering style experience: - `/index` - a lightweight ‘shell’ that loads very quickly without any expensive fetches, SPA-style. - The index page contains a `filters` turbo frame with a form for filtering, and a `results` frame with a `src` of `/results`. Results are computationally expensive, hence the separate frame and route to keep the initial page load fast. Interacting with the filter form sets the `src` of the `results` frame, to trigger fetching results. ```auto
``` This is nice as the query string is updated when the user interacts with the filtering form, thanks to the `data-turbo-action="advance"`, but the issue is that it sets the whole path to `/results?x=y`, as that is the target of the form, whereas I’d like to always keep the user on `/index?x=y`. I’d like a solution that: - Always keeps the URL consistently `/index`, never changes it to `/results` - Keeps the query string / history in the browser in sync with the users interactions with the form - Triggers fetching the new results when the user interacts with the filtering form. - Ideally I don’t have to re-render the `filters` frame, as it has some UI state like opening dropdowns that should be persisted as the user interacts with the form. The only option I can think of is not setting `turbo-action` on the form, and using some JS in a stimulus controller to push a navigation event and update the query string, but I’m hoping there’s a more idiomatic turbo way of achieving this? I’m open to restructuring the turbo frames completely if there’s a better way. ---
**Author:** ![markhealey](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/markhealey/32/3031_2.png) [@markhealey](https://discuss.hotwired.dev/u/markhealey)\ **Post date:** [April 27, 2023, 3:47pm UTC](https://discuss.hotwired.dev/t/using-advance-turbo-action-to-update-the-query-string-only-not-the-path/4988/2 "2023-04-27T15:47:01Z")
I tried to programmatically write to the URL/turbo state but could not get it to work > [@Programmatic write to Turbo history](https://discuss.hotwired.dev/t/programmatic-write-to-turbo-history/4639): > > I have a fully functioning Turbo-powered site with everything working great except one single page which is powered by a non-Turbo stream API. It’s a legacy page with a handful of Handlebars templates. This, too, works really well given the legacy code being plugged in…but every time a handlebars template is rendered, the URL is updated with the latest API state. It is here I need to write to the Turbo history stack. Using the browser back/forward buttons to navigate pre-Turbo would rely on a p… ---
**Author:** ![BenNadel](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/bennadel/32/3067_2.png) [@BenNadel](https://discuss.hotwired.dev/u/BenNadel)\ **Post date:** [April 28, 2023, 9:52am UTC](https://discuss.hotwired.dev/t/using-advance-turbo-action-to-update-the-query-string-only-not-the-path/4988/3 "2023-04-28T09:52:08Z")
I don’t have anything to contribute here, only to say that I’ve also been thinking about the same problem. The Turbo Drive history works really well when the page is “flat” and all navigations are related. But, the moment you have a secondary layer (ex, fly-out, modal window, complex aside), having all navigations tied to the _entire URL_ is a point of friction. In Angular, they have “auxiliary” routes where you can literally have multiple routable areas operating at the same time. In AngularJS (pre-auxiliary routes), I have done something similar to what you are saying, but I have to do it all manually in the JavaScript. But, instead of programmatically updating the `History` API, what I’ll do is when the sub-view renders, I’ll pre-compute the link-URLs in the page to build off of what is _already in the address bar_. Now, in Angular, this isn’t really _that complicated_ because all the rendering is client-side. So, it’s easy to see which URL is already loaded. However, with Hotwire, that secondary view is delivered by the **server**. And, the server has no sense of what URL is already rendered by the primary view. And, this is where I usually give up and stop thinking about it. ☹ Anyway, I just wanted to say that the struggle is real and I can related. Unfortunately, I don’t have much to add.