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

Bring visitorKeys back #3250

Merged
merged 3 commits into from Sep 20, 2021
Merged

Conversation

ardatan
Copy link
Member

@ardatan ardatan commented Aug 27, 2021

See #3245 (comment)

I checked Allow edits by maintainers. So you can make changes on this PR instead of creating a new one by checking out this branch using GitHub CLI. Also you can leave comments here then I can also do the changes you want :)

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Aug 27, 2021

CLA Signed

The committers are authorized under a signed CLA.

@IvanGoncharov
Copy link
Member

@ardatan Need to think about this one.
The original intention was was to allow you to use non-standard AST.
Can you please provide examples of code where you use it?

@IvanGoncharov
Copy link
Member

Note: you can return false from visitors to skip the traversal of subtrees and it works in old version of graphql-js too.

@ardatan
Copy link
Member Author

ardatan commented Aug 27, 2021

@yaacovCR
Copy link
Contributor

Returning false means you no longer visit any of the children, what if you want to visit only some?

@yaacovCR
Copy link
Contributor

@IvanGoncharov why exactly was it deprecated even in terms of its original rationale of custom ast?

in general, for use cases above, it lets you whitelist what you want to visit rather than entering each child node with a visitor function that returns false, the latter being slightly less performant, and sometimes quite more verbose.

@yaacovCR
Copy link
Contributor

yaacovCR commented Sep 2, 2021

Related: ardatan/graphql-tools#3481

@yaacovCR
Copy link
Contributor

yaacovCR commented Sep 2, 2021

we can workaround the above bug secondary to lack of visitorKeys, but it doesn't change that we are doing too much visiting :(

we want to be speedy; if visitorKeys is dropped upstream, we will have to re-implement the v15 version -- please keep

@IvanGoncharov
Copy link
Member

I checked Allow edits by maintainers. So you can make changes on this PR instead of creating a new one by checking out this branch using GitHub CLI. Also you can leave comments here then I can also do the changes you want :)

@ardatan That's great, however, I created new PR for a different reason.
In this and your previous PRs, you add code that doesn't match style of the whole file.
A test case that you added in this PR gives a good example of what I'm talking about.
All other test cases follow the same patterns and the same name convention so I expect one that you added to also do this.
I'm 100% up for providing necessary context when reviewing PR but I expect the PR authors to review files they are changing and code around the change.
Without that, I need to check every line of the proposed change and match it with the rest of the code (very hard in GitHub review UI) and spend time left review comments.
And that is a pretty time-consuming and exhausting process, so it's simpler for me to write code from scratch and create new PR.
For example, even though this PR is added single test case it took me way more time to review it and leave comments than to simply from it from scratch using other test cases as templates.

This situation repeats itself and was the major issue with all your previous PRs.
So if you want your future PRs to be merged please spend time and try to match the code style and conventions used in this project. If you to improve something (e.g. typings) do it in separate PR and for all places that have the pattern, you want to change.

P.S. I applied changes to this PR and merging it, but the above comment stays true for future PRs.

@IvanGoncharov
Copy link
Member

@yaacovCR I'm merging this one but I think it's not a good long-term solution to expose such a low-level mechanism and also think it's brittle and non-intuitive API. So it should be a part of #3225 and want to continue the discussion there.

@IvanGoncharov IvanGoncharov merged commit 0091421 into graphql:main Sep 20, 2021
@IvanGoncharov IvanGoncharov added the PR: breaking change 💥 implementation requires increase of "major" version number label Sep 20, 2021
@IvanGoncharov
Copy link
Member

@ardatan Added ASTVisitorKeyMap to v15 see #3267 will release new version of v15 shortly

@ardatan ardatan deleted the bring-visitorKeys-back branch September 21, 2021 07:24
@leszekhanusz
Copy link

Another use for the visitorKeys is present in graphql-python/gql to parse the results coming from the backend

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: breaking change 💥 implementation requires increase of "major" version number
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants