[Fleet] Implement new category/subcategory UI

[kpollich]

Since the Elastic Package Spec now supports category/subcategory relationships, we need to make some UI adjustments in the Integrations application to support the new nested category structure.

Example categories API JSON: https://github.com/elastic/package-registry/blob/main/testdata/generated/categories.json

Implementation

• Build a nested category/subcategory structure based on the parent_id and parent_title fields returned from the EPR packages API
• When filtering to a category that contains subcategories, an additional level of filtering is displayed above the integrations grid
  • The first X amount (ordered by count of integrations) subcategories appear as clickable buttons in this list
  • A "see more" style button (see designs) is displayed for any remaining subcategories
    • We let the subcategories overflow on one row with a gradient depicting overflow. We would still need to calculate whether the "see more" button should be present or not in case there the number of subcategories is too few to depict overflow.
  • Clicking a subcategory filters the list of integrations down to only those that contain that subcategory
  • URL state is updated based on the selected category and subcategory
  • Only a single subcategory can be selected at a time - no additive filtering
• Implement changes under feature flag (until all the new subcategories are added in epr)

Designs

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

Design is here: https://github.com/elastic/ingest-dev/issues/1349

[criamico]

@dborodyansky I implemented a simpler version of the top row subcategories. I'm basically showing a fixed number of subcategories (for now 6) and the rest of them are hidden under the button. I think that this is a more robust way of implementing it, since we don't need to calculate dynamically the page width.

Here I have some screenshots with mocked data:

And here's an example with fewer subcategories:

[kpollich]

@criamico I am +1 for implementing this via a cap to the number of categories shown vs a page/container width and "fade" on the last child. Seems much simpler and more predictable so long as the UX is still acceptable.

We can definitely pursue the higher-fidelity UX with the overflowing container + faded out last child, but if it's something we want to prioritize we should do so as a follow-up to the initial scope of getting category/subcategory on the page in a simpler way.

[criamico]

@dborodyansky I don't see anywhere in the designs a visual indication of the selected subcategory. What do you think of highlighting it with a different color? It seems very hard to understand which one is selected otherwise.

I was thinking of using this color used on the side panel category, but let me know if there is a better option:

Edit: as pointed out by @hop-dev in the code review, the UX needs some more work. We could add a visual indication of the selected subcategory with a different color or we could add it to the search box besides the category. What do you think?

[jlind23]

@criamico thanks for the work. @kpollich lets merge it like this and create a follow up issue afterwards if needed.