Just throwing my 2 cents: I don't think it's fair to say that "it's intended to be a replacement", given that multiple API paradigms can coexist in the same system and each of them have their trade-offs.
(cherry picked from commit b1ab1820b6)
Updated code to match definition in GraphQL\Executor\Executor::defaultFieldResolver. Change is notable because previous version did not indicate that the closure receives the $info variable.
This allows for a more granular default for which Exceptions are thrown, taking
the settings made through the ClientAware interface into account.
- Add docs
- Add a test case
- Differentiate clearly from other test
This moves validation out of GraphQLSchema's constructor (but not yet from other type constructors), which is responsible for root type validation and interface implementation checking.
Reduces time to construct GraphQLSchema significantly, shifting the time to validation.
This also allows for much looser rules within the schema builders, which implicitly validate while trying to adhere to flow types. Instead we use any casts to loosen the rules to defer that to validation where errors can be richer.
This also loosens the rule that a schema can only be constructed if it has a query type, moving that to validation as well. That makes flow typing slightly less nice, but allows for incremental schema building which is valuable
ref: graphql/graphql-js#1124
This factors out the enum value validation from scalar value validation and ensures the same try/catch is used in isValidLiteralValue as isValidPHPValue and protecting from errors in valueFromAST.
ref: graphql/graphql-js#1126
This changes the parsing grammar and validation rules to more correctly implement the current state of the GraphQL SDL proposal (facebook/graphql#90)
ref: graphql/graphl-js#1102
