| A few features which look minor but the author got totally right, which IMHO would allow this solution to scale very well with more complex applications. 1) X-Alpine-Target ```
<form method="post" action="/comments" x-target="comments comments_count"
``` generates an ajax request with this header by default: ```
X-Alpine-Target: comments comments_count
``` This is very very cool! In most usecases, one the serverside I can return a full html document and alpine-ajax will only look for #comments and #comments_count in the response. BUT, if I want the serverside to be faster (ie: do less), then the client is able to tell the server which parts of the html it wants via the `X-Alpine-Target` header -- instead of the server having to know which parts need updating via the url alone. It's like graphql for the htmx/hotwire architecture. 2) `ajax:missing`. If the client expects dom ids to be in the response and they aren't there, you can create a sentry error to expose the broken "contract" between the initial page's request and the action's response. 3) x-merge="append" In hotwire, the html markup is dumb and the turbo-stream response is smart (`turbo-stream action="append"`). But in alpine-ajax, the response is dumb and the html markup is smart (`x-merge="append">`). This difference is subtle, but it allows for the serverside responses (for actions) be more general purpose/discrete components, while the ux which might change from page-to-page or section-to-section is decoupled to that page's/section's container html. 4) x-sync "Elements with the x-sync attribute are updated whenever the server sends a matching element, even if the element isn't targeted with x-target." Wow - amazing developer ux for cross cutting concerns like notifications, flash messages, etc. So practical. 5) Creating demos with an alpine-ajax mock server.... wow, an out of the box way to make standalone component test pages. |