Skip to content

RFC for fetchBy* queries #769

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

Closed
balavishnuvj opened this issue Sep 22, 2020 · 6 comments
Closed

RFC for fetchBy* queries #769

balavishnuvj opened this issue Sep 22, 2020 · 6 comments

Comments

@balavishnuvj
Copy link
Contributor

balavishnuvj commented Sep 22, 2020

Describe the feature you'd like:

To get an element from the dom, we have 6 variants viz. getBy, getAllBy, queryBy, queryAllBy, findBy, and findAllBy.

More often than I like to admit I would visit cheatsheet to find the method I'm looking for.

Suggested implementation:

A sample usage for react(can be adopted for rest)

fetchByText(/text/, { allowEmpty: true, allowMultiple: false });

This would be able to combine get* and query* queries. We would still need to consider find* because of thats the only async query.

Proposal for findBy* is

asyncFetchByText(/text/, { allowMultiple: false });
fetchByTextAsync(/text/, { allowMultiple: false });

Describe alternatives you've considered:

Visit cheatsheet when you forget what does what

Teachability, Documentation, Adoption, Migration Strategy:

We should be able to include this along with the rest of the variants.

Would be happy to implement it myself  😀

@kentcdodds
Copy link
Member

A big problem for this would be TypeScript. If the result could be null or undefined then you have to cast the value every time which would be annoying.

I'm sorry, but it's extremely unlikely that we're going to change the name of these methods now. The name of methods is entirely a familiarity thing. It's subjective, so making an API change will cause more confusion than benefit.

I'm willing to be swayed by other maintainers, but right now I'm pretty positive this will not happen. A wrapper library could be created though.

@smeijer
Copy link
Member

smeijer commented Sep 22, 2020

I'm comfortable with the way that it currently is. If there is a real need, I'm available to help shaping a nice and simplified api for a wrapper lib.

I'm not in favor of adding the change directly to the core, as it would be a HUGE breaking change, if the existing methods are being removed. If the existing methods would be kept to ease migration, the change would only add more methods, making things more confusing.

@balavishnuvj
Copy link
Contributor Author

balavishnuvj commented Sep 22, 2020

I guess it makes more sense to create a library on top of it, so that core is not cluttered.

@Aprillion
Copy link

Aprillion commented Sep 22, 2020

I can imagine import userScreen from '@testing-library/user-screen' with simplified API ...
but it would need to provide more benefits than just the now-familiar method names

e.g. simplified negative asserts like await isRemovedByText('gg')
(sugar for await waitForElementToBeRemoved(() => screen.getByText('gg')))

@kentcdodds
Copy link
Member

Here's my proposal. If someone cares enough about this, make a package (not in the Testing Lib org, just your own package). If it gets adoption, then we can bring up the idea of bringing it into the org and potentially adding it to core if it becomes very popular.

Outside of that, we're not going to do anything else here. Thanks anyway!

@balavishnuvj
Copy link
Contributor Author

Made a package.

https://www.npmjs.com/package/rtl-simple-queries

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants