Displaying multiple highlighted matches from an array attribute

I’m creating a documentation website and am trying to make all content fuzzy searchable, returning individual matches from paragraphs.

I’ve gotten everything working for the most part, except for the display of the results.

This is what my index looks like (example):

[
  {
    "title": "A page title",
    "url": "/the-url",
    "content": [
      "This is a paragraph",
      "This is another paragraph",
      "This is more as an example"
    ]
  },
  ...// more items
]

The issue I’m running into is that while Algolia can match and highlight on individual strings within the content array, it always appends them together with a comma when outputting.

For example, if I search “This is”, then ${components.Highlight({ attribute: 'content', hit }) returns the following HTML:

<span class="ais-Highlight">
  <mark class="ais-Highlight-highlighted">This is</mark>
  <span class="ais-Highlight-nonHighlighted">a paragraph</span>
  <span class="ais-Highlight-separator">, </span>
  <mark class="ais-Highlight-highlighted">This is</mark>
  <span class="ais-Highlight-nonHighlighted">another paragraph</span>
  <span class="ais-Highlight-separator">, </span>
  <mark class="ais-Highlight-highlighted">This is</mark>
  <span class="ais-Highlight-nonHighlighted">more as an example</span>
  <span class="ais-Highlight-separator">, </span>
</span>

When rendered, all of the paragraphs are appended together into a giant wall of text. Ideally, I’d love to just change the separator to be something else like <br> or something, but I’ve been searching and poking at this for hours and cannot find a way to override the separator.

I tried directly accessing hit._highlightResult.content[].value. In the above example, that would return <mark>This is</mark> a paragraph but Algolia can’t render HTML that’s in a variable, only if it’s entered as a string literal.

Is there a way to achieve what I’m trying to do?

Good lord, I’ve found the world’s worst hack ever that will temporarily work while I’m finding a better solution. Big thanks to CSS Tricks.

I modified my CSS to display that separator as a table, which automatically blocks it out separately from the other spans :joy: and then I set the visibility to hidden so that the commas don’t show.

No changes to HTML.

CSS:

.ais-Highlight-separator {
  display: table;
  visibility: hidden;
}

Here are the before and after images.
Before:

After:

Ideally, it’d be really, really great if we could override or change what that separator is. Have I missed this in the sea of Algolia docs?

@vthanh welcome to the community!

Which exact frontend library are you using? Unfortunately, it looks like the separator is exposed in the React libraries but not the others.

One workaround is to supply your own highlight template, where you take the highlighted HTML from the library and combine it with your own HTML and add the line break there instead. This would be a bit of work, granted you could take the source code from our own plugin as your starting point.

Happy to help further, let us know! Thanks!

Hey @michael.king, thanks for the reply!

It’s a website built using the static site generator called 11ty and the styling is done with just UniformCSS + some sass.

Would that custom highlight template work though? Wouldn’t Algolia still auto-insert those commas between the values? I looked at the docs here on highlighting and providing pre/post tags, but it looks like even if I set this for example:

  highlightPreTag: '<em class="search-highlight">',
  highlightPostTag: '</em><br/>'

Multiple matches from an attribute’s array of values would still end up returning with , in between, as I’m not seeing a way to set or change that delimiter. So I’d be able to have Algolia insert those line breaks for me, but I’d still have to use the CSS hack above to get rid of the commas

If that’s the case, then I’d like to put in a feature request to allow changing/customizing that delimiter for InstantSearch.js, like it sounds like you can do for the React library

@vthanh Yeah that looks like the case – to submit a feature request, it looks like the developers want them submitted via GitHub: