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

Add resolver validation, check if value is a function #669

Merged
merged 2 commits into from
Jan 19, 2017
Merged

Add resolver validation, check if value is a function #669

merged 2 commits into from
Jan 19, 2017

Conversation

robzhu
Copy link
Contributor

@robzhu robzhu commented Jan 17, 2017

If a field's resolver is set to a constant value like "{}" we get a runtime error, "resolveFn is not a function". We can easily detect this case when we validate fields during schema creation. This PR adds a new validation rule to check that the resolve definition is a function.

@robzhu robzhu changed the title Validate resolver definition is a function Add resolver validation, check if value is a function Jan 18, 2017
@@ -506,6 +506,11 @@ function defineFieldMap<TSource, TContext>(
`${type.name}.${fieldName} field type must be Output Type but ` +
`got: ${String(field.type)}.`
);
invariant(
isValidResolver(field.resolve),
Copy link
Contributor

Choose a reason for hiding this comment

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

you could probably just inline this as !field.resolve || typeof field.resolve === 'function'

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"!field.resolve" means we will accept any "falsey" value such as 0 or the empty string. Is that what we want?

Copy link
Contributor

Choose a reason for hiding this comment

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

You're right, that it would let in falsey values. We could instead use field.resolve == null || typeof field.resolve === 'function' to be more specific

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried that, but the linter treats == as an error. I can update the linter to allow it if you feel strongly that == is more expressive.

Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably enable == null in the linter. I think eslint now has the ability to whitelist that particular kind of usage. It's equivalent to the longer form.

@@ -506,6 +506,11 @@ function defineFieldMap<TSource, TContext>(
`${type.name}.${fieldName} field type must be Output Type but ` +
`got: ${String(field.type)}.`
);
invariant(
isValidResolver(field.resolve),
`${type.name}.${fieldName} field resolver must be function or null/` +
Copy link
Contributor

@leebyron leebyron Jan 18, 2017

Choose a reason for hiding this comment

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

how about field resolver must be a function if provided, but got:

@leebyron
Copy link
Contributor

btw - this looks good - you should merge once you've got something you think is best

@robzhu robzhu merged commit 5cf4cef into graphql:master Jan 19, 2017
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