-
Notifications
You must be signed in to change notification settings - Fork 148
feat: add prefer-find-by rule #144
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
Conversation
docs/rules/prefer-find-by.md
Outdated
|
||
## Further Reading | ||
|
||
TBD |
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 would link to findBy query doc here, as it mentions that findBy
is a shortcut for waitFor
+ getBy
. I would use the text from that callout as the main inspiration for this url in the description at the top.
Looking good so far! |
```js | ||
const submitButton = await findByText('foo'); | ||
|
||
const submitButton = await screen.findAllByRole('table'); |
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 would add some correct usages of waitFor here as well.
docs/rules/prefer-find-by.md
Outdated
|
||
## When Not To Use It | ||
|
||
TBD |
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.
TBD | |
Don't use this rule if you don't care if people aren't following best practices of testing library. |
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 wouldn't go that direct here. Better something nicer like "Not encouraging use of findBy
shortcut from testing library best practices".
lib/rules/prefer-find-by.ts
Outdated
docs: { | ||
description: 'Suggest using find* instead of waitFor to wait for elements', | ||
category: 'Best Practices', | ||
recommended: false, |
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.
Why not recommend this one?
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 think it should be recommended, indeed.
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.
"warn" or "error" ?
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.
Nice question. I think warn is enough? This rules doesn't prevent any malfunctioning code, just warns about a preferred way of writing it.
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 added warn
messages: { | ||
preferFindBy: 'Prefer {{queryVariant}}{{queryMethod}} method over using await {{fullQuery}}' | ||
}, | ||
fixable: null, |
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.
Can we not make the simple ones fixable?
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.
This is still a draft Ben. Leave the guy work on this! We are discussing in the original issue if addressing it here or in a 2nd PR.
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.
Was just an idea. Not trying to clock this or anything...
3d9d0d8
to
8f49686
Compare
I pushed a new version.
still pending to make it fixable |
lib/rules/prefer-find-by.ts
Outdated
|
||
type Options = []; | ||
export type MessageIds = 'preferFindBy'; | ||
// TODO check if this should be under utils.ts - there are some async utils |
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.
We have ASYNC_UTILS
in utils.ts
but it includes more methods than here.
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.
Maybe it's a good idea to keep all different async utils under an enumerate type and then build ASYNC_UTILS
from all the enumerate options?
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.
after giving some though, I am not sure of moving this one out. It's not a list of all wait
methods, but just a list of the ones this rule cares about. Not sure how useful it could be outside of here, as it's not all the wait
methods. Either way, we could centralize them in the future if we see the chance
Nice work mate. It would be nice to have the fixable code here, but let me know what you think about it and if you prefer to address it in a separated PR in the future. |
8f49686
to
38a67f7
Compare
This PR is ready to be reviewed. I gave suggestions a try (instead of directly fixing the code), but the problem is that types in ESLint 6 differ from ESLint 7. I have a local branch with the So this PR goes without suggestions for fix available 😞 |
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.
Looking good mate, thanks for your work! I just requested couple of extra examples and tests, everything else seems fine. We are leaving the fix step for a future PR then right?
e649e9d
to
03ed88c
Compare
BTW, I added the new rule to the main README.
yes. The problem is that when testing code: `
const submitButton = await ${waitMethod}(() => screen.${queryMethod}('foo', { name: 'baz' }))
`,
errors: [{
messageId: 'preferFindBy',
data: {
queryVariant: queryMethod.includes('All') ? 'findAllBy': 'findBy',
queryMethod: queryMethod.split('By')[1],
fullQuery: `${waitMethod}(() => screen.${queryMethod}('foo', { name: 'baz' }))`,
},
suggestions: [{
messageId: 'preferFindBy',
// this expected output should match the suggestion output of the rule
output: `const submitButton = await screen.${queryMethod.includes('All') ? 'findAllBy': 'findBy'}${queryMethod.split('By')[1]}('foo', { name: 'baz' })`
}]
}]
}) No matter what output I write in the test, the tests pass, making me think that there's something wrong with the test assertion declaration. I think the problem might be solved with ESlint 7 - furthermore, the contract changed in that version so it'll be easier to implement once that is solved. We could probably go with that in another PR, does that sound good for you? |
03ed88c
to
df905be
Compare
@gndelia that sounds good. I remember I had a similar problem when implementing the fix for the |
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.
Just a small text update in the rule description and we are ready to go!
docs/rules/prefer-find-by.md
Outdated
@@ -0,0 +1,78 @@ | |||
# Use `find*` query methods to wait for elements instead of waitFor (prefer-find-by) |
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.
Can you use here same description from README please?
# Use `find*` query methods to wait for elements instead of waitFor (prefer-find-by) | |
# Suggest using `findBy*` methods instead of the `waitFor` + `getBy` queries (prefer-find-by) |
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.
done
I've been thinking about this rule name. Could we regret it in the future for being so generic? Could we have in the future other cases where we prefer |
I think when it comes to rule names less is more. Either prefer-find-by or no-wait-for-get |
we could expand the rules or rename (breaking change) if we get a collision in the future. Not sure which other use case |
df905be
to
12e8b46
Compare
12e8b46
to
6b487fe
Compare
🎉 This PR is included in version 3.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This one tackle #127
While current code works, I still have to polish some stuff and add more scenarios (and update the docs)