Return all searchable facets belonging to a searchable attribute?

I need to return a list of facetHits based on a parent attribute. For example, for a “library-books” index and for the book attribute “author,” there are several sub-attributes that I have also configured as searchable facets:

  • author.city.value
  • author.favorite_color.value
  • author.whatever.value

Is there a way to query booksIndex.searchForFacetValues() to return all searchable facets belonging to the “author” attribute? Wildcards don’t seem to work, and manually listing every searchable facet in the query isn’t very maintainable when there’s a duplicate list in attributesForFaceting. Honestly, even being able to just get a list of all facets period from the ‘Search’ ACL would do the trick.

Edit:
To help illustrate why I’d want this, I’m building a search UI where I provide the user with a drop-down list of facets to filter by (“Filter by author’s _____”), and depending on what records that user’s search key has access to, some of those facets will return zero results—in which case it’s pointless to show those facet names. For reasons specific to my use case, it’s important that “author” be an attribute of “book” instead of its own index.

Edit 2:
I have found a way to achieve this, but it has major limitations that make it a poor solution for this use case. booksIndex.search('', { facets: ['*'] }) gives me a search result that includes a list of all the facets and I could filter this client-side for author., but this comes with two big problems:

  1. The response for this search is huge; nearly 20kb compared to the <1kb searchForFacetValues response.
  2. search() is limited to 1000 hits (and increasing this limit would make the response much bigger), and my “library” has tens of thousands of books, so I’ll potentially be missing a lot of facets in what’s supposed to be a full list of author-based attributes.

Hi will_too,

Your method of using the normal search method and passing in the facets parameter would be how to address searching across multiple facets.

Addressing your concerns, you can reduce the overall response size by setting hitsPerPage to 0 which will remove all the hits information from the response which would be the majority. This will leave you with just the facets information to make the filters component.

Please note that the facet information is reflective of all the data in your index based on the search parameters and not just the hits on that current page. Whether hits is limited to 0 or 1000 does not affect the returned facet values.

Please let us know if you have any issues.

Yeah, this does work, but it still doesn’t quite cover the use case I needed.

What I ended up doing was add the settings ACL to our server-side key and write a script that polls the index for its facets, then filters by searchable() and stores those keys. Not ideal, but it seems access to settings is absolutely required if you want a list of searchable facets and I wasn’t comfortable granting that to the users.

This is understandable.

Your solution sounds good to me.

The only thing I’d challenge is : “what’s the source of truth for those searchable subattributes”?
Are you setting attributesForFaceting through code or manually in our Dashboard?
If you’re setting them via code, it could make sense to extract your lists at the same time as your setSettings call, instead of getting it back from Algolia elsewhere.

It’s through the dashboard for now, but we will likely want to eventually replace this with, as you say, setting the searchable attributes and storing them from the same place.