Dark Mode

[thatmattlove]

Hello,

I've taken a look at #3599, and it looks like dark mode would be a welcome feature. Would the maintainers have any opposition to me running with a migration to Bootstrap 5 (and related dependencies), as well as an implementation of a dark theme based purely on CSS media queries? That way, Netbox's theme would simply align with the user's defined color preference.

I've got a fair amount of experience with front-end languages/concepts, you can check hyperglass, my company's website, or the website of the IX I run if you'd like.

If this is something that would be welcome by the community, I'd be willing to take it on.

[jsenecal]

I've seen your work, awesome job! I would definitely appreciate a UI refresh and dark versions of Netbox but it seems like there's not a lot of interest unfortunately as the aforementioned issue got very little attention. (Thanks for hyperglass though)

[jeremystretch]

We need to move from Bootstrap 3 to Bootstrap 5. (Yes, it's that old.)

[thatmattlove]

From a maintainer perspective, are there any hard and fast browser requirements that Netbox must support? Namely, IE 11? This would be my only "concern" with moving to BS5 - IE support is dropped. This is common with any framework these days, but I wasn't sure if there were any users (or support-paying customers) that had a requirement to support IE 11. If not, I'll open an issue and volunteer to do the work as @xkilian suggested.

[jeremystretch]

That's a good question. I'm not up to speed enough on where browsers are these days regarding different features. We're probably okay with whatever BS5 supports given its popularity, but I'm open to feedback.

[jeremystretch]

I've opened #5893 to give this more visibility. I don't know specifically what BS5 support for dark mode looks like, but I have to imagine it's better than whatever options we have currently.

[thatmattlove]

Sweet - I responded there as well, but I'd be happy to help with this in whatever way would be most beneficial to the community. I don't have a ridiculous amount of free time to dedicate, but I'll put in as much as I can.

Re: dark mode - easily accomplished with the addition of CSS variable support (or compiling Sass, or both).

[DanSheps]

I've got a fair amount of experience with front-end languages/concepts, you can check hyperglass, my company's website, or the website of the IX I run if you'd like.

Would you be interested in doing a API driven frontend for us? lol

[jeremystretch]

I'm all for an API-driven UI; we've long envisioned this as effecting "NetBox v3.0." But I worry about trying to take on too much too fast. @checktheroads do you think it makes sense to tackle the UI refresh and conversion to BS5 in v2.11, with an eye toward supporting a future API-backed frontend, and then start on that migration in the following release? Or is it more practical to take on all at once?

[thatmattlove]

That's a tough one. I can say that going the SPA frontend API backend route for NetBox would be a pretty considerable undertaking - albeit worth it, in the end.

There's a lot to consider - authentication would completely change, DRF serializers modified/added that potentially don't exist today (I'm admittedly not overly familiar with the NetBox code structure, yet), new OS dependencies/installation processes (i.e. NodeJS), bundle/build processes that need to be built into startup, to say nothing of the development process for maintainers being very different. But again, worth it.

After thinking that through a bit, that definitely feels like a more "3.0 major breaking change" type thing that something to slip into a minor release. My opinion would be to stay on course with BS5 and migrating away from jQuery - this alone will help a future migration to SPA/API.

[candlerb]

DRF serializers modified/added that potentially don't exist today

That's the big one. There's quite a lot of functionality in the UI which can't be replicated via the API, or at least, not efficiently. In particular, there are various search filters that aren't exposed via the API, and little or no control over what related objects are fetched.

This could be implemented by a whole bunch of ad-hoc REST API endpoints customised to the needs of the UI (ugh). Or it could be done generically with something like GraphQL. Or it could be done by defining RESTful ways to do certain custom queries, as PostgREST does - e.g. see filtering, resource embedding. Personaly, I don't really see the value in putting a layer over SQL: the Salesforce "REST" API also exposes its own SQL-based query language.

In any case, I think we agree that the API is going to change significantly, which seems like "3.0" to me too.

[jeremystretch]

Personaly, I don't really see the value in putting a layer over SQL

There's a ton of logic and validation within the REST API. Enforcement of object-based permissions alone necessitates this.

[thatmattlove]

Enforcement of object-based permissions alone necessitates this.

Agreed - if the app had zero requirements for authentication, I could see the value in removing the extra layer. But DRF and one of the DRF JWT libraries (can't recall the name at the moment) make it very easy to flexibly handle authentication/authorization for each view.

I do however like the idea of using GraphQL - it would make the querying and filtering much less obtuse in those cases where fine granularity is needed.

In particular, there are various search filters that aren't exposed via the API, and little or no control over what related objects are fetched.

Indeed, I anticipate needing to add a lot of UI-specific serialzers. Another reason I think putting this endeavor on the 3.0 roadmap is probably wise :)