Validation Too Strict for Custom Scalars

[gaberogan]

Custom Scalars is GraphQL's only way of providing flexible input types. As it should be, there is no validation for these in the main editor. In the variable editor however, a custom scalar is only allow to be a string, number, boolean, or null. Anything else throws an error. If I need a free form object in the variable editor, it will complain. Could we make a non-breaking change and remove validation for custom scalars here to be more consistent and flexible, allowing free form object types? (by removing type instanceof GraphQLScalarType)

graphiql/packages/codemirror-graphql/src/variables/lint.js

Lines 165 to 174 in fa5fe7e

	// Validate enums and custom scalars.
	if (type instanceof GraphQLEnumType || type instanceof GraphQLScalarType) {
	if (
	(valueAST.kind !== 'String' &&
	valueAST.kind !== 'Number' &&
	valueAST.kind !== 'Boolean' &&
	valueAST.kind !== 'Null') ||
	isNullish(type.parseValue(valueAST.value))
	) {
	return [[valueAST, `Expected value of type "${type}".`]];

[acao]

hey, good question!

maybe instead it could provide a warning, such as how vscode gives a warning squiggle for any or implicit any even when "noImplicitAny": "true"

also of interest, there is a 2nd stage draft spec for Custom Scalar Definitions that are hosted via URIs:
graphql/graphql-spec#635

there is also this successor to the inputUnion spec proposal that is now RFC 1, called tagged type:
graphql/graphql-spec#733

[gaberogan]

@acao Thanks for the input, I haven't seen those RFCs before. I think in the case of a custom scalar it would be an explicit "any" because the variable editor knows it's a custom scalar and unfortunately we can't perform any validation beyond this and have to assume it's valid.

[acao]

personally, i feel it's best to make it invalid by default until we adopt the custom scalars spec. otherwise it's a breaking change. i prefer it to be invalid by default, because JSON, etc custom scalars, while sometimes useful, are less than ideal (like any in typescript). the custom scalars spec will take care of the rest, and then GraphiQL will know how to properly validate most any custom scalar in use

[acao]

do you mind if i turn this into a feature request to support the custom scalar spec?

otherwise, it makes the most sense to mark this as a wontfix and close it.

[truptivishe-gep]

I too am facing this issue as one of my field is of type AnyScalarGraphType. Graphiql shows the warning : Expected value of type "_Any". Shouldn't AnyScalarGraphType be included as a valid scalar type?

[acao]

@truptivishe-gep Any is not a specification scalar, and if you follow the discussion here, you'll see that there is still something in the works for providing and validating custom scalar definitions across languages

[acao]

closing this as a dupe because it's another request for validating the Any scalar/non-spec scalars

graphiql is a to-spec tool used for specification development, and closely aligned with graphql-js, so once the custom scalar spec lands in graphql@17 hopefully we will create a feature request to add this capability.