Hi all, is there an easy way how to turn off hiding options in refinement lists? I have found only this: https://www.algolia.com/doc/guides/building-search-ui/widgets/customize-an-existing-widget/js/#display-facets-with-no-matches But it looks like bit complicated and we don't have the original lists (we have landing pages where the filter is already active by some rules, so is not possible). To be specific, here is an example. If user select transactionalType, the list of possible regions should be untouched and provide all options. Now if user select some transactional type, some regions are obviously hidden.

Hey! I think we need a bit more context to help with hiding options in refinement lists. Could you share: • What's the specific use case you're trying to solve? It sounds like you want region options to stay visible even when filtered by transaction type • Are you using InstantSearch.js? Which version? React, Vue, vanilla? • For the landing pages - how are the initial filters being applied?

1. yes, exactly. Just do not hide the options even when there are no results under theme 2. react-instant-search (7.13.6) under Next.js 14; Typesense v27; typesense-instantsearch-adapter (2.8.0) 3. you can imagine that the params are in url and the widgets are set according to that.. Is detailed implementation needed? Could provide it, but not right now. I wanted to mention it, just to know that there is a limitation.

For keeping all refinement list options visible (even with 0 results) in React InstantSearch, I have a few questions: • Do you have access to the complete list of possible regions somewhere (API, static data)? • Are you handling URL parameters through the routing prop on InstantSearch?

1. no, thats the issue. I heard it can be fetched from Typesense, but since we aim for a SSR implementation I dont think that would be the best approach 2. yes, we do

For an SSR-friendly approach, would it work to: • Either fetch and cache the complete list of regions at build time to use with transformItems • Or maintain a static list of all possible regions in your codebase The second option might be simpler if your regions don't change often. Would either of these work for your use case?

So basically you confirming that there is only one solution, the one in the link I have posted.

Yeah, it's a client thing. To still map over all of the values you must know them beforehand

Thanks for your time. Now it makes sense. I just want to be sure before the work will start.