Restructure device component templates

[jeremystretch]

Proposed Changes

We need to devise a cleaner method of displaying components on the device view. This is needed both to accommodate the display of additional attributes and other data, and to ensure long-term maintainability.

Justification

The current implementation employs an {% include %} block inside a for loop to instantiate a template, rendering one or two HTML tables rows per object. Some of these templates, particularly the interface template, has grown quite complex. There are several aspects to consider as part of this initiative:

• Can we leverage different DOM elements in place of tables? (This may require upgrading to Bootstrap 4.)
• Can we enable column-based ordering of items, like what django-tables2 provides for normal object lists?
• Should we look into populating some data dynamically via the API to improve performance? This would be particularly beneficial when displaying interfaces: There is no need to query IP address or VLAN information, for instance, if the user has opted not to display that information.

[tyler-8]

The datatables project could be a possibility for helping with item 2 & 3. It has Bootstrap support built-in, and handles API pagination if setup correctly (there's a DRF plugin that does it automatically).

[DanSheps]

FYI, Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction.

Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3?

[jeremystretch]

I've come across datatables before but haven't looked too closely at it. The biggest likely problem is that we're not dealing with simple single-row-per-object tables: Multiple rows of objects are required per object to display things like tags, IP addresses, and VLANs. This is why I'd like to move away from tables if possible in favor of something more flexible.

[tyler-8]

Bootstrap 4 does have quite a big change to the nav menu structure, but I do think going to BS4 would be a move in the right direction.

Never used datatables, however I am a big fan of bootstrap 4. Does datatables support BS4 or does it need to sick with BS3?

Bootstrap 3 to 4 requires a fair amount of work, though I agree, it's the right move at some point. (official docs | summarized guide)

AFAIK, datatables integrates with BS4 fine: https://datatables.net/examples/styling/bootstrap4

The biggest likely problem is that we're not dealing with simple single-row-per-object tables...

In that case datatables wouldn't be that helpful. Granted, I've only given it about 2 minutes of thought but I worry that too much data is going to be crammed in to one page. An interface listing in tabular format gives the cleanest summarized view of most of the data. Perhaps use of tooltips or dynamically expanding elements to get drill-down info (like list of VLANs tagged) would be one alternative to scrapping tables entirely.

if the user has opted not to display that information

Smells like a case for GraphQL APIs. No but really - if we're treading in to the world of having users choose which complex data structures they want to see (beyond simple filtering), you don't want to pull all the data and then parse out pieces and build new serializers/views every time a new API output is decided upon. You want the user to retrieve only the data they want and then display it. Luckily, on the API tooling side, there is already an excellent tool for doing that for Django. This is all out of scope for this issue of course, but seems like it could be related.

[minitriga]

In terms of showing more data within a row. Datatables supports child rows, we used this on a custom IPAM/DCIM/Ticketing system when I worked at Cisco. This helped us show the different relationships between objects easier while keeping the table pretty clutter-free.

https://datatables.net/examples/api/row_details.html

[DanSheps]

Thanks @minitriga my look is that looks like exactly what we need

[Arkasha99]

What about using split.js? We don't need those "show IP" or "show VLANs" buttons then, we just click on interface and open split view window, showing all the info about particular interface like in jira kanban. We can also use datatables filtering inside this window.
https://split.js.org/

[DanSheps]

So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time.

[minitriga]

Indeed when you click the dropdown button perform an API call to get the data you would like it doesn't require anything specific through. Not sure if you would want to prepopulate the page with all data required for the table or do API calls for each row child.

https://jsfiddle.net/c5yxjz0f/3

I altered a jsfiddle project to do an API call to a public API and present the data if succeeded but not sure if this would work for NetBox.

[tyler-8]

So, looking into datatables a bit, it does look like it is looking for some specific variable returned from a rest API if the API is to be queried each time.

Out of the box it has a specific structure it expects the data to be in, however it is customizable with varying degrees of complexity depending on how you want to shape the data.

[DanSheps]

I finally have had a chance to circle back around to this. @minitriga that only works if you are loading all of the data into ajax at once. Unfortunately, we would be using server side processing because loading all data will most likely result in timeout issues for people.

Server side processing expects data to be returned in a specific format, so we would need to alter our serializers based on whether or not we are using datatables. It is expecting the draw, recordsTotal and recordsFiltered fields, and we would need to rename our "results" key to "data". I am not opposed to going in this route in the future, but it looks like it won't be as simple and this would need to be done in a major release. Our current serializers are just not configured to handle what datatables would require and it would be a major deviation from our current API.

We might be able to re-map it but we would still need to find out how many records we have total, and we would need to handle the "draw" parameter.

[jeremystretch]

Closing this out in favor of #4786 now that tables are configurable per-user.

[jeremystretch]

Closing this out in favor of #4786 now that tables are configurable per-user.