http://instantsearch-css.netlify.com/widgets/hierarchical-menu/

https://discourse.algolia.com/t/custom-refinement-widget-for-facet-combinations/6341/3

Currently we are diverging in the way we can use a different client for searching. We have algoliaClient in React InstantSearch and createAlgoliaClient in InstantSearch.js, which is proving it a bit difficult for a project like Algolia transformers since it needs to support all these forms, which is why aligning would be nice.

I think my preferred way is this:

createClient({ originalCreateClient: algoliasearch, appId, apiKey });

http://instantsearch-css.netlify.com/widgets/menu-select/

Breadcrumb

• Update DOM

ClearAll

• Update DOM

CurrentRefinedValues

• Update DOM

HierarchicalMenu

• Update DOM

Highlight

• Update DOM

Hits

• Update DOM

HitsPerPageSelector

• Update DOM

InfiniteHits

• Update DOM

Menu

• Update DOM

PriceRanges

• Rename widget to NumericRange
• Change API: remove labels list (duplicate of NumericRefinementList)
• Update DOM

NumericRefinementList

• Update DOM

NumericSelector

• Update DOM

Pagination

• Update DOM

PoweredBy

• Create widget
• Update DOM

RangeSlider

• Update DOM

RefinementList

• Update DOM

SearchBox

• Change API: remove the poweredBy option
• Update DOM

SortBySelector

• Update DOM

Snippet

• Update DOM

StarRating

• Update DOM

Stats

• Update DOM

Toggle

• Update DOM

NumericMenu

options are { min?: number, max?: number }, defaultRefinement is min:max, this should move to the object form (in the Search State too)

We should document and align which ways users have to customise the dom of the widgets. This is the templates in IS.js, the slots in Vue InstantSearch and the component props in React InstantSearch.

Can be another header like options (originally had them in there, but removed in 3dce846).

two options:

1. make a new repo for specs, RFC
2. move instantsearch.css (the themes) outside of this repo

• https://community.algolia.com/instantsearch.js/v2/widgets/priceRanges.html

doesn't exist in any other implems

I remember having had this discussion a few months ago. Should we set escapeHTML to true by default in InstantSearch 3?

Hey @ronanlevesque,

I saw you released a v3, can we have on the repo a CHANGELOG with the breaking changes so it makes it easy for us to implement?

Thanks 👍

possible solution: remove count.

Problem: count will always be "what it will be when you click this". Which means when not selected, the count is the count when it will be selected, and when selected the count will be what it will become unchecked.

Screenshots:

IMO this can't be fixed without going to a radio input display, which doesn't make much sense, so the count should be removed

When trying to use the theme and override some parts, it's hard to override selectors with an importance higher than class, so we should avoid those IMO

The className is applied but the margin is only applied on the RefinementList.

Menu

RefinementList

AFAIK the current implementation of highlight is with a wrapper element, and then "nonhighlighted" and "highlighted" parts. Is this a change on purpose?

The widget list will redirect to the production page instead of the preview.

The style of link switch when the user trigger a search. It's seems to come from the highlight style that override the link style.

Just a short one-liner to reuse on documentation

Currently the the .ais-RatingMenu-link is only a <a> when the parent item is selected otherwise it's a <div> element. But it's not valid to bind events on non clickable element like <div>, it should probably be a <a> or a <button>.

http://instantsearch-css.netlify.com/widgets/rating-menu/

This is a breaking change, and thus not yet possible, but would be a good idea once we all use instantsearch.css

See also MDN

The HTML Mark Text element (<mark>) represents text which is marked or highlighted for reference or notation purposes, due to the marked passage's relevance or importance in the enclosing context.

The "➕" in the panel with the collapsed option is not vertically centered.

The issue is that this is a special character that is not vertically centered by default.

Right now there's top: 0 which makes it below the baseline of the header text.

The value top: -5px would make the default symbol ➕vertically aligned. However, if the user edits the default template, top: -3px would be the correct value.

We could either:

1. Change the default symbol
2. Go for top: -3px and ignore the 2 pixels difference for the default ➕
3. Programmatically change the top value if the template is overriden

I would personally go for (2).

What do you think?

Both images should be the same size, and maybe even smaller (1em) so they fit in a button without forcing the "big button style"

With height and width 1em (before it was 20 and 40 (px implied)), it looks like this:

On all the list the links are wrap by an <li> element, in general it's bigger than the link. So when we hover the different item of list the cursor quickly swap between the pointer and the default one. At high speed it appears like a blink. Maybe the link could take all the space available in order to avoid the blink.

Before

After

Analytics

• Create widget

Breadcrumb

• Create widget
• Update DOM

Clear

• Rename widget to ClearAll
• Update DOM

CurrentRefinedValues

• Create widget
• Update DOM

Highlight

• Update DOM

Input

• Remove widget

Menu

• Update DOM

NoResults

• Rename widget to NoHits

NumericRefinementList

• Create widget
• Update DOM

NumericSelector

• Create widget
• Update DOM

Pagination

• Update DOM

PoweredBy

• Update DOM

PriceRange

• Rename widget to NumericRange
• Update DOM

RangeSlider

• Create widget
• Update DOM

Rating

• Rename widget to StarRating
• Update DOM

RefinementList

• Update DOM

Results

• Rename widget to Hits
• Update DOM

ResultsPerPageSelector

• Rename widget to HitsPerPageSelector
• Update DOM

SearchBox

• Update DOM

SortBySelector

• Update DOM

Snippet

• Update DOM

Stats

• Update DOM

Toggle

• Update DOM

TreeMenu

• Rename widget to HierarchicalMenu
• Update DOM

Analytics

• Create widget

Breadcrumb

• Update DOM

ClearAll

• Update DOM

CurrentRefinements

• Rename widget to CurrentRefinedValues
• Update DOM

HierarchicalMenu

• Update DOM

Highlight

• Update DOM

Hits

• Update DOM

HitsPerPage

• Rename widget to HitsPerPageSelector
• Update DOM

InfiniteHits

• Update DOM

Menu

• Update DOM

MultiRange

• Rename widget to NumericRefinementList
• Update DOM

NumericSelector

• Create widget
• Update DOM

Pagination

• Update DOM

Panel

• Remove widget
• Add templates to all widgets

PoweredBy

• Update DOM

RangeInput

• Rename widget to NumericRange
• Update DOM

RangeSlider

• Update DOM

RefinementList

• Update DOM

SearchBox

• Update DOM

SortBy

• Rename widget to sortbyselector
• Update DOM

Snippet

• Update DOM

StarRating

• Update DOM

Stats

• Update DOM

Toggle

• Update DOM

excludedAttributes

no need for ul/li

There are some inconsistencies in what is provided in the different flavours (for example in IS.js we call refine more descriptive names sometimes, same for items).

Let's do a consistency pass here!

The "No results" case is not handle by the library.

There's a difference between IS.Js and RIS regarding this widget, and I'm not sure if we went the right direction

IS.js	RIS

This is clear in the difference between hierarchical menus

IS.Js	RIS

As you see in the first screenshot, it's hard to get an accurate number for the "count", so I'd suggest going with a attribute/label: value structure. This is more flexible WRT different kinds of results (page: 1, price: 1, etc).

What I suggest is to take the DOM of RIS in this case and not show the count anymore

Since it's a non-clickable item: http://instantsearch-css.netlify.com/widgets/breadcrumb/