-
Notifications
You must be signed in to change notification settings - Fork 172
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
GraphQLScalars are not intended for email, password, etc. validation #168
Comments
Just following up here - this is not to say that if you do this that you're not doing GraphQL correctly or anything like that - the technology is young and experimentation with this technique is warranted and good. My opinion expressed on the other thread is that on balance the pros and cons have in the past weighed out in favor of doing validation elsewhere and keeping the type system simpler, but you may find other conclusions. One concern is that if you ever foray into code generation based on a GraphQL schema for any client (for example, generating Java models for an Android app), then you'll need to teach those scripts what to do when they encounter an Of course, if you're not doing such code generation, then that wouldn't be a concern :) |
@leebyron thanks for following up! Very interesting point & what you alluded to is the very thing I want to try. Similar to how an introspection query can create a client-safe schema, I'd like to build something that creates client-safe type validation. At a cursory glance, it looks like I'll just have to polyfill the |
Yeah I am curious to see how this turns out. You'll need to do validation in |
See graphql/graphql-js#433 (comment)
Basically Lee says
GraphQLScalars
should only be used if the field is represented as a different underlying type, hence they shouldn't be used to validate emails and passwords, which are internally stored as strings.The text was updated successfully, but these errors were encountered: