Cancel requests when element is removed

[wmTJc9IK0Q]

This makes it so that when requestCancellation is auto and the element that initiated the request is removed, the request will now be cancelled. Otherwise open SSE requests keep getting new events and patching elements that shouldn't be and resources are not released causing memory leaks.

[wmTJc9IK0Q]

Since actions can return values to callers, I needed to add a new context API that allow setting a cleanup based on a key. The key can't be auto-set to the action name because there could be different fetch actions used on the same element and we only want to keep the removalFn for the last fetch action.

[romshark]

I faced a problem today (see Discord thread) and it seems this change is addressing it.

I wanted to bind an SSE connection to a particular view, and once that view is morphed away or replaced the SSE connection would reset. Currently it just keeps creating more SSE connections on every page transition. I kept wondering why my app is bugging out, turns out it was the multiple SSE connections patch-racing.

[wmTJc9IK0Q]

@wmTJc9IK0Q Yes that is similar to my use case. I have an SSE endpoint that powers a specific server-side component and pushes updates to it. Whenever the parent component removes this child component I want the requests to stop and no more patching of elements.

[romshark]

Maybe, for reasons I currently don't see, it makes sense to allow the old behavior through an option still:

<div id="t" data-on-load="@get('/stream', {detach: true})"></div>

Detaching means it won't get canceled if t is removed from the DOM.

But it definitely makes sense to make cancelation the new default behavior. If you want to keep an SSE stream triggered by an element, keep that element. Current behavior is rather counterintuitive and potentially dangerous (memory leaks, patch races).

[bencroker]

Thanks for the PR. We need to discuss internally if and how we want to handle this.

[wmTJc9IK0Q]

@bencroker Anything I can do to move this forward?

[bencroker]

Not really. We've been busy and haven't come to a decision on this yet.