Why is it recommended to model hierarchical categories as separate facets?

[richardscarrott]

The HierarchicalMenu widget and documentation recommends modelling each level as a separate facet, e.g.

Given this hierarchy:

root
├── Clothing
│   ├── Hoodies
│   └── T-Shirts
│       ├── Polo
│       └── V-Neck
└── Shoes
    └── Running Shoes

You'd model it like this:

{
  objectID: '1',
  name: 'V-Neck T-Shirt',
  categories: {
    lvl0: 'Clothing',
    lvl1: 'Clothing > T-Shirts',
    lvl2: 'Clothing > T-Shirts > V-Neck'
  }
}

And then defining a separate facet for each level, i.e. categories.lvl0, categories.lvl1 and categories.lvl2.

My understanding is, when a user drills down to 'Clothing > T-Shirts', the HierarchicalMenu widget does something like:

1. Search 'categories.lvl1:Clothing > T-Shirts'
  - This returns the hits and the lvl2 facets (i.e. V-Neck, Polo) 
2. Search 'categories.lvl0:Clothing'
  - This returns the sibling facets for lvl1 (i.e. T-Shirts, Hoodies)
3. Search ''
  - This returns the sibling facets for lvl0 (i.e. Clothing, Shoes)

The UI then takes all these facets and string splits as appropriate to render the HierarchicalMenu as desired.

I'm struggling to see why it couldn't be simplified by modelling it like this:

{
  objectID: '1',
  name: 'V-Neck T-Shirt',
  categories: [
    'Clothing',
    'Clothing > T-Shirts',
    'Clothing > T-Shirts > V-Neck'
  ]
}

And defining just one facet on categories.

That way, again if a user was to drill down to 'Clothing > T-Shirts', the search would just need to perform the following:

1. Search 'categories:Clothing > T-Shirts'
  - This returns the hits
2. Search ''
  - This returns the sibling facets

(This I think is the same pattern as regular non-hierarchical facets).

Then a UI could take the category facets returned, determine the level by string splitting ('Shoes > Running Shoes'.split(' > ').length), filter out those which aren't in a level above or within the 'Clothing' category and render them in a hierarchical menu.

Having written this question out, I now see a potential drawback is you'd be over fetching facet values because you'd return 'Shoes > Running Shoes' for example which wouldn't be rendered in the above scenario of ('Clothing > T-Shirts') and you'd therefore be sharing the maxValuesPerFacet of 1000 across all levels but, at least in our scenario, we're way off 1000 categories (we have ~60).

It'd be great if you could help me determine if my second approach is in fact viable (totally possible it wouldn't even work correctly as I've not implemented it yet) and also if you could share some of the decisions / tradeoffs you made when designing the HierarchicalMenu.

[francoischalifour]

Hey @richardscarrott! I didn't find original resources and context about this design decision besides the original implementation, which doesn't explain the reasoning.

We'll come back to you with a detailed answer next week 🙂

[Haroenv]

This is an interesting idea, I think originally this was done like it was for features like a custom rootLevel. If we look into rebuilding hierarchical menu with more features, we will take your suggestion in account!