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

Does this lib support <input type="color"/> ? #423

Closed
ambroiseRabier opened this issue Aug 4, 2020 · 10 comments
Closed

Does this lib support <input type="color"/> ? #423

ambroiseRabier opened this issue Aug 4, 2020 · 10 comments

Comments

@ambroiseRabier
Copy link

ambroiseRabier commented Aug 4, 2020

Does this lib support <input type="color"/> ?

@kentcdodds
Copy link
Member

Hi @ambroiseRabier,

Yes it does.

@ambroiseRabier
Copy link
Author

ambroiseRabier commented Aug 4, 2020

I didn't said it explicitly, but how do you use this library to set the color ? I doesn't type anything, when choosing a color, it is a serie of minimum 2 clicks. Neither click or type seem to have options for colors.
I just tried the closest I could think of: userEvent.type(element, '#123456', {delay:0}), no success with that.

@kentcdodds
Copy link
Member

Sorry, I think I was mistaken. Hey @visualjerk, do you have any ideas here?

@kentcdodds kentcdodds reopened this Aug 5, 2020
@visualjerk
Copy link
Collaborator

visualjerk commented Aug 5, 2020

<input type="color" /> is a bit tricky, as most browsers display it as a color picker.

As you can see here typing on these doesn't trigger an input event or change the inputs value.

So in order to test those you would probably have to use dom-testing-library fireEvent to dispatch an input event:

fireEvent.input(colorInputElement, {target: {value: '#333333'}})

Maybe we find a solution that comes closer to how a user interacts with these kind of inputs, but I assume it is pretty hard to do inside an emulated dom.

@kentcdodds
Copy link
Member

I agree. Maybe we could add a note in the docs about this? @ambroiseRabier, would you be interested in doing that?

@ambroiseRabier
Copy link
Author

@visualjerk that is indeed the solution I went for.
@kentcdodds when you mean doc, you mean the README.md ? I see no section that would fit this piece of information, should we add a "Known issues" or "Unsupported user events" section ?

@kentcdodds
Copy link
Member

Yeah, I think a new section titled "Known issues" or "Known limitations" would be useful.

@jesujcastillom
Copy link

Can I help with that?

@kentcdodds
Copy link
Member

Sure @jesujcastillom :)

@josebui
Copy link

josebui commented Sep 19, 2022

Is there any expectation to support this in the future?

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

6 participants