Subtle interaction between node replacement and turbograft:remote:always

[patrickdonovan]

I was trying to add a listener to a form to take some action on turbograft:remote:always, (after completion of the submitting of that form, one way or another), and it was not working for me. The reason was that the form was being replaced by a partial refresh, and the event listener was being cleaned up (maybe by twine?) before turbograft:remote:always had fired.

I was able to achieve the behavior I was looking for with listening on 'turbograft:remote:success turbograft:remote:fail' which both fire before the cleanup has occurred, but perhaps loadend is too late for turbograft:remote:always?

@qq99

[qq99]

Agreed, I wonder about the naming for event(s), maybe these concepts?

1. After the XHR is done, after the replacements and whatnot are done (:= complete?)
2. After the XHR is done, but before any replacements are done (:= always?)

[marutypes]

Keeping always the same means it won't break anything we've already built that might be expecting this behaviour, but I sort of feel like those names are counterintuitive.

• always feels like it should basically be sugar for being both success and fail
• complete sounds more like it would occur after replacements

Not sure how much that behaviour change would break though :(