Support FrameElement.reload() without an initial [src] attribute

[seanpdoyle]

The problem

If a <turbo-frame> element is rendered without a [src] attribute,
calls to .reload() will have no effect. If a <turbo-frame> is to be
its own browsing context, it should be able to apply its current
location (that is, it's owning document's current location) to its
browsing context.

For example, if a page has a <turbo-frame> element that contains text
that's typically updated by a Web Socket-delivered <turbo-stream>, it
might be useful to gracefully degrade to periodic long-polling if
that Web Socket connection were to fail. That might involve something
like a reload Stimulus controller with a delay:

<script type="module">
import { Application, Controller } from "@hotwired/stimulus"

const application = // boot up a Stimulus application

application.register("reload", class extends Controller {
  static values = { frequency: Number }

  disconnect() {
    this.#reset()
  }

  frequencyValueChanged(frequencyInMilliseconds) {
    this.#reset()

    if (frequencyInMilliseconds) {
      this.intervalID = setInterval(() => this.element.reload(), frequencyInMilliseconds)
    }
  }

  #reset() {
    if (this.intervalID) clearInterval(this.intervalID)
  }
})
</script>

<turbo-frame id="dynamic-data" data-controller="reload" data-reload-frequency-value="30000">
  <h1>This data will refresh every 30 seconds</h1>
</turbo-frame>

The fact that the <turbo-frame id="dynamic-data"> element doesn't have
a [src] attribute shouldn't prevent the page from being able to
re-fetch its content.

The solution

When FrameElement.reload() is invoked, it delegates to its delegate
instance's sourceURLReloaded() method. In all cases,
FrameElement.delegate is an instance of FrameController.

This commit extends the FrameController.sourceURLReloaded()
implementation to set the element's [src] attribute to the element's
baseURI value, which sets off the usual attribute change listeners
and <turbo-frame> navigation logic.

[afcapel]

In the specific example in the PR, you could also set the turbo frame src attribute before the reload:

    if (frequencyInMilliseconds) {
      this.element.src ||= this.element.baseURI
      this.intervalID = setInterval(() => this.element.reload(), frequencyInMilliseconds)
    }

I feel that setting the src makes it easier to see that the frame is a remote frame and where it came from. For example, we have some changes in the pipeline that rely on the presence of the src attribute to identify remote frames.

[seanpdoyle]

@afcapel that's the exact solution we're using to work around the current constraints!

Is the separation between "remote" and "local" frames something that we'll need to document?

If we aren't interested in this change, would it be worth adding this solution to be part of the Turbo Frame reload() documentation?