Feature Request: declarative connection to a Turbo Stream using the `turbo-stream` custom tag

Currently, some JavaScript is needed to connect a Turbo Stream to an EventSource (SSE) or WebSocket (by the way, the docs aren’t very clear about how to do this).

It would be superb if it could be done without JavaScript, rather using an incantation of the turbo-stream custom element.

Current imperative mechanism:

(window['EventSource'] && window['Turbo']) ?
  Turbo.connectStreamSource(new EventSource('/my-turbo-stream')) :
  console.warn('Turbo Streams over SSE not available');

Suggested declarative mechanism:

<turbo-stream src="/my-turbo-stream">

If the URL scheme was ws: then Turbo would create a new WebSocket, otherwise it would be an EventSource.

The addition of a src attribute to the custom turbo-stream tag need not (but may) be conflated with the use of it in directives to altering the DOM as content arrives on the stream or as the result of a form submission (i.e. the existing capabilities of the custom tag).

[seanpdoyle]

Thank you for sharing that code, I think we’re aligned now.

To re-contextualize a part of my original comment:

If your use case is outside of Rails, I’m interpreting the scope of the Issue as much larger, including the introduction of a backend agnostic version of the turbo-cable-stream-source.

I think we’re still discussing the details of a backend agnostic version of the turbo-cable-stream-source element. Based on your code sample, I’m interpreting that you’re suggesting the current turbo-stream element be extended. Is that correct?

I think overloading the element to behave differently based on the presence or absence of a src attribute could be tricky. Maybe a new turbo-stream-source element (like the Rails version, but without the “cable”) could serve that single purpose.

Is there something about extending the semantics and behavior of the existing turbo-stream element that’s more compelling than introducing a new element?

[delitescere]

I appreciate it might be tricky, indeed.

To me, it’s the same duality as “turbo-frame acting as a source” and “turbo-frame acting as a target”.

But if it were named slightly differently, that is less important than having it at all. Of course, as I’m not writing it, I defer to the developers to choose the smoothest implementation.

Much appreciated!

Also see https://link.medium.com/hcGxj0262jb for more (a lot more) context