The issue with use_full_path is that it is only initialized on page load and does not automatically update afterward. This means that if the URL’s GET parameters change during the session (for example, when HTMX updates the browser URL), use_full_path will still point to the original path from the initial page load instead of the new, current path.
As a result, any requests that rely on use_full_path will use outdated query parameters, leading to incorrect or unexpected behavior.
To fix this, you need to ensure that whenever an HTMX request updates the URL, the element using use_full_path is also swapped in the same request. This forces it to reset and pick up the new full path from the browser.
In practice, the way to use it:
Dynamic / URL-changing triggers – If GET parameters are expected to change (e.g., pagination, filtering, search), then you must make sure the element depending on use_full_path gets reloaded as part of each HTMX swap, so it stays in sync with the browser’s URL.
The issue with use_full_path is that it is only initialized on page load and does not automatically update afterward. This means that if the URL’s GET parameters change during the session (for example, when HTMX updates the browser URL), use_full_path will still point to the original path from the initial page load instead of the new, current path.
As a result, any requests that rely on use_full_path will use outdated query parameters, leading to incorrect or unexpected behavior.
To fix this, you need to ensure that whenever an HTMX request updates the URL, the element using use_full_path is also swapped in the same request. This forces it to reset and pick up the new full path from the browser.
In practice, the way to use it:
Dynamic / URL-changing triggers – If GET parameters are expected to change (e.g., pagination, filtering, search), then you must make sure the element depending on use_full_path gets reloaded as part of each HTMX swap, so it stays in sync with the browser’s URL.