Implement Views #75
Comments
|
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 |
|
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. |
|
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 😬 ) |
|
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). |
The whole incremental updates is still very abstract to me. But @dwsutherland might be able to answer, or @oliver-sanders .
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). |
|
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. |
|
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). |
|
Yes OK (I think). |
I think they all need to share the same data model, otherwise we end up requesting the same data multiple times.
I think the views are responsible for hooking into that data-structure (d3 style).
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 |
|
Closing this umbrella issue in favour of a GitHub project - https://github.com/cylc/cylc-ui/projects/3 |
Implement all Vue views:
cylc graph:The text was updated successfully, but these errors were encountered: