Skip to content

Add 'getDefinitionsMap' to 'ASTValidationContext' #1476

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

Closed

Conversation

IvanGoncharov
Copy link
Member

@mjmahone I finally figure out how to address your comment:
#1463 (comment)
Can you please review this PR so I could rebase #1463 on top of it?

@@ -22,38 +22,25 @@ export function unusedFragMessage(fragName: string): string {
* within operations, or spread within other fragments spread within operations.
*/
export function NoUnusedFragments(context: ValidationContext): ASTVisitor {
const operationDefs = [];
const fragmentDefs = [];
Copy link
Member Author

Choose a reason for hiding this comment

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

In the context of GQL documents getDefinitionsMap is a just reusable version of this code.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is very clever. I like the idea behind it a lot. I'm not sure it makes sense to expose publicly yet, but for the internal rules it makes a lot of sense to use something like getDefinitionsMap directly.

@IvanGoncharov IvanGoncharov force-pushed the SDLContextGetDirective branch from 62bcd86 to f1d0a02 Compare August 22, 2018 15:45
@IvanGoncharov
Copy link
Member Author

@mjmahone Can you please take a look?

Copy link
Contributor

@mjmahone mjmahone left a comment

Choose a reason for hiding this comment

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

I like where this is going a lot. I don't think we should block #1463 on it, but it would be a great improvement once that's in place.

@@ -22,38 +22,25 @@ export function unusedFragMessage(fragName: string): string {
* within operations, or spread within other fragments spread within operations.
*/
export function NoUnusedFragments(context: ValidationContext): ASTVisitor {
const operationDefs = [];
const fragmentDefs = [];
Copy link
Contributor

Choose a reason for hiding this comment

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

This is very clever. I like the idea behind it a lot. I'm not sure it makes sense to expose publicly yet, but for the internal rules it makes a lot of sense to use something like getDefinitionsMap directly.

);
}
return fragments[name];
return this._fragments[name];
Copy link
Contributor

Choose a reason for hiding this comment

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

We could still move the this._fragments instantiation to here:

if (!this._fragments) {
  const fragments = keyMap(...);
  this._fragments = fragments;
  return fragments[name];
}
return this._fragments[name];

No point incurring the cost of object-creation until someone actually asks for it.

if (def.kind === Kind.DIRECTIVE_DEFINITION) {
locationsMap[def.name.value] = def.locations.map(name => name.value);
}
const defNodes = context.getDefinitionsMap().DirectiveDefinition || [];
Copy link
Contributor

@mjmahone mjmahone Aug 24, 2018

Choose a reason for hiding this comment

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

I think it makes more sense to have both contexts have a getDirectiveDefinitions() by having ASTValidationContext define the function. On the other hand, if we can hide getDefinitionsMap somehow from being publicly exposed, I'm OK with the current API.

One nice thing with not exposing it: we could later easily add a getFragmentDefinitions() and getOperationDefinitions() using the same private structure, without ever publicly exposing the somewhat complex KindToNodesMap.

My big worry with getDefinitionsMap is that the type signature for it is a bit strange to me. It's very clever, which makes it hard for a newcomer to immediately grasp. Whereas getDirectiveDefinitions(): $ReadOnlyArray<DirectiveDefinitionNode> obviously returns all the known directives, and the type signature supports that.

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