Some thoughts about turbo-frame-tags when the redirected render doesn't contain any turbo-frame-tags that match the original

[kobaltz]

Firstly and perhaps most importantly, thank you so much for Turbo. I really enjoy it!

Let's take a very simple example of a new Rails application with hotwire-rails created. We create a scaffold for products and within the form partial of the products, we wrap the form elements in a turbo_frame_tag 'product'. The expected behavior now is if there are any validation errors, it renders the page with the validation errors. Turbo accomplishes this already.

However, if there are no validation errors and the record persists successfully, then I would expect it to render the display of the show page. However, because there is no turbo-frame-tag on the show page, it doesn't do anything and we still have the form displayed.

I think that this is very unexpected behavior even though things make sense with turbo. I know that this functionality has caused me a few headaches initially and also the community with trying to find proper workarounds.

I'm not the best Javascript person out there, but dabbled around in it a bit, so I would leave any PR to the experts. However, I did pull in the turbo library from turbo-rails into my application to tinker with things and came up with a minor-ish fix.

Within the FrameController class, I modified the loadResponse function. I added the const html which before was simply inside of the fragmentFromHTML, but the important bit is the else statement. It looks like the element is the rendered result from our Rails application and the turbo-frame-tag has been plucked out as a fragment of the original rendered response. So, if no element is found, then that means that the rendered page did not have any turbo-frame-tags which means that our UI will look like it did not perform any action.

My thought here is to replace the body of the current page, with the entire contents of the rendered response in the event that no turbo-frame-tag was found within the response.

  async loadResponse(response) {
    const html = await response.responseHTML
    const fragment = fragmentFromHTML(html);
    const element = await this.extractForeignFrameElement(fragment);
    if (element) {
      await nextAnimationFrame();
      this.loadFrameElement(element);
      this.scrollFrameIntoView(element);
      await nextAnimationFrame();
      this.focusFirstAutofocusableElement();
    } else {
      document.getElementsByTagName("html")[0].innerHTML = html
    }
  }

[sstephenson]

Thanks for opening this issue! What we intend to do when there's no matching frame in the response is to empty out the frame's contents and log a message to the console. Hoping to get that in for the next beta.

[kobaltz]

Thanks for the quick response @sstephenson! I wonder if there could be an option which would default to the functionality as you're describing, but a configuration override which would render the response and update the history. It seems like this would give best of both worlds.

[sstephenson]

It's an interesting idea, but I think it's more important to preserve the contract that navigation in a frame stays in the frame unless you explicitly opt out with target="_top" or data-turbo-frame.

Generally we avoid configuration options unless we have no other choice. But I'd be open to adding any special hooks necessary to allow you to implement this outside of Turbo.

[kobaltz]

That's understandable. And I think having some hooks would be sufficient if we also got the responseHTML along with some indication of the element being found or not (the DOM was updated with a new turbo-frame-tag). We could then probably use the turbo:submit-end to load the view and update the history if the event indicates that no changes were made on the page.