Ability to enforce query parameters

When doing a search on a subset of your dataset, the filter you used will show up in the currentRefinedValues and can show up in a refinement list.

This issue has no quick win :

• We could add an exclude or filterData to every widget. This would work, but adds yet another type of needed logic to every widget and I’m definitely against it. However it remains a considerable option.
• We could add some logic to the helper that would allow to flag some filters as being enforced, which would mean that we wouldn’t list them in the facetValues it sends back to the widgets.
• Or we could do a simple thing, which requires adding some size to the JS client build (but if we go with https://github.com/algolia/algoliasearch-client-js/issues/179 , this is no issue) : add the generateSecuredAPIKey to the client, expose a privateSearchParameters to instantsearch, and generate a securedAPIKey that would contain these parameters in itself.

cc @redox .

And @vvo , we already have multiple use cases where this would be needed.

• In Magento, in a specific category, you don’t want your users to be able to unrefine
• In Magento, @maxiloc is using something like visibility: true
• In Shopify, I have already two users using us on categories pages using tags.

[pixelastic]

I think what @bobylito mentionned earlier about this being added to the helper would be the best solution here.

We will still need a way to pass this config to the helper from instantsearch, though. I really think this is not something that must be handled on a per-widget basis, but being in the core of the helper.

As usual, we could either give users access to the helper and let them configure this constants (but this requires to totally embrace the helper, document it completly, and so on). Or we could expose one more API entrypoint to instantsearch that delegates to the helper, with the added overhead of every new entrypoint we add to instantsearch…

I feel like we are pushing the limits of what can be done with a JavaScript search library. What is considered “advanced” use case today should be default basic options of the instantsearch.js of tomorow.

[vvo]

At this point we do not have any clear proposal on this being a feature of the helper.

I think we should go with a more simple approach for now, I created #1064