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

Fixes #150. #151

Merged
merged 1 commit into from
Aug 1, 2016
Merged

Fixes #150. #151

merged 1 commit into from
Aug 1, 2016

Conversation

dahjelle
Copy link
Contributor

@dahjelle dahjelle commented Jul 21, 2016

Since the <li>'s onMouseUp handler will set optionsOpen to false, we don't need to do that here if we click on the <li>. Fixes #150.

@ghost ghost added the CLA Signed label Jul 21, 2016
@ghost ghost added the CLA Signed label Jul 21, 2016
@dahjelle
Copy link
Contributor Author

And…I haven't the slightest idea why those tests are failing. They fail locally (forgot to look earlier…oops!), but they are also failing on master. Perhaps a dependency upgraded?

@asiandrummer
Copy link
Contributor

@dahjelle - Thanks for fixing this! I'll take a look at the master failure in a bit.

@ghost ghost added the CLA Signed label Jul 26, 2016
@@ -111,7 +111,10 @@ export class ExecuteButton extends React.Component {
} else {
document.removeEventListener('mouseup', onMouseUp);
onMouseUp = null;
this.setState({ optionsOpen: false });
// don't run setState if we click on an <li> menu item
if (upEvent.target.parentNode.parentNode !== downTarget.parentNode) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A small nit, but upEvent.target.parentNode.parentNode could be named into something more readable

@dahjelle
Copy link
Contributor Author

I tried a different tactic using compareDocumentPosition, but I'm not necessarily convinced it is more readable. It is probably less fragile. Thoughts?

@ghost ghost added the CLA Signed label Jul 26, 2016
@@ -111,7 +111,13 @@ export class ExecuteButton extends React.Component {
} else {
document.removeEventListener('mouseup', onMouseUp);
onMouseUp = null;
this.setState({ optionsOpen: false });
// don't run setState if we click on the menu
if (!(
Copy link
Contributor

@asiandrummer asiandrummer Jul 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about:

const isOptionsMenuClicked = !(
  downTarget.parentNode.compareDocumentPosition(upEvent.target) &
  Node.DOCUMENT_POSITION_CONTAINED_BY
);
if (isOptionsMenuClicked) {

?

@asiandrummer
Copy link
Contributor

So the build fails on react-test-utils@15.2.1 because the DOM provided to CodeMirror doesn't have getClientRects function while creating a Range object. I'm trying to see if this is a known issue - nonetheless, I'll get the tests working soon. Thanks for your patience!

@dahjelle
Copy link
Contributor Author

Thanks for your patience!

Thank you for the hand-holding! Glad to help. :-D

How about…

Yes, I like it. Thanks! I moved the ! to make the variable name make more sense. It still isn't strictly accurate—it's something more like isOptionsMenuClickedAndNotAlreadyClosed—but I think it's close enough to read the code and get an idea of what is going on.

So the build fails on react-test-utils@15.2.1 because the DOM provided to CodeMirror doesn't have getClientRects function while creating a Range object. I'm trying to see if this is a known issue…

It looks like js-dom's implementation of Range is a work-in-progress.

For whatever it's worth, I found this page where they had a suggestion to add a mocked document.createRange to the tests. If I add

document.createRange = function () {
  return {
    setEnd() { },
    setStart() { },
    getBoundingClientRect() {
      return { right: 0 };
    },
    getClientRects() {
      return { right: 0 };
    }
  };
};

to GraphiQL-test.js, the tests pass.

@asiandrummer
Copy link
Contributor

asiandrummer commented Aug 1, 2016

omg that's exactly what we needed - 010d47 takes care of this!

@dahjelle
Copy link
Contributor Author

dahjelle commented Aug 1, 2016

Cool! I rebased this PR on master. :-D

@asiandrummer asiandrummer merged commit d42b15a into graphql:master Aug 1, 2016
@dahjelle dahjelle deleted the fix-execute-button branch August 1, 2016 19:09
acao pushed a commit to acao/graphiql that referenced this pull request Jun 1, 2019
…transform-es2015-block-scoping-6.24.1

Update babel-plugin-transform-es2015-block-scoping to the latest version 🚀
acao pushed a commit to acao/graphiql that referenced this pull request Jun 5, 2019
acao pushed a commit that referenced this pull request Feb 20, 2022
* edit commands

* 0.2.3

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

Successfully merging this pull request may close these issues.

3 participants