Add functionality to remove element from dom

[tito10047]

Q	A
Bug fix?	no
New feature?	yes
Issues	Fix #2007
License	MIT

Add ability to remove element from dom passing the header to response

#[AsLiveComponent()]
final class Component
{
	use DefaultActionTrait;

	#[LiveAction]
	public function removeFromDom() :Response{
                $response = new Response(null);
                $response->headers->set('X-Live-Delete', '1');
                return $response;
	}
}

[tito10047]

Please be patient with this PR, I'm new to the open source world and this library is huge. But I'm big fan of it and wan't to join.
So I need little help.
How I can create tests for this feature? I haven't found anything similar in the library

[javiereguiluz]

@tito10047 this feature request looks like reinventing Turbo streams inside Stimulus.

Turbo Streams allow to add/remove/replace/update/prepend/append content to existing page elements. See https://symfony.com/bundles/ux-turbo/current/index.html and also the original Turbo docs: https://turbo.hotwired.dev/

[tito10047]

@javiereguiluz yes, but all twig live components is about reinventing turbo. Twig live components is about add/replace/update/append content. bud I only miss there "remove" and this PR is about that

[kbond]

I think this does make sense. Internally we've also talked about a renderless response: an empty response that tells the frontend to do nothing. We're thinking about a custom LiveResponse extends Response that we could ship with live components. I think we could use this new object to help with some of the verbosity of the proposal here:

// in a component live action

return LiveResponse::delete();

[smnandre]

Yep this is something we talked about with @dejagersh

• pure renderless responses
• delete responses

But also "json response" (pure data/model, without HTML)... even if it seems to be another subject with very specific implementation challenges

If we talk 'http status codes', all this could be very fun :)

• 202 could handle async backend operation with some auto-poll-check system
• 204 also makes sense here (when deleting a child / LiveProp collection item
• 205 could force children to refresh
• 206 could return only a part / block (i'd love this)