Philipp Fritsche
Philipp Fritsche
Without the options, `.type(element, 'foo')` is: ```js await user.click(element) await user.keyboard('foo') ``` If that's what you want, you can use `.type()`. If you use `skipClick` option, just use `.keyboard()`. If...
Would a `.selectAndType(element, 'text')` API satisfy your use case?
As I'm currently rewriting our test environment, I stumbled over this too. Workaround: add https://github.com/rollup/plugins/tree/master/packages/commonjs to your plugins.
I agree, getting rid of these imports would be nice. This is mostly a matter of code duplication and domains. Ideally the typing and fixes would be applied in `dom-testing-library`...
It looks like the prototype chain in the JSDOM implementation is correct, but the setup of the jest-jsdom environment is broken. There is a local `Node` variable that shadows `global.Node`....
Workaround: Use constructor from defaultView. ``` test('select per defaultView.Range', () => { document.body.innerHTML = `foo` const range = new document.defaultView.Range() range.setStart(document.body.firstChild, 0) range.setEnd(document.body.firstChild, 1) document.getSelection().addRange(range) }) ```
A flat error object would also provide an easy solution to provide errors for different levels of nested fields at once. ``` { 'foo': 'someError', 'foo.bar': 'anotherError', } ```
I think the way this should be solved is a declaration file in this repo that imports the matcher types from the modules (might use declaration files as a stepping...
[userEvent/fireEvent]: fireEvent docs say to use userEvent, but all React code samples use fireEvent
We should reconsider this when #980 is merged
[userEvent/fireEvent]: fireEvent docs say to use userEvent, but all React code samples use fireEvent
I've got the impression that more people than we probably like to admit do not take the time to read the docs. They take the first example that vaguely might...