Build inputs with auth

[homerjam]

Hi,

Just updated to Pothos 4.0, very smooth - great work :)

Could it be possible to implement the builder.objectField() method for inputs? ie.

builder.inputField({
...
})

Also I would like to define authScopes on input fields ie.

const UpdateInput = builder.inputRef(`${capitalize(type.name)}UpdateInput`).implement({
			fields: (t) => {
				const fields: InputFieldMap = {};

				fields.name = t.field({
						type: 'String',
						required: false,
						authScopes: {
							admin: true
						}
					});

				return fields;
			}
});

builder.mutationFields((t) => ({
			[`update${capitalize(type.name)}`]: t.field({
				type: 'Json',
				args: {
					id: t.arg.string(),
					input: t.arg({ type: UpdateInput, required: true }),
				},
				async resolve(root, args, ctx, info) {
					// mutate
					return {
						success: true,
					};
				},
			}),
		}));

Thanks!

[hayes]

The problem with inputFields is that the types for inputs are inferred from their definition. If you tack on additional fields after definition it can't change the types, so fields using that input wouldn't know that those additional fields exist.

Can you elaborate on the use case for this? We could potentially add something like const newRef = inputRef.extendFields(...), but you'd need to then use the new ref to access those fields

Auth scopes on inputs is interesting. I want to say that it's possible, but it's complicated. The biggest issue is that arguments might be used before the resolver/auth checks are run leading to inconsistent behavior. Specifically, inputs are processed by the Prisma plugin for all nested selections, if one of those nested selections has an input with an auth scopes, either the Prisma plugin has access to that value (maybe fine) or we throw that auth error on the root field instead

I think it might be okay, as long as we are explicit that the scope protects the resolver, not the argument itself

[homerjam]

Right now I'm able to work around the inability to extend input fields so perhaps it's not that important - I mostly just expected it to exist because I define/extend objects like this on the query side (ie not the mutation side).

For the input auth scopes I think it would be fine to protect the resolver, ideally there might be a way to protect specific args/fields and enable the rest of the mutation to run (similar to how queries are protected) but in reality this could be difficult to reason with and perhaps it's best to go with 'atomic' updates (not too clear on my usage of this term :)