Dispatch datastar-fetch events from the element that creates them

[gazpachoking]

Feature Request

The ergonomics of using datastar-fetch events would be improved quite a bit by dispatching them from the element where they are created. Currently you have to do a check in any handler for the event that evt.detail.el == el to filter instead of using the standard event bubbling of the html spec.

This was done previously in #761, but was later reverted due to #802, where streams would stop working after the element that initiated them was removed from the page. This should no longer be a concern though, as it will be a feature that the stream is cancelled when the element is removed rather than a bug starting in RC.6.

Datastar Version

v1.0.0-RC.5

[bencroker]

We’re using mutation observer, which reports when the element has been removed from the parent’s childList. At that point, el is detached but still alive in memory. So while this may be possible, we’d have to be careful to ensure that there aren’t any ramifications. For that reason, we can visit after RC.6 is out.

[gazpachoking]

Sounds good. A couple other situations that might cause issues: User is using their own abort controller. One of the elements ancestors get removed from the dom.
Ideally it would fall back to dispatching from the document. I'll do some testing once rc6 is out.

[tv42]

This would be very helpful. Currently I have to resort to a workaround like this:

document.addEventListener("datastar-fetch",e=>{
    e.detail.el?.dispatchEvent(
        new CustomEvent(`fetch-${e.detail.type}`,{detail:e.detail,bubbles:true})
    )
});

[bencroker]

@tv42 please provide details as to why this would be useful in your specific use-case.

[tv42]

It's the best way I've found so far for providing error etc feedback in the UI at the right place.
The page contains multiple of these kinds of forms, global errors and toasts are just wrong.

form #create_foo_form
    data-indicator="_create_foo__busy"
    data-on:submit="@post'create_foo', {contentType: 'form'})"
    data-on:fetch-started="$_create_foo__error = undefined"
    data-on:fetch-error="$_create_foo__error = evt.detail.argsRaw.status"
    {
        div {
            label for="name" { "Name" }
            input #name
                name="name"
                type="text"
                placeholder="Name of the foo create"
                required;
            // per-field errors would go here if you had them
        }
        // repeat for more fields
        footer {
            button type="submit"
                data-attr:aria-busy="$_create_foo__busy"
                data-attr:disabled="$_create_foo__busy"
                data-busy-text="Creating..."
                { "Create" }
            span
                .error
                style="display:none"
                data-show="$_create_foo__error"
            {
                "Request failed (status "
                    span data-text="$_create_foo__error" {}
                ")."
            }
        }
}

[bencroker]

I'll do some testing once rc6 is out.

@gazpachoking have you had a chance to test this since?

[gazpachoking]

@gazpachoking have you had a chance to test this since?

I haven't tested since. The changes I was mentioning in RC6 don't actually matter much though, since it's was only one of the possible scenario (and were reverted as the default since then.) I do think the method in my PR is still valid though, it dispatches on the element if the element isConnected, otherwise falls back to dispatching from the document. Since the event bubbles, the datastar event listener on the document should catch it either way.