-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
feat(component-testing): Fuzzy search #15546
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems legit, I did not pull it to test locally yet. It might be good to add a minimal test for the searching (probably inside of RunnerCt, it should be quite easy).
Also looks like something got busted in Design System that is breaking the tests there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Please move the logic hook out of design system.
- We also need to highlight matched letters on the files/folders. For example when you have one top-level folder called
tests
and you are typingtes
you will see that nothing changed. Just a UX imporvement
@@ -0,0 +1,74 @@ | |||
import Fuse from 'fuse.js' | |||
import { useEffect, useLayoutEffect, useMemo, useState } from 'react' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import { useEffect, useLayoutEffect, useMemo, useState } from 'react' | |
import * as React from 'react' |
What do you think about this? Actually, this is the only right way to import React as ESM module. Moreover it is much easier to read code when default react hooks are started with React.
facebook/react#18102
https://twitter.com/sebmarkbage/status/1231673639080038400
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this is the only right way to import React as ESM module
Is this actually relevant to us? Why would it matter?
much easier to read code when default react hooks are started with
React.
I disagree with this and see no significant difference other than styling. I will not be changing it for your (CT) codebase, but for design-system
I will continue importing React as above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did post 2 links. You are doing actually an invalid thing, you are trying to import UMD using esm default export. Once react will finally have esm export this will not be possible. So it's not the styling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know very little about the crazy mess that is different types of JS modules, but the most recent React team interaction on modules/importing was the following: https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html#removing-unused-react-imports
In particular, I will point out this:
Change all default React imports (i.e. import React from "react") to destructured named imports (ex. import { useState } from "react") which is the preferred style going into the future. This codemod will not affect the existing namespace imports (i.e. import * as React from "react") which is also a valid style. The default imports will keep working in React 17, but in the longer term we encourage moving away from them.
As a question of my own, don't import *
imports hurt tree shaking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a question of my own, don't import * imports hurt tree shaking?
No, just because for now it's still an all-piece of react in one object that just exports different parts. But yeah export default is the biggest mess.
I tried this locally. Fuse.js gives really terrible results. This is intended apparently - see this comment by the author for example. If you have One lib I have used in the past is fuzzysort which gives you exactly what you'd expect with 0 config. Any particular reason to use Fuse.js? |
BTW I've been using fuzzy-search here https://material-ui-pickers.dev/api/DatePicker (for props search and it can be 50+ props here) it works really nice for years and can search through object, so we can search even through the whole relative path. |
Neat... I made a simple implementation with https://github.com/farzher/fuzzysort and it seems great. Let's discuss more. I think my overall implementation is pretty bad so we can probably trash it in the future. I used the wrong data structure (nested tree instead of flat) and it made everything really hard to work with. |
I am perfectly fine with On the topic of I would recommend against |
Naive fuzzy search for CT. Contains only the most basic configuration, and does not have match highlighting. The
useFuzzySearch
hook does expose the necessary information, but I was uncomfortable with the current component implementation, and decided to leave that for another PR.I will be adding Jest tests for
useFuzzySearch
. They may come in this PR (which requires waiting for a separate PR setting up Jest), or in a future PR as I shore up the design system.We may want to debounce the filtering, but I don't see the need at the moment.