Ability to override frame-target from server response

Currently if the response from turbo requests returns a redirect response whilst inside a frame, there is no way for the server side to conditionally control what turbo to do with the response, eg. force a full page refresh with target=“_top”

There are use cases especailly for modal windows where upon succesful save we would want to perform a redirect back to the index page, where as 422 response would do the normal turbo frame replacement within current frame.

It would be nice to support something like this, which will allow us to control targets from serverside to frame targets by setting frame target via the http response headers.

 if @record.save
  response.headers["Turbo-Frame"] = "_top"
  redirect_to settings_locations_url
else
  render partial: 'form', status: :unprocessable_entity
end

What everyones thoughts are on this? or is there something I am missing to make this easier.

[dhh]

Reviewing all this, it seems like we have a wide array of interesting edge cases, but also a base case where I think our current default is just bad. If a request originates from within a frame, and the response to that request doesn’t include a matching frame, then I think we should just break out of the frame. Either replacing the entire page or following the redirect. I think that’s a better default, it doesn’t break something that isn’t broken already, and it’ll solve the majority of the issues here.

Happy to take a PR to that effect.

[didroe]

I’m interested in a solution to this issue, for the use case of implementing modals containing forms. Where sometimes you want to re-render the modal with new/error content, and sometimes redirect the whole page. But you don’t know until you’re on the backend which path you want to take.

Adding support for the server to control the target frame feels like the right solution - it’s way more flexible than the client interpreting certain status codes (ie. https://github.com/hotwired/turbo/pull/210), and is less convoluted than disabling the frame and implementing a frame-missing handler. Being able to specify the target frame feels like a simple mechanism that can address a large number of use cases, and it’s ultimately the server that knows how a rendered view should be interpreted. Other features could then be built on top at the server end, to give a good out-of-the-box experience. eg. 303/500 defaulting to targetting _top.

A header seems the cleanest and most simple implementation to me. Turbo itself need only support the header, it can leave it up to the server to pass the target frame through the redirect by whatever means it likes. Personally, I think a query param could be a good solution for passing the target through. I explored a possible implementation of this on this branch. As the redirect is opaque to the client, no handling of query params would be necessary in Turbo itself (as it would never see the redirected URL).

In a future world, we might hope that whatwg adds a way to expose particular headers from the initial/redirected response. And then the query param workaround could be dropped in favour of that mechanism.