Follow-up: Refactor type of work chart data and presentational component

The following discussion from !166170 (merged) should be addressed:

• @ekigbo started a discussion: (+3 comments)

  Note: @apennells It looks like this request is breaking the default state in storybook, previously we just passed the data in, but now we'd need to mock the API request (and probably also mock the fetchTopRankedGroupLabels request) for this story to work correctly.

  additional thoughts:

  I know we shouldnt write code to make testing easier, but I'm curious about the choice to inline the data fetching action?

  Conceptually I think inlining it like this makes sense with apollo+graphql since we provide the apollo client directly to the vue components, while for vuex the preferred pattern is still probably externalise data fetching in the actions.js file + mutations for side effects and then inject state/getters to the component.

  Given we're wanting to remove the vuex module though, we wouldnt really have a way to inject the data into the component I guess, unless we moved them out of the of the typeOfWork module into the root module.

  Is the plan to move/remove the rest of the state from the typeOfWork module over multiple MRs? I'm just a bit curious why we've left the subject, errorMessage and isLoading fields in place, but moved the data state inline, im guessing that would be the plan though given the MR description and if so then we (just me really 😛) will need to live with this halfway point (inlined but not using graphql apollo).