Create filters side panel for Nautobot 2.0 UI

[norbert-mieczkowski-codilime]

What's Changed

The new Nautobot 2.0 UI gets filters side panel. Its title and conent are empty by default and have to be supplied with title and content parameters to useFiltersPanel hook. Optionally, useFiltersPanel also accepts id parameter, which will be generated automatically if not given explicitly. The hook API is as follows:

const { close, isOpen, open } = useFiltersPanel({ id: "filters-panel", title: "Title", content: <></> });

TODO

• Implement FiltersPanelContext and FiltersPanelContextProvider to manage filter panels in the UI application
• Create FiltersPanel and FiltersPanelContainer UI components for visual representation
• Implement useFiltersPanel as well as useFiltersPanelContext as user-friendly API for the components above
• Place FiltersPanelContainer component inside GenericView

[glennmatthews]

Question/nitpick, should the filters panel extend as high as it does, or should it flow "under" the table header and buttons?

Current appearance:

Quick mockup of what I'm asking:

[glennmatthews]

It feels inelegant to me that we are adding functionality that should be exclusive to the object-list view at this basic level of the UI. Is there any cleaner way to do this?

[norbert-mieczkowski-codilime]

Although it is exclusive to the object list view, filters panel is at the same time an upper-level layout element, which is actually higher in the node hierarchy than the object list view itself. It would be either required to restructure the root layout of the application, or filters panel, to make the two (object list view and filters panel) coupled more tightly. I'm not insisting on this implementation though, just pointing out that we would need to change some of the requirements in order to do so

[timizuoebideri1]

Would it make logical to provide a placeholder (GlobalState, CreateContext, etc.) so that each page can override it as needed?
The buttons that should be placed in the placeholder may then be provided by ObjectListView.

[glennmatthews]

Similarly, shouldn't this be only in ObjectList.js rather than in GenericView.js?

[norbert-mieczkowski-codilime]

ObjectList view is lower in the tree structure, which rules out the possibility of filters panel to be a part of it. How I see it - currently the layout consists of these 4 fundamental elements: header, sidebar, main content and filters panel. So if we want to shuffle them, we need to change the root layout. Perhaps it would be a good idea, since you said filters panel is going to be used only on object list view anyway, but at the same time for now it is designed to be a top level layout element and if that needs to change, then let's do it outside of scope of this PR

[bryanculver]

Question/nitpick, should the filters panel extend as high as it does, or should it flow "under" the table header and buttons?

Current appearance:

Quick mockup of what I'm asking:

Cloud has it like so:

Considering we want to have breadcrumbs I think it would be fine to have breadcrumbs and banners take up the full width and both the main section and filter sidebar come under them.

[norbert-mieczkowski-codilime]

I was initially asked to do a similar panel that Nautobot Cloud already has, but if you need something else, I'm happy to help. Just need to have a clear view on what does it have to look and beahve like.

[bryanculver]

I was initially asked to do a similar panel that Nautobot Cloud already has, but if you need something else, I'm happy to help. Just need to have a clear view on what does it have to look and beahve like.

I think it's good as is, just needs an implementation review. Do you mind fixing the merge conflict?

[HanlinMiao]

Pulled it down and looks good!