Add the ability to specify '_none' as a target

[justisr]

This change adds the "_none" target, which can be used to tell Alpine Ajax that you don't want to reload the page or modify the DOM, you just want to send the request (likely a POST request), and stay on the page you're already on.

Also added some tests for it.

[justisr]

Any thoughts on this @imacrayon?

The use case that inspired this for me is the fact that redirects are followed transparently, and wanting to manually redirect the user after a brief period. Specifically, a user clicks "Save" and the form flashes a message saying "Changes saved. Redirecting..." then redirects them to the resulting page with their modifications. The way this is achieved with a framework I previously worked with is returning a json response containing the status, a flash message, and a url to redirect to.
Since all this is handled with javascript, we don't need to target an html element nor do we want to refresh the page.

A simpler imagined use case is just wanting to call a javascript method flashSavedMessage() whenever a POST is returned successfully, or any other sort of behavior that already exists in the client and doesn't inject html from the response body.

[imacrayon]

Hey! Thanks for following up with some examples, that helps me wrap my head around this a little more.
I’m still torn on accepting this: It would push state management back to the frontend which is something I’m not keen on encouraging. But, it could also be useful as a kind of “escape hatch” in some situations.
My rule of thumb so far has been to make the “good” way to do things a part of the HTML API and the more “client-side-state” things available in the JavaScript API. I wonder if this functionality should instead exist on the JS side of things? Like we could expose a function primitive to issue a requests and another primitive to merge content on the page.

[justisr]

I'm sure that _none would be the go-to tool for people already wanting to do state management in the client, although "encourages" might be a strong word for it.

Imagine you've got a page full of toggle switches for notification preferences, and you just want to auto-save any changes. There's no need to request the page again every time the user toggles a switch since your page already looks the way you want it to. You can just send an ajax post request and as long as you don't get an error response, you're good.

Maybe exposing function primitives is the way to go though, so we can split the tool chain into the individual tools we need. My only real complaint would be that I wouldn't be able to use the x-target.status format to concisely achieve the functionality I want, because if any of the possible status responses should behave like _none, then whole thing needs to be re-created using the function primitives, even if the other status responses would use the default Alpine Ajax behavior.

I can't say I mind too much either way though. As long as an escape hatch is available, I think the implementation of it should depend on your goals for the project.

[imacrayon]

Ok, you convinced me. Thanks for your patience with this!