profile
viewpoint
Nick McCurdy nickmccurdy Weehawken, NJ https://nickmccurdy.com/ Web developer. Open source contributor. Administrator @reactiflux.

gatsbyjs/gatsby 47994

Build blazing fast, modern apps and websites with React

koajs/koala 315

[SEEKING MAINTAINER] An HTTP/2 and ES6 Module-ready Koa Suite

nickmccurdy/bootswatch 41

Themes for Bootstrap

karma-runner/karma-edge-launcher 17

A Karma plugin. Launcher for Microsoft Edge.

nickmccurdy/add-hooks 15

Emacs function for setting multiple hooks.

409H/defiscan 7

A read-only defi portfolio scanner

nickmccurdy/buzzword-generator 7

Produces amusing buzzword phrases.

JRJurman/Letteropend 4

A gem that exposes Letterboxd data

hollyhastings/justify 2

Justify is a web application that randomly generates excuses to get out of unwanted circumstances.

nickmccurdy/cdnm 2

Manage dependencies through CDN URLs in HTML files.

startedben-rogerson/twin.macro

started time in 21 minutes

Pull request review commenttesting-library/dom-testing-library

feat: suggest close matches using Levenshtein distance [POC]

 function queryAllByTestId(...args) {  const getMultipleError = (c, id) =>   `Found multiple elements by: [${getTestIdAttribute()}="${id}"]`-const getMissingError = (c, id) =>-  `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`+const getMissingError = (+  c,+  id,+  {computeCloseMatches = false, ...options} = {},+) => {+  const defaultMessage = `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`++  const closeMatches =+    !computeCloseMatches || typeof id !== 'string'+      ? []+      : getCloseMatchesByAttribute(getTestIdAttribute(), c, id, options)

I'm ok with giving it a trial run and seeing what real-world experience with it will be like, so defaulting to disabled makes sense to me. Let's try it out using leven.

dougbacelar

comment created time in 44 minutes

Pull request review commenttesting-library/jest-dom

ci: Add validate workflow instead of travis

  ## Our Pledge -In the interest of fostering an open and welcoming environment, we as-contributors and maintainers pledge to making participation in our project and-our community a harassment-free experience for everyone, regardless of age, body-size, disability, ethnicity, gender identity and expression, level of-experience, nationality, personal appearance, race, religion, or sexual identity-and orientation.+We as members, contributors, and leaders pledge to make participation in our+community a harassment-free experience for everyone, regardless of age, body+size, visible or invisible disability, ethnicity, sex characteristics, gender+identity and expression, level of experience, education, socio-economic status,+nationality, personal appearance, race, religion, or sexual identity and+orientation.++We pledge to act and interact in ways that contribute to an open, welcoming,+diverse, inclusive, and healthy community.  ## Our Standards -Examples of behavior that contributes to creating a positive environment-include:+Examples of behavior that contributes to a positive environment for our+community include: -- Using welcoming and inclusive language-- Being respectful of differing viewpoints and experiences-- Gracefully accepting constructive criticism-- Focusing on what is best for the community-- Showing empathy towards other community members+- Demonstrating empathy and kindness toward other people+- Being respectful of differing opinions, viewpoints, and experiences+- Giving and gracefully accepting constructive feedback+- Accepting responsibility and apologizing to those affected by our mistakes,+  and learning from the experience+- Focusing on what is best not just for us as individuals, but for the overall+  community -Examples of unacceptable behavior by participants include:+Examples of unacceptable behavior include: -- The use of sexualized language or imagery and unwelcome sexual attention or-  advances-- Trolling, insulting/derogatory comments, and personal or political attacks+- The use of sexualized language or imagery, and sexual attention or advances of+  any kind+- Trolling, insulting or derogatory comments, and personal or political attacks - Public or private harassment-- Publishing others' private information, such as a physical or electronic-  address, without explicit permission+- Publishing others' private information, such as a physical or email address,+  without their explicit permission - Other conduct which could reasonably be considered inappropriate in a   professional setting -## Our Responsibilities+## Enforcement Responsibilities -Project maintainers are responsible for clarifying the standards of acceptable-behavior and are expected to take appropriate and fair corrective action in-response to any instances of unacceptable behavior.+Community leaders are responsible for clarifying and enforcing our standards of+acceptable behavior and will take appropriate and fair corrective action in+response to any behavior that they deem inappropriate, threatening, offensive,+or harmful. -Project maintainers have the right and responsibility to remove, edit, or reject+Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are-not aligned to this Code of Conduct, or to ban temporarily or permanently any-contributor for other behaviors that they deem inappropriate, threatening,-offensive, or harmful.+not aligned to this Code of Conduct, and will communicate reasons for moderation+decisions when appropriate.  ## Scope -This Code of Conduct applies both within project spaces and in public spaces-when an individual is representing the project or its community. Examples of-representing a project or community include using an official project e-mail-address, posting via an official social media account, or acting as an appointed-representative at an online or offline event. Representation of a project may be-further defined and clarified by project maintainers.+This Code of Conduct applies within all community spaces, and also applies when+an individual is officially representing the community in public spaces.+Examples of representing our community include using an official e-mail address,+posting via an official social media account, or acting as an appointed+representative at an online or offline event.  ## Enforcement  Instances of abusive, harassing, or otherwise unacceptable behavior may be-reported by contacting the project team at kent+coc@doddsfamily.us. All-complaints will be reviewed and investigated and will result in a response that-is deemed necessary and appropriate to the circumstances. The project team is-obligated to maintain confidentiality with regard to the reporter of an-incident. Further details of specific enforcement policies may be posted-separately.+reported to the community leaders responsible for enforcement at+me+coc@kentcdodds.com. All complaints will be reviewed and investigated promptly

We could use TestingLibraryOSS@gmail.com which everyone has access to. I've got that address forwarding to me and others can do the same. I know a lot of people wouldn't feel comfortable chatting a COC violation on a public place like discord.

MatanBobi

comment created time in an hour

pull request commenttesting-library/dom-testing-library

Proposal setup to make the TypeScript migration easier

I think it would be best to avoid doing the migration all at once and instead do it over time and only start generating the type defs when we're finished.

ghostd

comment created time in an hour

startedsmeijer/where-broke

started time in an hour

issue commenttesting-library/user-event

Re-thinking approach to async event handling

Thanks for bringing this up. I've never felt comfortable making all of these synchronous. The user never fires these events synchronously, so I don't like that these fire synchronously. But you explain the problem with the alternative really well. Specifically about asserting on the loading state. The suggestion is:

What matters here is that the element isn't displayed, so .not.toBeInTheDocument() is more accurate and reliable.

But that missing some important assertion. I think it's important that we assert that the loading state exists. As you point out, it's not reasonably possible to make this assertion if we make all these events fire asynchronously (which, for everyone else's benefit, is the reason user-event is still not built-into core: https://github.com/testing-library/dom-testing-library/pull/616#issuecomment-643711133).

Unless we can find a reasonable way to solve this problem, I don't know if we can proceed 😬

nickmccurdy

comment created time in an hour

issue commenttesting-library/react-testing-library

Event properties (e.g. button) are not passed to event handler in pointerDown event

@marcosvega91 @eps1lon thanks for your comments and the workaround code.

szhsin

comment created time in 3 hours

fork piperchester/patch-node

Patch's Javascript client library - https://www.usepatch.com

https://www.usepatch.com

fork in 4 hours

startedmicrosoft/Web-Dev-For-Beginners

started time in 5 hours

startedsugarshin/react-instagram-embed

started time in 5 hours

issue closedtesting-library/react-testing-library

Event properties (e.g. button) are not passed to event handler in pointerDown event

<!--

  • Please fill out this template with all the relevant information so we can understand what's going on and fix the issue. We appreciate bugs filed and PRs submitted!

  • If your issue is regarding one of the query APIs (getByText, getByLabelText, etc), then please file it on the dom-testing-library repository instead. If you file it here it will be closed. Thanks :)

  • Please make sure that you are familiar with and follow the Code of Conduct for this project (found in the CODE_OF_CONDUCT.md file).

We'll probably ask you to submit the fix (after giving some direction). If you've never done that before, that's great! Check this free short video tutorial to learn how: http://kcd.im/pull-request

-->

  • @testing-library/react version: 11.2.2
  • Testing Framework and version: jest <!-- are you using jest, mocha, puppeteer, ava? And what version? -->
  • DOM Environment: jsdom <!-- If you're using jsdom (the default with jest), what version? Otherwise, what browser and version are you running tests in? -->

<!-- Keep in mind that if you're using a version of node we don't support that could also be an issue. Check our package.json file "engines" config for the supported version.

Also keep in mind that if you're using a version of react we don't support that could be an issue. Check our package.json file "peerDependencies" config for the supported version. -->

Relevant code or config:

const App = () => {
  const [isRightClick, setRightClick] = useState(false);

  const handlePointerDown = (e) => {
    console.log("e.button:", e.button);
    if (e.button === 2) setRightClick(true);
  };

  return (
    <div
      className={isRightClick ? "rightClick" : "noClick"}
      onPointerDown={handlePointerDown}
    >
      Right click me
    </div>
  );
};

test("Pointer down with right click", () => {
  render(<App />);

  const element = screen.queryByText("Right click me");
  expect(element).toHaveClass("noClick");
  fireEvent.pointerDown(element, { button: 2 });
  expect(element).toHaveClass("rightClick");
});

<!-- If this is an issue with documentation, please file an issue on the docs repo: https://github.com/testing-library/testing-library-docs -->

What you did:

<!-- What you were doing --> Fire pointerDown event with button property set to 2, simulating a right click.

What happened:

In the event handler which handles the onPointerDown event, e.button is undefined instead of 2. <!-- Please provide the full error message/screenshots/anything -->

Reproduction:

<!-- If possible, please create a repository that reproduces the issue with the minimal amount of code possible.

Template repo: https://github.com/testing-library/dom-testing-library-template

Or if you can, try to reproduce the issue in a Codesandbox. You can fork the one here: https://codesandbox.io/s/5z6x4r7n0p --> Please see an Codesandbox example

Problem description:

<!-- Please describe why the current behavior is a problem --> Test always fails in components which handle right click events.

Suggested solution:

<!-- It's ok if you don't have a suggested solution, but it really helps if you could do a little digging to come up with some suggestion of how to improve things. --> Pass all event properties fired in pointerDown event to corresponding event handler.

closed time in 5 hours

szhsin

issue commenttesting-library/react-testing-library

Event properties (e.g. button) are not passed to event handler in pointerDown event

Closing since this issue is caused by the testing environment not any @testing-library/* package.

szhsin

comment created time in 5 hours

startedfontsource/fontsource

started time in 7 hours

fork sw-yx/post-mortems

A collection of postmortems. Sorry for the delay in merging PRs!

http://danluu.com/postmortem-lessons/

fork in 9 hours

Pull request review commenttesting-library/eslint-plugin-jest-dom

feat(prefer-in-document): add support for assigments

 const invalid = [       `expect(${q}('foo')).not.toBeNull()`,       `expect(${q}('foo')).toBeInTheDocument()`     ),+    invalidCase(+      `expect(${q}('foo')) .not .toBeNull()`,

@AntonNiklasson FYI i had to change around the fixer from what you had due to this use case here. FYI using hard coded numbers in a fixer can be problematic for stuff like spacing etc.

benmonro

comment created time in 9 hours

push eventtesting-library/eslint-plugin-jest-dom

Ben Monro

commit sha 0249708cfb0f232f56eb12ff09fc7bf8b82729c7

fixed bug with not handling

view details

push time in 9 hours

push eventtesting-library/eslint-plugin-jest-dom

Ben Monro

commit sha 5a3f7c187d6d000bd5a7879b82708c96ee50dcae

fixed spelling mistake

view details

push time in 11 hours

issue commenttesting-library/react-testing-library

Event properties (e.g. button) are not passed to event handler in pointerDown event

Hi @szhsin thanks for reaching us 😄

Unfortunately pointerEvent is not yet implemente in jsdom. There is an open PR of @eps1lon https://github.com/jsdom/jsdom/pull/2666.

As workaround you can provide your own implementation of PointerEvent

class PointerEvent extends Event {
   constructor(type, props) {
     super(type, props)
     if (props.button != null) {
       this.button = props.button
     }
   }
 }
 window.PointerEvent = PointerEvent
szhsin

comment created time in 11 hours

startedvazco/uniforms

started time in 12 hours

startedpnpm/benchmarks-of-javascript-package-managers

started time in 12 hours

created repositorypiperchester/next-starter-jamstack

created time in 13 hours

startedben-rogerson/twin.macro

started time in 14 hours

pull request commenttesting-library/eslint-plugin-jest-dom

fix: make sure prefer-in-document only lint queries

going to close this PR in favor of that one as it handles more use cases. apologies for any duplicated effort. but would love to get your eyes on that PR if you don't mind.

Ah, that makes sense. No worries on the duplicate effort, I just enjoy learning more about this. I'll take a look at your PR 👌

AntonNiklasson

comment created time in 15 hours

created repositorykeijiro/SimpleCompositionTest

created time in 15 hours

startedloadimpact/k6

started time in 16 hours

issue commenttesting-library/react-testing-library

intellisense for @testing-library/react is not working on Ubuntu

There is also this package developed by @smeijer https://github.com/smeijer/where-broke it could help

Umer-Hayyat

comment created time in 16 hours

issue openedtesting-library/react-testing-library

Event properties (e.g. button) are not passed to event handler in pointerDown event

<!--

  • Please fill out this template with all the relevant information so we can understand what's going on and fix the issue. We appreciate bugs filed and PRs submitted!

  • If your issue is regarding one of the query APIs (getByText, getByLabelText, etc), then please file it on the dom-testing-library repository instead. If you file it here it will be closed. Thanks :)

  • Please make sure that you are familiar with and follow the Code of Conduct for this project (found in the CODE_OF_CONDUCT.md file).

We'll probably ask you to submit the fix (after giving some direction). If you've never done that before, that's great! Check this free short video tutorial to learn how: http://kcd.im/pull-request

-->

  • @testing-library/react version: 11.2.2
  • Testing Framework and version: jest <!-- are you using jest, mocha, puppeteer, ava? And what version? -->
  • DOM Environment: jsdom <!-- If you're using jsdom (the default with jest), what version? Otherwise, what browser and version are you running tests in? -->

<!-- Keep in mind that if you're using a version of node we don't support that could also be an issue. Check our package.json file "engines" config for the supported version.

Also keep in mind that if you're using a version of react we don't support that could be an issue. Check our package.json file "peerDependencies" config for the supported version. -->

Relevant code or config:

const App = () => {
  const [isRightClick, setRightClick] = useState(false);

  const handlePointerDown = (e) => {
    console.log("e.button:", e.button);
    if (e.button === 2) setRightClick(true);
  };

  return (
    <div
      className={isRightClick ? "rightClick" : "noClick"}
      onPointerDown={handlePointerDown}
    >
      Right click me
    </div>
  );
};

test("Pointer down with right click", () => {
  render(<App />);

  const element = screen.queryByText("Right click me");
  expect(element).toHaveClass("noClick");
  fireEvent.pointerDown(element, { button: 2 });
  expect(element).toHaveClass("rightClick");
});

<!-- If this is an issue with documentation, please file an issue on the docs repo: https://github.com/testing-library/testing-library-docs -->

What you did:

<!-- What you were doing --> Fire pointerDown event with button property set to 2, simulating a right click.

What happened:

In the event handler which handles the onPointerDown event, e.button is undefined instead of 2. <!-- Please provide the full error message/screenshots/anything -->

Reproduction:

<!-- If possible, please create a repository that reproduces the issue with the minimal amount of code possible.

Template repo: https://github.com/testing-library/dom-testing-library-template

Or if you can, try to reproduce the issue in a Codesandbox. You can fork the one here: https://codesandbox.io/s/5z6x4r7n0p --> Please see an Codesandbox example

Problem description:

<!-- Please describe why the current behavior is a problem --> Test always fails in components which handle right click events.

Suggested solution:

<!-- It's ok if you don't have a suggested solution, but it really helps if you could do a little digging to come up with some suggestion of how to improve things. --> Pass all event properties fired in pointerDown event to corresponding event handler.

created time in 18 hours

Pull request review commenttesting-library/dom-testing-library

feat: suggest close matches using Levenshtein distance [POC]

 function queryAllByTestId(...args) {  const getMultipleError = (c, id) =>   `Found multiple elements by: [${getTestIdAttribute()}="${id}"]`-const getMissingError = (c, id) =>-  `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`+const getMissingError = (+  c,+  id,+  {computeCloseMatches = false, ...options} = {},+) => {+  const defaultMessage = `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`++  const closeMatches =+    !computeCloseMatches || typeof id !== 'string'+      ? []+      : getCloseMatchesByAttribute(getTestIdAttribute(), c, id, options)

I'm concerned about this increasing the performance issues we already have with find* queries which are expected to fail at least once.

Good point. I tested a few times on my local running getByTestId('search', {computeCloseMatches: true}) vs getByTestId('search', {computeCloseMatches: false}).

Not a reliable benchmark, but when false it finished consistently at around 20ms. When true finished at around 35ms. It increases with the number of elements found, but not by much. Might become slightly quicker with the recommended lib.

Any chance we could lazily calculate this value so it's only run when the error is actually displayed?

An alternative would be to throw functions for find* queries. And then check if typeof lastError === 'function' when waitFor times out.

That might mean decoupling find* and get* queries a bit or perhaps make get queries depend on find queries instead of the other way around.

i.e: a get* query could be a find* query with {timeout: 0, interval: 0} ? (not sure if that would work)

Since that seems a bit involved, we could start with a config computeCloseMatches that defaults to false and give that some testing?

dougbacelar

comment created time in 21 hours

Pull request review commenttesting-library/dom-testing-library

feat: suggest close matches using Levenshtein distance [POC]

 function queryAllByTestId(...args) {  const getMultipleError = (c, id) =>   `Found multiple elements by: [${getTestIdAttribute()}="${id}"]`-const getMissingError = (c, id) =>-  `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`+const getMissingError = (+  c,+  id,+  {computeCloseMatches = false, ...options} = {},+) => {+  const defaultMessage = `Unable to find an element by: [${getTestIdAttribute()}="${id}"]`++  const closeMatches =+    !computeCloseMatches || typeof id !== 'string'+      ? []+      : getCloseMatchesByAttribute(getTestIdAttribute(), c, id, options)

I'm concerned about this increasing the performance issues we already have with find* queries which are expected to fail at least once.

Good point. I tested a few times on my local running getByTestId('search', {computeCloseMatches: true}) vs getByTestId('search', {computeCloseMatches: false}).

When false, it finished consistently at around 20ms. When true finished at around 35ms. It increases with the number of elements found, but not by much. Might become slightly quicker with the recommended lib

Any chance we could lazily calculate this value so it's only run when the error is actually displayed?

An alternative would be to throw functions for find* queries. And then check if typeof lastError === 'function' when waitFor times out.

That might mean decoupling find* and get* queries a bit or perhaps make get queries depend on find queries instead of the other way around.

i.e: a get* query could be a find* query with {timeout: 0, interval: 0} ? (not sure if that would work)

Since that seems a bit involved, we could start with a config computeCloseMatches that defaults to false and give that some testing?

dougbacelar

comment created time in 21 hours

startedottomated/CrewLink

started time in a day

more