You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Vuex store has the methods to store the data.workflow object. And the service discards any other top level entry such as nodesEdges, tasks, etc. Picking only workflow.
But while reviewing cylc/cylc-flow#3337 & cylc/cylc-uiserver#70, and experimenting with Cylc UI to confirm nothing was broken, I noticed that the WorkflowService never populated the Vuex store.
We can work around it with GraphQL aliases, but it only works until another query is registered that overrides it by requesting workflows {}.
Maybe the WorkflowService would have to be renamed to GraphQLService, or simply refactored to store the data in the Vuex store, without picking any of its attributes.
The text was updated successfully, but these errors were encountered:
Both tasks and nodesEdges can be sub fields of workflows ... but this seems kinda restrictive (as each query will be binned into the workflows by force)... I would vote to use data
The current implementation of the
WorkflowService
is tailored for a GraphQL such asThe Vuex store has the methods to store the
data.workflow
object. And the service discards any other top level entry such asnodesEdges
,tasks
, etc. Picking onlyworkflow
.But while reviewing cylc/cylc-flow#3337 & cylc/cylc-uiserver#70, and experimenting with Cylc UI to confirm nothing was broken, I noticed that the
WorkflowService
never populated the Vuex store.We can work around it with GraphQL aliases, but it only works until another query is registered that overrides it by requesting
workflows {}
.Maybe the
WorkflowService
would have to be renamed toGraphQLService
, or simply refactored to store thedata
in the Vuex store, without picking any of its attributes.The text was updated successfully, but these errors were encountered: