Apply different merge strategy per target about alpine-ajax HOT 4 CLOSED

No problem! You’re not the first to miss that detail, so if you have any suggestions for how we could improve that in the docs, I’d welcome a PR.

from alpine-ajax.

Hi, thanks for the kind words!
So the x-merge attribute actually belongs on the target element (not the requesting element) so that you can mix and match merge strategies. You can add x-merge=“append” to your list, and x-merge=“replace” to your form and you should be good to go. Since “replace” is the default you can leave the attribute off of the form and things will still work.

from alpine-ajax.

ohh, that's awesome, how did I miss that.. (probably because i'm used to htmx :P)
thanks for the quick reply, much appreciated

from alpine-ajax.

tbh, I was just looking at it again, and thought it's actually pretty clear in itself, only thing maybe is where it is on the page, maybe it should be closer to/merged with the x-target part somehow.
i'll try to propose something

Also to come back to my original question, I did test it and it didn't work, then I realised there are many more concepts here that are different to htmx which then requires different api choices.
For example, on that add resource use case, my api returns either

• on form error -> a FormError component (id='form-errors') with all the errors in it
• on success -> a ResourceItem component (id='resource-item-[id]' and a AddResourceForm component (id='resource-add')

so my x-target looks something like x-target='resource-add resource-list form-errors'

i ran into a few quirks:

• on form error: it while I can see the FormError component being returned with the correct id, it starts to display it but then it's removed from the page, along with other things. My assumption is that the lib acts this way because I am not sending back the other ids that the x-target is waiting for, hence replacing then with nothing?
• on success: the issue is that I am not sending back the list component, only the new item but then the lib obviously didn't know where to put it :) (was using the swap-out-of-band feature on htmx for that) reason is, I prefer to insert into DB and return, instead of insert, fetch entire list again and then return the list.

Again I assumed the lib would take whatever I send back and try to replace it and do nothing if not but it looks like it replaces targets with nothing if it can't find the id in the response. (edit: I checked the code and yes it makes sense as it does this to cater for a deletion scenario, I think)
Switching back to a regular redirect in the api then did the trick (for the success scenario).

Anyway :D
probably a lot of thoughts about how the behaviour of the lib could change based on that, but then you would probably just re-create htmx ahah
and I think it's more of a developer choice to embrace either htmx's paradigm, or your chosen paradigm which is more aligned with progressive enhancement and therefore wouldn't run into those issues mentioned (which are mostly due to adapting to another library and not the library itself)!

A last point on progressive enhancement, in your inline edit example, on a regular site, this would get the edit component from server and replace the view component. If JS is disabled, the edit component would be displayed without any styling, on a blank page. Is it acceptable behaviour for progressive enhancement? I guess better than nothing!
Or is the guideline to check requests headers to check if it's an Alpine AJAX request, and either return the component, and a full blown page otherwise ..? Or I guess just redirect to previous url and that covers all cases..
there's probably actual rule on that but curious to hear what you think :) (same and even more so for the toggle button example)

thanks!

from alpine-ajax.