Posted on 14/11/2019 21:50:57
Hi Tomas,
I'd beware of the desired UX. I've been chasing this for a few years with different customers and it boils down to how that works with the other facets. Common issues are:
- Using Navigation to look like Facets
- Let's assume your in page 2 of results with 2 or 3 facets selected
- User cliks on a "subgroup" what happens?
- Do you honor all of the URL parameters? You need to "remember" the filter selection
- But you really go back to page 1
- And since it's navigation, you don't really have the #results
- Using Facets (like Nicolai suggested)
- Let's assume Products can belong to multiple groups and the facet is specifically named
- The facet options may not be related to the "parent group name"
- Because facets don't have a tree hirarchy, you may be getting 2nd level and 3rd level groups mixed into one
We've been trying to use a new approach recently through an IndexBuilderExtender, where we create new fields specifically for LevelOneGroupID (and Name), LevelTwoGroupID until level 5. This gives us some awareness of the depth level, so we only present 2nd level groups as facet options, but if a product belongs to multiple 2nd level groups, you get presented with that.
A next level approach you also do is to take the IndexBuilderExtender approach (or the Facets approach - 2nd bullet), and then generate a custom facet helper that cross-checks with navigation items. While you're getting valid 2nd level facet options (which also give you number of results, and by being facets you overcome issues with determining urls), you can remove the facet options (groupID) that don't exist under a particular group (active ecom group navigation).
But this approach may have some more performance issues and be extra challenging getting entire group navigation and/or using API vs XSLT vs other options you find to get the proper context navigation.
Hope that makes sense.
Best Regards,
Nuno Aguiar