api-on-the-fly - part 2 - mutation association

[oliver-sanders]

Addresses the fourth point of #339

Note - Built on top of #357 now merged
Note - Works with the data types defined in cylc/cylc-flow#3469

Use the argument types defined in the GraphQL schema to associate mutations with "Cylc Objects" by which I mean workflows, cycle point, tasks, etc.

This mapping will be used when you right-click on something (say a task in the tree view) to work out which mutations are relevant to the thing you clicked on.

At the moment this is built into the temporary Mutations view.

Example

TODO

• Test

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Appropriate tests are included (unit and/or functional).
• No change long necessary, functionality not exposed to users (yet)
• No documentation update required.

[kinow]

Form generation working. Could you explain what are the associations? I chose holdWorkflow, but could choose other types, and not only workflow in association. So not quite sure I understand how that part will work.

Some consoler errors

Debugging, it shows that the this.value value is a String I think?

Everything else works, nice form generation! 🎉 As the whole code is new, +1 LGTM and we can discuss any changes afterwards if you prefer 👍

[kinow]

(Or are associations going to be restricted later, and only for now I can associate anything with any mutation?)

[oliver-sanders]

Could you explain what are the associations

The "associations" work is simply about introspecting the arguments of mutations to find out what Cylc things the mutation operates on (i.e. workflows, cycle points, tasks, jobs).

The result is a mapping (e.g. the broadcast mutation works on multiple workflows and [optionally] multiple cycle points).

This will be used in a future PR to achieve this:

1. User right-clicks (or taps or whatever) on a cycle point node in the Tree View.
2. The UI works out which mutations take cycle point(s) as arguments (e.g. broadcast, stop, insert).
3. The UI lists these mutations in a context menu.

[oliver-sanders]

Debugging, it shows that the this.value value is a String I think?

So this is the same traceback is the same issue mentioned in #357, I had thought this was caused by error in the GraphQL schema (from Cylc Flow) but it turns out it isn't.

GraphQL introspections provide "default values" in JSON format so lists come through as strings (e.g. "[\"*\"]"). The solution is to JSON.parse them which I've done in another branch.

This PR just adds associations and doesn't touch the form generation logic (which is where the error is coming from).

[oliver-sanders]

@wxtim I've put you down for review 2, this is a much quicker review than the last one.

[hjoliver]

Change log and tests?

[oliver-sanders]

Added unit tests, change log not helpful as the mutations view (as is in this PR), will not make release.

[hjoliver]

change log not helpful as the mutations view (as is in this PR), will not make release.

It will make the next (alpha-2) release. By 8.0.0 we should have another change long entry that removes it. (At least, that's how we are managing pre-8.0.0 changes, in my mind!)

[hjoliver]

You seem to have a bunch of minor quoting issues (via the linter) in the new tests.

[oliver-sanders]

It will make the next (alpha-2) release

I'll put a changelog in on the most contemporary aotf PR for a2.

[oliver-sanders]

You seem to have a bunch of minor quoting issues (via the linter) in the new tests.

Doesn't fail in my env, different linter versions perhaps, should be fixed.

[hjoliver]

LGTM