Define where the data will be loaded for views like Dashboard

[kinow]

Follow up from #149

When browsing /#/dashboard, the user will initiate a Route to a view. The view is handled by a component, in this case src/views/Dashboard.vue.

At the moment, Dashboard.vue is initiating a polling to retrieve data from GraphQL for the query. The design sketch document has what is in GScan.vue in the place of what we have in the Drawer.vue at the moment.

Once we move GScan.vue there, both components (Dashboard.vue and GScan.vue) will be displayed at the same time. This issue is for discussion around choosing when and how to fetch the data for components in Cylc UI.

[kinow]

I thought the application do something like:

1. User requests /, so the router understands it needs to display the Dashboard.vue
2. Before doing that, the user is displayed with the loading bar (we could add status messages later like "Loading User Data", "Fetching Workflows")
   2.1. Fetch User data (needed for Header.vue and possibly other components or for auth checking)
   2.2. Fetch Workflows data via WebSocket (or polling for now)
3. Once the data has been fetched and the Vuex store is populated, the components are ready to be displayed, so we remove the progress bar and display the application

I thought (could be wrong, sorry) that there would be an initial "heavy/expensive" GraphQL query to fetch the workflows (2.2). But subsequent queries would receive only incremental updates.

With that in mind, I thought for this scenario, of the user viewing the dashboard, the query would bring the status too (as we gray out stopped workflows), and possibly the events (I think so? The latest message or something similar).

So that data would be used by GScan.vue to create the tree of workflows, and could be used by any number of components, like Dashboard.vue, which would summarize the stats and also display events.

[kinow]

Similarly, when the user visits /#/workflows/five, if he adds several views with Tree, Graph, Gantt, Dot, etc, I wouldn't expect each component to interact with WebSocket/GraphQL/etc. Instead, I thought the data would be put in the store for these components to simply display - in a reactive way.

[kinow]

Said all that, we can go with the current approach, as this discussion could drag over time, and I think we have a good momentum on Cylc UI, and would prefer to continue the development of new components/views/etc instead of focusing too much on lengthy discussions around this (not too hard to change it later). And as I could very well be wrong too hehe :)

[oliver-sanders]

I wouldn't expect each component to interact with WebSocket/GraphQL/etc. Instead, I thought the data would be put in the store for these components to simply display - in a reactive way

Isn't this what we already have? The WorkflowService is a singleton which handles the REST interface (websocket in the future).

[kinow]

Well, yeah. In a certain way. It will be called every time we navigate to /#/dashboard, while the GScan.vue within Drawer.vue would be called once (components bound to views are created/mounted when you navigate to the route).

I was thinking in a way to load the data common for the view and its components, but let's start with the current approach. If we don't have any issues we won't have to change it, and then we can just close this issue.

[kinow]

ps: just had a quick meeting with Hilary, and after some discussion I think it cleared up a few things for me! Next week I'll write unit tests for the WorkflowService and for other classes, and should understand more how it works and how we are supposed to plug it into our components 🤞

[kinow]

Next on my list. We have the workflow component in a PR, and the GScan component is already working. Time to get the dashboard to show some real numbers.

I have a better understanding of the code, so hopefully will be able to plug in the data for the dashboard with no issues 👍