Implement Views

[oliver-sanders]

Implement all Vue views:

• GScan
• Implement the original "classic" Cylc suite views.
  • Tree View
  • Dot (LED) View
  • Graph View
• Implement "static" view(s) as a replacement to cylc graph:
  • Graph View
• Implement desired new views:
  • Dashboard
  • Gantt View
  • Job analysis
  • Suite analysis
• Pursue possible "blue sky" ideas for future suite views:
  • Matrix View? (Matrix View #52) (sketch)

[kinow]

Note to self: if, when implementing these views, we keep in mind to use or create components that are able to search the current view, that could be useful towards fixing #51

[oliver-sanders]

Note: the desire to select a task in one view and highlight it in another (e.g. highlight a task in the tree view and have the graph view focus to that point). Views should have a standard representation of the users focus/selection.

[kinow]

Note: the desire to select a task in one view and highlight it in another (e.g. highlight a task in the tree view and have the graph view focus to that point). Views should have a standard representation of the users focus/selection.

I was thinking about sharing the data model between views too, but I think we will have slightly different data structures for each view. Might have to keep only the selection as you suggested, and each view will handle the work of interpreting the selection values and displaying the data correctly.

[kinow]

We (southern hemisphere team) had a quick VC yesterday about GraphQL & cylc-ui Views. I thought I could filter queries by pretty much any field we had in the types we had coming from queries (similar to SQL).

But actually we need to implement the - if I understood correctly - filters in the resolvers first. So for each of these Views we will have, the filtering part (i.e. filter by owner, filter by workflow name, etc) would need to check whether the filtering is done on the client side, or if we will request the data already filtered.

And if the latter, check if the schema contains the filters, which I think are related to the args variables created in the schema (@dwsutherland can correct me if I'm wrong 😬 )

[hjoliver]

Filtering server-side might make incremental updates more difficult? (But would reduce network traffic and client memory use if sending the whole result every time).

[kinow]

Filtering server-side might make incremental updates more difficult?

The whole incremental updates is still very abstract to me. But @dwsutherland might be able to answer, or @oliver-sanders .

(But would reduce network traffic and client memory use if sending the whole result every time).

That's what I think too... and from a client-side (aka annoying user, UI dev) POV, it would be much easier if I could just query with filters, instead of having to write code to filter the returned values (which could lead to duplication, more tests, some bugs, etc).

[hjoliver]

I agree on easier client-side development, but for massive suites we really need incremental updates otherwise grabbing the entire suite state data every time anything changes is a big load.

However, I might have been confusing WS-UIS updates vs UIS-UI updates. The incremental path is clearer from WS to UIS - where the WS first sends the full suite state, then increments thereafter. UI is complicated by the variety of requests possible via GraphQL. I'm not sure if we can come up with a good way to incrementally update any requested subset of the workflow data.

[kinow]

Oh, I think I see what you mean. But in the worst case, once the user chose filters, we would have to re-send the initial query with filters, and then subscribe and incrementally update it. Which is still better than sending multiple requests (even if they have filters).

[hjoliver]

Yes OK (I think).

[oliver-sanders]

I think we will have slightly different data structures for each view

I think they all need to share the same data model, otherwise we end up requesting the same data multiple times.

• e.g. Graph View = Tree View + Edges

I think the views are responsible for hooking into that data-structure (d3 style).

each view will handle the work of interpreting the selection values and displaying the data correctly

I think this is a broadcast problem (observer pattern), if a node is selected in one view that view needs to broadcast the selection. Any active views should attempt to obtain that focus if possible.

There is also the requirement for one view to be able to set the focus of another. For instance if you try to view a job.out file in the tree view it should open in the cylc review view.