Hooks - basic plumbing

[timleslie]

This PR implements the basic plumbing for the mutation hooks. It puts in place field type hooks and custom user hooks for fields and lists.

This PR should be considered a WIP for the full hook implementation and should not be used in production (unless you're extremely brave!)

The following things still need to be completed in future PRs:

• API: The current API has some subtle variations from the documented API and may yet change again. I would like to make this the subject of a future hairy session before finalising.
• Nested after...() hooks (Hooks - nested afterChange/afterDelete #533). These hooks should not be executed until all nested mutations have been completed. This will require a separate change to how we pass things through to nested mutations.
• Error handling. The data passed back through validation errors is a basic prototype. Updates to the admin-ui which handle these errors will inform future updates to this API. Failures within other hooks are not currently caught, and will propagate like any other uncaught exception. We want to catch these and serve them back with custom information to inform the app developer and user that it was a hook operation which failed.
• Rollbacks (Hooks - rollback on failure #534): We don't currently support rolling back when a hook fails.
• Testing: We don't have any explicit tests for hooks yet. These will be implemented once the API has been finalised.
• Documentation: Once the API is settled, the docs will need to be updated to reflect this and written in a more consumable format than the current raw notes from the hairy session.

[jesstelford]

Looking good so far!

[jesstelford]

Suggested change

// eslint-disable-next-line no-unused-vars

[timleslie]

👍

[jesstelford]

Suggested change

	addValidationError("Sorry, no Barry's allowed", { a: 1 }, { b: 2 });
	addValidationError("Sorry, no Homers allowed", { a: 1 }, { b: 2 });

Simpsons reference.

[timleslie]

👍 😆

[jesstelford]

This will execute getDefaultValue() twice (once for the filter, and again for the map). Is there a way we can avoid this in case there are potentially expensive lookups performed, or the function has side effects?

[timleslie]

Yeah, I agree it's a bit icky. I've kept it like this for now just to make the field-mapping pattern clear. I'm open to changing it up once everything settles down a bit.

[jesstelford]

🤔 Since the only output of these two functions is to call addFieldValidationError, which pushes the given data onto fieldValidationErrors, could we not have the validateInput methods return errors instead?

fieldValidationErrors.push(
  ...(await Promise.all(fields.map(field => field.validateInput(args))))
);

Similarly for the other functions below.

[timleslie]

Yeah, this mechanism was as per the design in the hairy session. I'll leave a FIXME in the code for us to loop back to this and check whether this is what we really want.