Add beforeOperation.[create|update|delete] and afterOperation.[create|update|delete] operation routing for list hooks

[dcousens]

This pull request adds the .[create|update|delete] hooks for the *Operation list hooks, and adds the same for field hooks internally (but not externally, as that is a breaking change for fields).

This routing is preferred for the refined type guarantees it can offer your application without needing to branch the types yourself.

[dcousens]

This will minimize the number of breaking changes moving forward and keeps us keenly aware of what else is being copied to this type.

[dcousens]

Apparently text({ label: 'a text field' }) is what we use for fields, but not for lists.
Strange

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit da90b62:

Sandbox	Source
@keystone-6/sandbox	Configuration

[gautamsi]

what about validateInput and resolveInput for list and field. I hope the list and field both will have same/similar syntax.

[dcousens]

@gautamsi resolveInput already has this syntax for lists, but not for fields.
Unfortunately for fields, it is a breaking change to add any of this to their types seeing as fields often wrap user configuration.

edit: as you can see however, I am adding this functionally for fields internally, so we can make that a clean breaking change

[dcousens]

validateInput and validateDelete is something I am playing with in 2bad55e - but it is not ready, and I am unclear how the types should work for users if you had:

validate: {
  create: ...
  update: ...
}
validateDelete: ...

I think probably only one version should be allowed, validate*, or validate: { ... }, not both.

[dcousens]

Alternatively, I could add validateInput.[create | update], and validateDelete.delete, and then break that in the next major to merge into validate.*.

[gautamsi]

why not validate.[create | update | delete]

[borisno2]

Nice!

[dcousens]

@gautamsi what do you do if users provide both? (as I mentioned in #8826 (comment))

validate: {
  create: ...
  update: ...
  delete: ...
}
validateInput: ...
validateDelete: ...

That is the question I don't know the answer to, and thus it seems like it might end up as a breaking change, unlike this pull request.

[gautamsi]

I guess throw error and have them provide only one, this is breaking changes so they should be able to work through

[gautamsi]

Can you do that in upcoming breaking change ? It will streamline [validateInput | resolveInput | beforeOperation | afterOperation].[create | update | delete]

[dcousens]

@gautamsi that is my intent, yes - and I might add support earlier as you said, with a throw, but I don't want to block on that