🐛 Broken search string when navigating from deps page

[ibolton336]

Resolves [Dependencies]Application inventory page shows no applications once Accessed from dependencies
Resolves https://issues.redhat.com/browse/MTA-2056

• Removes the auto applied search string when direct navigating using the side nav. This was applying filters that were not registered within the application table ( & other tables). I.E when navigating from the dependencies page, the search string was including an "applications.name" filter which is just referenced as "name" within the applications table. Future iterations may allow us to rewrite the search string when navigating between pages or standardizing on a specific key for app names on the back end.
• Adds the ability to parse the url string for initial search values in the dependencies toolbar.
• Adds associated clear filters handler to clear the url when the toolbar clear button is pressed. This is necessary to overwrite the initial filter values. Implemented this in dependencies page & applications table. There may be a need to incorporate this into filter toolbar at some point.

[sjd78]

The changes LGTM.

Does the "clear all" function need to be applied to more tables? Should it exist in all filterable tables? If yes, either this PR can be expanded, or a followup issue needs to be created.

[ibolton336]

The changes LGTM.

Does the "clear all" function need to be applied to more tables? Should it exist in all filterable tables? If yes, either this PR can be expanded, or a followup issue needs to be created.

This one is tough because the toolbar is a pf library component which manages the chip state and the clear button state. The toolbar exposes the clearAllFilters callback for special cases like this one when there are initial filter values parsed and loaded from the url query params. Ideally I'd like to move this code into our custom filter toolbar component based on the presence of initialFilterValues, but that doesn't seem possible at the moment.

This PR does cover both of the cases where we are using this initialFilterValue set logic, though. It is a bit annoying that we will have to remember this for any of these cases going forward.

[sjd78]

The changes LGTM.
Does the "clear all" function need to be applied to more tables? Should it exist in all filterable tables? If yes, either this PR can be expanded, or a followup issue needs to be created.

This one is tough because the toolbar is a pf library component which manages the chip state and the clear button state. The toolbar exposes the clearAllFilters callback for special cases like this one when there are initial filter values parsed and loaded from the url query params. Ideally I'd like to move this code into our custom filter toolbar component based on the presence of initialFilterValues, but that doesn't seem possible at the moment.

Yeah that makes this one a bit rough for sure.

This PR does cover both of the cases where we are using this initialFilterValue set logic, though. It is a bit annoying that we will have to remember this for any of these cases going forward.

Makes sense. Probably best to open an issue to log this future work and make it easy to find if/when the search string stuff comes up again.

[sjd78]

LGTM, just needs the issue generated so we don't forget the solution if/when it comes up again on another table.

[ibolton336]

#1667