rename hideContainerWhenNoResults to autoHideContainer

[vvo]

As proposed by @jerskouille in #394

TODO:

• always use facet values count to hide the container when relevant
• use nbHits if facet values not relevant
• handle cases were we have only null facet values
• also to be used in API proposal: clearAll #405 clearAll proposals where we hide when no refinements WERE made (vs no facet values available in the algolia response)

[pixelastic]

After discussions in #394 and #427 it seems that we are going to remove the autoHideWhenNoResults and autoHideWhenNoRefinements options for several widgets and replace them with a more generic autoHideContainer.

I think autoHideContainer sound to magical for the naming of a public-facing API attribute. What it does is really dependent on the widget context. I would use hdieContainerIfNoResults for widgets displaying results, and hideContainerIfNoRefinements for the clearAll widget. Explicit is better.

It does not change the fact that the underlying autoHideContainer decorator can use a autoHideContainer:true/false props itself, but the public-facing widget option should be self-explanatory.

[vvo]

I would say on this one (always using autoHideContainer) should not harm the users or make them wonder what is hapening. I agree I like being explicit most of the time but here what I want is "Hide this when it makes sense", being explicit introduces more naming conflicts.

clearAll widget needs an option to say "hide the container when no refinements were made", thus if we introduce both hideContainerIfNoResults and hideContainerIfNoRefinements, how do we name the "hide the container when no refinements were made"?

We would then need:

• hideContainerIfNoResults
• hideContainerIfNoFacetValues
• hideContainerIfNoNumericalRefinements (sliders)
• hideContainerIfNoRefinements (= no refinement were made, clearAll)

And we would be exhaustive, but that's a lot of options to remember for the "hide this when it make sense" usecase, while "autoHideContainer" could solve the three first cases.

I would still go for autoHideContainer

[Jerska]

This actually allowed us to not worry about some namings:

• For facetting widgets, we'd use hideWhenNoRefinements when there is no available refinement to select.
• For currentRefinedValues and clearAll, we also want hideWhenNoRefinements, but these refinements are the currently selected ones

Our widget are already "intelligent" by doing a lot of logic, and I like the idea that a widget knows when it's best to be hidden or show and allow the user to customize it with something like #455 .

In the end the markup generated and cssClasses are kind of magical too. But as soon as we document them they become part of the widget and it's easy to understand, don't you think that a clear documentation would be enough for this too?

[pixelastic]

Ok, I was missing some pieces, I thought there was only two cases. Makes sense with your explanation. Having a unified and maigical autoHideContainer options is also nice from our user POV, where we do not want them to dive too deep into the world of refinement and facets.

LGTM, then

[vvo]

doing this right now so we can handle #427