loading states: Respect path filter in processing undo callbacks #2297
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The loading-states extension queues up callbacks on
htmx:beforeRequest
. Onhtmx:beforeOnLoad
it executes any undo callbacks thatmayProcessUndoCallback
allows.mayProcessUndoCallback
only checks for the existence of the target.Suppose we have multiple requests in flight. We use
data-loading-path
to only have matching requests modify the loading states of target elements. While attaching loading states can be filtered, removing loading states always succeeds as the undo queue is drained onhtmx:beforeOnLoad
.This means that target elements are marked as loaded even though their requests are still in flight.
This change passes the request path to
mayProcessUndoCallback
to allow for delayed execution of undo callbacks when a path filter is available.Corresponding issue: #2296
Testing
I tested this manually with a test page that would trigger multiple requests, served by a backend that introduces random delays to the responses. I used the loading states extension and only set up
data-loading-aria-busy
on target elements. With this change those elements whose requests were still in flight would remain inaria-busy
state, while those whose requests were completed would have the attribute removed.Without the change any completed request would cause the removal of
aria-busy
from all elements, even if their requests were still in flight.Checklist
master
for website changes,dev
forsource changes)
approved via an issue
npm run test
) and verified that it succeeded