Proof-of-concept: Introduce HTMX-based replacement for QuickSelect component in Maintenance tool #2883
Conversation
There was a problem hiding this comment.
There ought to be a naming convention for html templates that do not contain {% extends ..%}, that is: html fragments changing parts of a page, not an entire page.
Some possible naming conventions:
- Prefix with
_(single underline) - End with
-frag.html, not.html - End with
-partial.html, not.html
python/nav/web/maintenance/urls.py
Outdated
| @@ -32,6 +32,7 @@ | |||
| re_path(r'^active/$', views.active, name='maintenance-active'), | |||
| re_path(r'^planned/$', views.planned, name='maintenance-planned'), | |||
| re_path(r'^historic/$', views.historic, name='maintenance-historic'), | |||
| re_path(r'^search/$', views.component_search, name='maintenance-crazy-shit'), | |||
There was a problem hiding this comment.
Why stick with re_path? path is easier to read.
There was a problem hiding this comment.
I could ask you the same. I used the same pattern as the surrounding lines. They were all last modified by you as part of some Django upgrade, I believe :)
Since NAV never started out as a Django project, there has never been an explicit agreed-upon convention for this in NAV. I suspect a lot of this is pretty unused in NAV to distinguish fragments today, except for one subsystem: ipdevinfo uses the |
I don't have any particularly strong opinion on this one. But here are my thoughts:
The differences are minuscule IMO and are more a case of personal preferences. Unless we discover some more "technical" reasons to choose one over the other.. |
|
Discovered another naming variant used in NAV:
|
We might also consider some sort of "infinite-scroll" option that only loads a few items at a time, but reloads with new results when a filter has been entered. E.g. https://htmx.org/examples/infinite-scroll/ |
Loading all items, but limiting it with infinite scroll sounds like a good solution here. Then we also preserve the current functionality where user can browse all the items without entering at least 1 character. At the same time we will not overload our result list by default for cases when the list has many items. |
|
When it comes to naming convention for partials, we now have a poll #3368 |
lunkwill42
force-pushed
the
poc/maintenance-htmx
branch
from
f123d85 to
61af20b
Compare
|
Just rebased this on the latest master and squashed fixup commits, to get this up to snuff. Since we are already looking into other HTMX features like #3385, the two commits that introduce HTMX and Django-HTMX should probably be moved to a separate PR that others can be based off (and possibly the vendored in HTMX library should be replaced with a newer version) |
lunkwill42
added
the
nonews
lunkwill42
force-pushed
the
poc/maintenance-htmx
branch
from
61af20b to
925d05f
Compare
lunkwill42
force-pushed
the
poc/maintenance-htmx
branch
from
925d05f to
9832f3c
Compare
|
Cleaned up once more and moved HTMX introduction to a separate draft PR #3386 |
lunkwill42
force-pushed
the
poc/maintenance-htmx
branch
from
9832f3c to
534fb53
Compare
As mentioned in code review.
lunkwill42
force-pushed
the
poc/maintenance-htmx
branch
from
534fb53 to
148c1e1
Compare
|
|
TODO: actually replace the old search component with the new one |
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)