Suggestion: Add `matchingTerms` array to `search()` output

[Yorkshireman]

Is your feature request related to a problem? Please describe. I suspect a common use of this library is to search through a list of messages / emails etc and show matching results, and then highlight the matching terms in the resulting filtered list. This is not super-straightforward with the current implementation.

Describe the solution you'd like In the search() output it would be useful to have a matchingTerms key for each hit - its value could be an array of terms that matched with the hit.

For example, I have a list of emails with titles: "Your bill", "View your bill", "Make a payment", "Foo bar".

• I search for "bill payment".
• search() seems to treat a multiple-word term as, in this case, "Your OR bill"
• My app displays a list of emails that match the search criteria and I want to highlight "bill" and "payment" in each email's title to indicate why that email matched the search (in this case, those emails would be "Your bill" and "View your bill" and "Make a payment")
• If we had a matchingTerms array for each hit, this would be very easy to achieve.

Describe alternatives you've considered It's perfectly possible to achieve the above result without a matchingTerms output, but it seems to me it would be a welcome feature for many developers.

As an aside, it might actually help to spot bugs too.

[micheleriva]

Hi @Yorkshireman , thanks for your feature request. Do you happen to have a reference of other search engines implementing this feature? I'd like to see how they manage it

[Yorkshireman]

Hi @Yorkshireman , thanks for your feature request. Do you happen to have a reference of other search engines implementing this feature? I'd like to see how they manage it

Hi Michel, I don't sorry. I know I've been a bit lazy so far - I haven't looked at the source code of lyra properly yet, but I would think it wouldn't be too difficult to "pluck out" the term that "caused" the hit and push it into a matchingTerms array? I am talking from a completely ignorant position here though of course so I could be very wrong!

[Yorkshireman]

Ah you're probably wondering what is best to do rather than how. Yes makes sense.

[micheleriva]

Closing this as https://github.com/LyraSearch/lyra/pull/150 fixes the search algorithm. Multiple terms queries are OR by default now

[simonwiles]

I'm looking at replacing a lunr.js -based system, and I've just been taking lyra for a spin -- it performs very nicely! But this is necessary functionality for this particular case (either returning the terms matched as they appear in the the original context or a [start, end] offset -- lunr.js offers both). Or perhaps an extracted snippet could also work. Is there any likelihood of this being on your roadmap in the future? Thanks!