Make all GraphQL core queries injectable

[chillu]

Overview

We've done ground work on customiseable GraphQL queries a few months ago. The sole purpose of this was to make the CMS UI extensible. Yet somehow we ended up with AssetAdmin still having hardcoded queries (see readFilesQuery.js and AssetAdmin.js)

Extract from the ACs:

The following use cases are made possible through the API. This can be demonstrated by sample code and recipes rather than full implementations.

• Show a "pending approval" indicator on a file gallery tile in asset admin

I'm wondering how this was achieved without making the readFiles query injectable?

Acceptance Criteria

• All queries and mutations used in SilverStripe core modules can be extended by the means documented in https://docs.silverstripe.org/en/4/developer_guides/customising_the_admin_interface/reactjs_redux_and_graphql/#using-injector-to-customise-graphql-queries

Pull Requests

• [x] https://github.com/silverstripe/silverstripe-asset-admin/pull/847
• [x] https://github.com/silverstripe/silverstripe-admin/pull/683
• [x] https://github.com/silverstripe/silverstripe-framework/pull/8469

[robbieaverill]

Other examples of these types of queries:

• https://github.com/dnadesign/silverstripe-elemental/blob/3.0/client/src/state/history/readOneBlockQuery.js
• https://github.com/dnadesign/silverstripe-elemental/blob/3.0/client/src/state/history/revertToBlockVersionMutation.js
• https://github.com/silverstripe/silverstripe-cms/blob/4.2/client/src/state/history/readOnePageQuery.js
• https://github.com/silverstripe/silverstripe-cms/blob/4.2/client/src/state/history/revertToPageVersionMutation.js

These queries are all applied via registerTransforms.js injector calls for what it's worth.

[bergice]

Discussed this with @unclecheese.

He proposes that we move away from the DI on the front-end and instead move this to the back-end to be composed and presented using FormSchema to the front end as this should make it easier to extend and less abstract, but at the cost of coupling the front-end with the back-end.

The concern is that the way you would extend this using DI on the front-end would be too abstract and not able to scale.

We should look into a quick and clean way to make the asset-admin query extensible based on the requirements of the TNZ project as this should be the current priority.

[unclecheese]

POC is up here, (https://github.com/silverstripeltd/tourism1/tree/feature/injectable-queries) using two different forks -- one for admin/ and one for asset-admin/. There are bigger implications for how this will work that I've discussed with @chillu (out of scope for this card), but these changes get the story over the line.

[unclecheese]

Blocking based on all kinds of stuff up in the air on whether this is the right approach or not. Impossible to call this ready for peer review at this point, but done enough to satisfy edge case.

[robbieaverill]

I've reviewed all PRs and tested it out, all working nicely. Each PR could do with being rebased against 1.3 and have a good squash and re-label. I also expect someone else is going to review this as well =)

[robbieaverill]

All PRs merged