it didn't suggest the best result

with a List like this

const list = [
	{label:'exhibit motorcar engine v11'},
	{label:'exhibit motorcar engine v10'},
	{label:'exhibit motorcar engine v12'},
	{label:'selling motorcar engine fly over v15'}
]

const searchWord = 'engine v15'
const options = {
			isCaseSensitive: false,
			keys: ['label'],
		}
const fuse = new Fuse(list, options)
const result = fuse.search(searchWord)

console.log(result)

[
	{label:'exhibit motorcar engine v11'},
	{label:'exhibit motorcar engine v10'},
	{label:'exhibit motorcar engine v12'},
	{label:'selling motorcar engine fly over v15'}
]

What I got back is that exact order. Which is not correct, the item with keyword engine and v15 should be on the top score. If search result consists of 100 item, the selling motorcar engine fly over v15 will be about at the bottom of the result. Which is totally wrong. Because selling motorcar engine fly over v15 is most relevant to search term engine v15.

I was expecting the result below, which is more accurate.

[
        {label:'selling motorcar engine fly over v15'},
	{label:'exhibit motorcar engine v11'},
	{label:'exhibit motorcar engine v10'},
	{label:'exhibit motorcar engine v12'}	
]

[krisk]

@zehawki, re:

And more important why set these default values in particular? (Why would anyone want to search only the 1st 60 chars? Why would anyone want to limit the search in this way?)

Fuse.js was designed with two things in mind: simplicity and performance. It consequently, by design, does not have sufficiently advanced search capabilities for fields with large text. Internally it uses a modified Bitap algorithm, which is an approximate string matching algorithm, and tells whether a given text contains a substring that is “approximately equal” to a given pattern, where approximate equality is defined in terms of Levenshtein distance. if the text and pattern are within a given distance k of each other, then the algorithm considers them equal. [wiki]

I would argue that in order to search in large text and have a better relevance score, there are additional algorithms that Fuse.js would have to incorporate, such as tf-idf. This would produce a “fairer” score relative to the length of text. But doing this would considerably bloat the library.

(Note: at some point though, I may add plugin capabilities, so that Fuse.js could be expanded)

Nonetheless, for those times that users want to search large text, you can always update location, distance and/or threshold. Modifying these, at the very least, still allows for the calculation of the distance, and therefore produces a “truer” score. Conversely, simply setting ignoreLocation to true bypasses the distance calculation.

[krisk]

@zehawki I’m looking at the example you provided, this isn’t a bug.

Please check out the scoring theory 😄

The list you provided:

[
  {
    "name": "Icon 1c",
    "desc": "Through contributions, donations, and sponsorship, you allow Fuse.js to thrive. Also, you will be recognized as a beacon of support to open-source developers.",
    "notes": "This is only for your reference, it will not display with the component."
  },
  {
    "name": "Icon 3",
    "desc": "The text is used to generate the slug. Note that if you change the slug, the URL of this page will change. Do not change the slug unless really needed."
  }
]

Since you didn’t specify the fuzzy-matching options, Fuse.js will use the following values:

• location defaults to 0
• distance defaults to 100
• threshold defaults to 0.6

With the above options, for something to be considered a match, it would have to be within (threshold) 0.6 x (distance) 100 = 60 characters away from the expected location 0.

But taking each of the search queries (patterns) you provided above:

• URL is found at index 77
• needed is found at index 144
• unless is found at index 130
• really needed is found at index 137
• developers is found at index 147

Each of those patterns appears more than 60 characters away, therefore they wouldn’t match anything.

If you don’t care where the pattern appears in the string, and you still want to consider it a match, set ignoreLocation to true.