Skip to content

Eliminate circular dependency in validation rules #1263

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

Merged
merged 1 commit into from
Feb 27, 2018
Merged

Eliminate circular dependency in validation rules #1263

merged 1 commit into from
Feb 27, 2018

Conversation

bgw
Copy link
Contributor

@bgw bgw commented Feb 26, 2018

validation/validate.js depends on all of the rules, and all of the rules depend on ValidationContext, which was previously exported by validation/validate.js.

This moves ValidationContext out of validate.js to resolve this.

Circular dependencies are fine, but they tend to slow down flow, since it moves more work to the merging phase, and the merging phase isn't as fast as the inference phase. As a result, this should make flow marginally faster (in this case, only a fraction of a second faster).

This does have a minor breaking change: graphql/validatation/validate no longer exports ValidationContext, but graphql/validation still does. I can add an export to validate.js to preserve that behavior, but it's a minor change to a non-public API, and graphql-js has broken these things in the past.

I understand if you're not interested in merging this, since this is such a tiny speedup, but I personally just wanted to see if this could have any benefits.


Before (cycle shown via logfile generated with node_modules/.bin/flow server --profile):

selection_1225

selection_1229

After:

selection_1226

selection_1230

`validation/validate.js` depends on all of the rules, and all of the
rules depend on `ValidationContext`, which was previously exported by
`validation/validate.js`.

This moves `ValidationContext` out of `validate.js` to resolve this.

Circular dependencies are fine, but they tend to slow down flow, since
it moves more work to the merging phase, and the merging phase isn't as
fast as the inference phase. As a result, this should make flow
marginally faster.

This does have a minor breaking change: `graphql/validatation/validate`
no longer exports `ValidationContext`, but `graphql/validation` still
does. I can add an export to `validate.js` to preserve that behavior,
but it's a minor change to a non-public API, and graphql-js has broken
these things in the past.
@leebyron
Copy link
Contributor

Not sure I care about the 0.01s flow speed up, but I do think this is slightly cleaner - so thanks 👍

@leebyron leebyron merged commit 261b99b into graphql:master Feb 27, 2018
@leebyron
Copy link
Contributor

Internal file dependency changes are not considered breaking, only the top level module and immediate submodule (eg graphql/validation) - which this preserves :)

@bgw
Copy link
Contributor Author

bgw commented Feb 27, 2018

@leebyron I just brought it up because the release notes for v0.13.0 included:

Internal module 'graphql/language/kinds' no longer directly exports enum values # 1221

Not that you were relying on internal modules, were you :)

@bgw bgw deleted the validation-cycle branch February 27, 2018 21:47
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