Virtual Field (Resolved) Input Values

[ggpwnkthx]

Is the spirit of the virtual field type designed strictly for calculating an output? I've run into an situation where having a calculated output and allow the user to submit data in the context of that field would be appropriate.

I have found a simple workaround is to use this change:

keystone/packages/core/src/fields/types/virtual/index.ts

Lines 76 to 85 in bd33f07

	return fieldType({
	kind: 'none',
	})({
	...config,
	output: graphql.field({
	...(usableField as any),
	resolve ({ item }, ...args) {
	return usableField.resolve!(item as any, ...args)
	},
	}),

        input: {
          create: {
            arg: graphql.arg({ type: graphql.JSON }), 
            resolve: () => undefined
          },
          update: { 
            arg: graphql.arg({ type: graphql.JSON }), 
            resolve: () => undefined
          },
        },

keystone/packages/core/src/fields/types/virtual/index.ts

Lines 86 to 89 in bd33f07

	__ksTelemetryFieldTypeName: '@keystone-6/virtual',
	views: '@keystone-6/core/fields/types/virtual/views',
	getAdminMeta: () => ({ query: config.ui?.query || '' }),
	})

And to change the existing serialize method defined here:

keystone/packages/core/src/fields/types/virtual/views/index.tsx

Lines 40 to 51 in bd33f07

	export const controller = (
	config: FieldControllerConfig<{ query: string }>
	): FieldController<any> => {
	return {
	path: config.path,
	label: config.label,
	description: config.description,
	graphqlSelection: `${config.path}${config.fieldMeta.query}`,
	defaultValue: createViewValue,
	deserialize: data => {
	return data[config.path]
	},

    serialize: value => {
      if (!value) return { [config.path]: null }
      try {
        return { [config.path]: value }
      } catch (e) {
        return { [config.path]: undefined }
      }
    },

keystone/packages/core/src/fields/types/virtual/views/index.tsx

Lines 53 to 54 in bd33f07

	}
	}

This could definitely be fleshed out much better by defining actual graphql.args in the field schemas and handling those in the controller. I'm happy to tackle this, but I wanted to make sure this would make sense as a modification to the existing virtual field type or if a whole new dynamic field type would be better.

[ggpwnkthx]

I forgot to note that with the changes above, when using a custom views for the virtual field, the inputData in the hooks will be what ever value is passed into the onChange prop in the view.

[dcousens]

I think we could extend virtual to allow input, or something similar.
This is a very common use case and it has been on our internal backlog for quite some time.

[ggpwnkthx]

Thank you for the insight and confirmation of design intention. My team will work on this. Should I bother submitting a PR with the simple graphql.JSON implementation. We're using that as a default catch-all, but I can hold off on a PR until we have a more complete solution if that's preferred.

[ggpwnkthx]

#9139 submitted for review.