Proof-of-concept: Introduce HTMX-based replacement for QuickSelect component in Maintenance tool #2883
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.
This is related to both #2639 and #2251 .
It's a very crude start to a PoC that can potentially replace the b0rked QuickSelect component used in the Maintenance tool. The QuickSelect component is also used by the IP Device History tool, and could be replaced also there once complete.
Quick explanation, for now: The QuickSelect component is pre-populated with all netboxes, locations, rooms, services, etc. from NAV, and is consequently output into the resulting HTML of the maintenance task edit form. From that HTML, QuickSelect's JavaScript counterpart allows the user to filter form values from this potentially giant list of stuff. This is exactly why the page load times can grow very long in big NAV installs, as mentioned in #2251. It will grow even bigger if we add an option to put interfaces on maintenance, which is a feature that has been suggested to us.
This PR intends to demonstrate how to use HTMX to dynamically look up maintenance components by having the backend do the searching and return fully formed HTML with the results. The potential downside to this approach is that there will be no initial scrollable list of all components: The user must enter at least a single letter search query to see any selectable components. This might still be preferable to loading "everything" from the database into an HTML fragment (this is equivalent to the API strategy that refuses to return all the millions of ARP entries when no arguments are given to the endpoint)