SearchBox Widget: Template options are janky/broken

[timkelty]

Do you want to request a feature or report a bug?
bug

What is the version you are using? Always use the latest one before opening a bug issue.
2.2.1 (latest as of post)

All I want to do is override the default magnifier and reset templates (use a different SVG).

There seem to be a number of oddities. First off, the options seems structured differently than most other core widgets. Instead of having a root level templates, and cssClasses props, it instead has root props of magnifier and reset. Nothing inherently broken there, just seems inconsistent (at least with the widgets I'm familiar with).

Second, the cssClasses prop doesn't really seem to work.

Attempt 1:

Try and render a custom template for the magnifier

searchBox(
  container,
  magnifier: {
    template: myCustomSearchSvg,
  },
);

It rendered my svg! However, within an empty span…I was expecting it to still be wrapped by an element with an .ais-search-box--magnifier since, I didn't override cssClasses.

Oh well, Attempt 2:

Try and manually add the class?

searchBox(
  container,
    magnifier: {
      template: myCustomSearchSvg,
      cssClasses: [{root: 'ais-search-box--magnifier'}],
    },
);

Bubkis. Same result as Attempt 1.

Attempt 3:

Try and render a custom template for the reset button

searchBox(
  container,
  reset: {
    template: 'x',
  },
);

Error!

Uncaught TypeError: Cannot read property 'style' of null
at search-box.js:124
at Object.init (connectSearchBox.js:105)
at InstantSearch.js:213
at arrayEach (_arrayEach.js:15)
at forEach (forEach.js:38)
at InstantSearch._init (InstantSearch.js:211)
at InstantSearch.start (InstantSearch.js:168)

Then I post this and gave up. :)

[bobylito]

Thanks for this bug report @timkelty 👍

[bobylito]

I've been able to reproduce what you describe. We'll be able to fix the bug that prevent you from usage a custom reset button and add some css classes. However we won't be able to change the structure nor make span divs, even though that's an error on our hand when adding the new searchbox in v2.

[timkelty]

Thanks @bobylito, will you queue up those breaking changes for v3 then?

[bobylito]

I'm wondering how much of these changes are really important, here. These are the changes I'm thinking about:

• make <span> into <div>. I'm not convinced it makes a huge difference.
• use the root css class for configuring the containers (<span> or later maybe <div>). That one disturbs me, I would see it go through
• use the main templates attribute for everything template, and not have them nested in the suboption. That one is in my opinion better kept the way it is right now, this way you can't setup a new magnifier without activating the option first.

WDYT @timkelty ? Happy to have your opinions too @vvo :)

[timkelty]

make <span> into <div>

Yeah, this doesn't really matter much at all.

use the root css class for configuring the containers

Would this make my above Attempt 1 and Attempt 2 both work?

The most troubling bug was my "Attempt 3", where it just threw an error when to change the reset template. Do any of your changes address this?

[bobylito]

The most troubling bug was my "Attempt 3", where it just threw an error when to change the reset template. Do any of your changes address this?

Indeed. There is an open PR for that #2585

use the root css class for configuring the containers

Would this make my above Attempt 1 and Attempt 2 both work?

Yes. It would have removed the friction. The root class is used inside a template, which gets removed when using a custom template.