Refactor dashboard navlets to use HTMX#3634
Conversation
Test results 27 files 27 suites 45m 17s ⏱️ For more details on these errors, see this check. Results for commit b92a2a9. ♻️ This comment has been updated with latest results. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3634 +/- ##
==========================================
+ Coverage 63.04% 63.14% +0.10%
==========================================
Files 614 614
Lines 45457 45502 +45
Branches 43 43
==========================================
+ Hits 28660 28734 +74
+ Misses 16787 16758 -29
Partials 10 10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
577b2c8 to
79f0b28
Compare
c9d6286 to
20865d9
Compare
hmpf
left a comment
There was a problem hiding this comment.
Add one commit that fixes the get's and post's of all the TemplateView desecendants to also have *args (or *_) and **kwargs (or **__) even if they don use them. Devs used to Django expect it.
| @property | ||
| def mode(self): | ||
| """Fetch the mode of this request""" | ||
| return self.request.GET.get('mode', NAVLET_MODE_VIEW) |
There was a problem hiding this comment.
Changing viewclass.as_view() to spit out two different classes depending on mode might be better, but is out of scope. Django-style would be to have the mode as part of the url (`path("something/str:mode", ..) and two different views but that's even more out of scope.
There was a problem hiding this comment.
I agree. The Navlets code is quite strange, and really we should separate GET and POST at least. I opted not to dig too much into the Navlets in this round, and leave that for later.
| hx-post="{% url 'add-user-navlet' dashboard_id %}" | ||
| hx-swap="beforeend" | ||
| > |
There was a problem hiding this comment.
What happens if you keep action and post in addition to what's here now?
There was a problem hiding this comment.
The native form submit event is overruled by HTMX, so adding them would make no difference. Action is only used for html form submission, or by certain javascript submit handlers across the codebase.
There was a problem hiding this comment.
Q: Is progressive fallback not a goal here? (not that I'm sure this ever had functional progressive fallback).
4418f4c to
143c621
Compare
|
@johannaengland Thanks for finding that bug! The problem was a missing css class when the column count is 1 🙃 It should now behave as normal: |
|
@johannaengland I fixed the authentication error by adding the dashboard loading URL to the authentication middleware whitelist. I also fixed the failing test. The Room/Location Active Alert navlets seem to work for me.
|
| '/index/audit-logging-modal/', | ||
| '/refresh_session', | ||
| ] | ||
| auth_not_required_regex = [r'^/index/dashboard/[^/]+/load/?$'] |
There was a problem hiding this comment.
Are you sure this is the best way to fix this? Because you're mentioning to fix authentication for unauthenticated users, but my problem was authentication for non-admin users
There was a problem hiding this comment.
The fix was intended to allow anonymous users to load the default dashboard, as only the ("") view is whitelisted. I have tested with an admin and a non-admin user (but authenticated), and both can load a dashboard they own or that is shared.
However, the views to render navlets are not added to the authorization whitelist, so the problem might lie elsewhere... Are you aware of why 'get-user-navlet' is allowed for unauthenticated users?
There was a problem hiding this comment.
I think it is because the dashboard that belongs to default user should also be visible for when a user is not logged in yet
2eb117e to
dd77674
Compare
A more practical method might be to just find any interactive graph, say the activity graphs for any port on any switch and click the graph's "Add graph to dashboard" button :) |
lunkwill42
left a comment
There was a problem hiding this comment.
I'm not deeply familiar with how the dashboard/navlet system works to begin with, but this certainly does look like a massive improvement over the existing code. Therefore, I don't have terribly much to say about the code itself (apart for my usual test naming nitpicks 😆), but I have tested in my browser (Firefox 145) and found a couple of weird things:
-
Dashboard compact mode looks different than before, and has issues. Something funny happens with the internal padding of widgets, and there are gaps in the vertical space between widgets where there before were none.
-
I added widgets of type "Rooms with active alerts" or "Locations with active alerts", then expanded (accordion?) one of the rooms or locations with active alerts to see the list of alerts under each. As soon as the widget is refreshed (on the refresh interval), my expansion is immediately forgotten and I am returned to the default state of the widget. This does not appear to happen in the original version, and this definitely reduces usability. I have no idea how this was achieved in the original.
-
There are non-fixup commits that exist only to refactor code that was added previously in the same PR. While refactoring is fine, doing it within a single PR just makes it harder to review, so I would suggest squashing things into more logical commits when you get to the "squashing fixups"-stage.
-
There are some comments about issues with rendering for unauthenticated users. I haven't the time or the brainpower to grok the issue this late in the afternoon, I'll have to get back to it 😆
python/nav/web/navlets/__init__.py
Outdated
| :param override_mode: Optional\; if provided, overrides the mode (VIEW or EDIT) | ||
| sent in the request. If None, uses self.mode. Used to enable the navlet to | ||
| return the correct template in error situations. | ||
| :type override_mode: str or None |
There was a problem hiding this comment.
non-blocking: While you see this all over old NAV code, please recall that this was written before type annotations were a thing in Python (some IDEs would even parse docstrings like these to provide type hints).
I would much prefer that type annotations were used for this rather than docstrings for new/rewritten/refactored code, in this modern day and age 😄
I don't know that type annotations can be used to give parameter explanations, though, so this can be kept in the docstring.
| hx-post="{% url 'add-user-navlet' dashboard_id %}" | ||
| hx-swap="beforeend" | ||
| > |
There was a problem hiding this comment.
Q: Is progressive fallback not a goal here? (not that I'm sure this ever had functional progressive fallback).
dd77674 to
6b4f70e
Compare
Weird bug yeah, it seems like jQuery UI did not initialize sorting properly unless there are existing navlets. It is fixed now to init on every new navlet. |
5d9654e to
b92a2a9
Compare
|
I'm sure @johannaengland and @hmpf are adequately able to test this feature, but I never did get an answer to my question above:
Also, I see SonarQube is not happy, it would be nice if someone took the time to review and then fix or dismiss its warnings. |
b92a2a9 to
7863e4d
Compare
|









Scope and purpose
Resolves #3635.
This PR refactors the dashboard navlets logic from a complicated JS flow, to use HTMX where possible, and simplifies necessary javascript plugin interoperability.
See issue #3635 for a full description of changes.
This pull request
navlet_controllerandnavlets_controllerwithnavlets_htmx_controllerHow to test
Loading navlets
Navlet Load
Adding and Removing Navlets
Dashboard Layout
Re-ordering Navlets
Updating columns
Compact Dashboard Mode
Editing Navlets
Periodic Refresh of Navlets
Refresh with standard interval
This can be tested with all Navlets that have a
refresh_intervaldefined, and don't haveajax_reloadorimage_reloadset toTrue. I have selected RoomStatus as an example as the refresh interval is short.Refresh with
ajax_reload=TrueAlert,PDUandUPSnavlet.renderrequests.Refresh for VlanGraphNavlet and GraphWidget
Contributor Checklist
Every pull request should have this checklist filled out, no matter how small it is.
More information about contributing to NAV can be found in the
Hacker's guide to NAV.
<major>.<minor>.x). For a new feature or other additions, it should be based onmaster.