Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: HTML Reporter: Fuzzy search using [email protected] #1447

Closed
wants to merge 3 commits into from

Conversation

ventuno
Copy link
Member

@ventuno ventuno commented Jun 13, 2020

Follow up on: #1442 (comment). Testing Fuse.js@6.1.0-alpha.1.

Fuse.js@6.1.0-alpha.1.

Search: "assert".
fuse@6 1 0-alpha 1  - assert

Search: "beforeEach".
fuse@6 1 0-alpha 1  - beforeEach

Search: "promiseaware".
fuse@6 1 0-alpha 1  - promiseaware

Search: "promiseawarebeforeEach".
fuse@6 1 0-alpha 1  - promiseawarebeforeEach

Search: "script".
fuse@6 1 0-alpha 1  - script

Fuse.js@6.1.0-alpha.0.

Search: "assert".
fuse@6 1 0-alpha 0  - assert

Search: "beforeEach".
fuse@6 1 0-alpha 0  - beforeEach

Search: "promiseaware".
fuse@6 1 0-alpha 0  - promiseaware

Search: "promiseawarebeforeEach".
fuse@6 1 0-alpha 0  - promiseawarebeforeEach

Search: "script".
fuse@6 1 0-alpha 0  - script

@ventuno ventuno marked this pull request as draft June 13, 2020 22:23
@krisk
Copy link

krisk commented Jun 14, 2020

Re: #1442 (comment)

The reason is because of the field-length norm, where the shorter the field is, the higher the relevance of a match will be.

However, it sounds like what you may be looking for then is a basic relevance scoring. In this case, I'd recommend pulling [email protected], and setting these options:

  • ignoreFieldNorm => true
  • ignoreLocation => true

By doing this, when I search for "promiseawarebeforeEach", I get the following:

[
  ({
    item: 'Module with Promise-aware beforeEach',
    refIndex: 3,
    score: 0.09090909090909091
  },
  {
    item: 'Module with Promise-aware afterEach',
    refIndex: 5,
    score: 0.2727272727272727
  },
  {
    item: 'Promise-aware return values without beforeEach/afterEach',
    refIndex: 4,
    score: 0.4090909090909091
  },
  { item: 'async beforeEach test', refIndex: 1, score: 0.5 },
  { item: 'assert.async in beforeEach', refIndex: 2, score: 0.5 },
  { item: 'beforeEach', refIndex: 0, score: 0.5454545454545454 })
]

Hopefully, this settles the use case? 😅

Also, if possible, if you could send me the full list above as text, and what the desired sort order would be, then it may be simpler for me to understand whether it should indeed be a covered behavior of Fuse.js. Thanks!

[Tracking krisk/Fuse#440]

@ventuno ventuno changed the title WIP: HTML Reporter: Fuzzy search using [email protected] WIP: HTML Reporter: Fuzzy search using [email protected] Jun 14, 2020
@ventuno
Copy link
Member Author

ventuno commented Jun 14, 2020

Thanks @krisk for further looking into this. I updated to [email protected] and although results look better I think they still look a little odd (see updated screenshots in the description. I kept both sets for comparison).

Here's the list of modules we are filtering I removed all other properties and only left name, which is the property we use for filtering. It's a little hard for me to provide the expected sorting, but my expectation would be that if I search "promiseawarebeforeEach" all results containing "Promise-aware" and "beforeEach" (together) should be closer to the top, so for example seeing "Module with Promise-aware afterEach" ranked higher than "Promise-aware return values without beforeEach/afterEach" is not really what I expect (fuzzysort is very close to what I expect example 1 and example 2).

As a I user, I know what my module name is and I'm just trying to get to it using the filter.
As far as I understand (just based on empirical observation) Fuse.js is optimized to surface matches when I don't know what's in the content, while fuzzysort's goal seems more optimal to our goal as it strives to match SublimeText's file finder.
Does that make sense?

@ventuno
Copy link
Member Author

ventuno commented Jun 17, 2020

Closing based on the above.

@ventuno ventuno closed this Jun 17, 2020
@ventuno ventuno deleted the ftr-1438-fuse-4 branch June 17, 2020 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants