Tracking Issue: Remove use of Vuex in favour of composables

[rtibbles]

Overview

Our usage of Vuex for state management has caused some additional complexity, often simply due to the way that we have used it using shared global state that can be independently updated by different code paths.

Of more concern is the fact that our use of Vuex in the core of the app creates an implicit API that it becomes hard to reason about, and difficult to alert to end users when it is no longer available. This is because to access Vuex state, getters, or actions, they are referenced in components using e.g.: mapGetters(['isAdmin', 'isLearner']) - so if we were to rename these, update them, or remove them, code relying on them would would very little indication that something had gone awry.

Description and outcomes

It is desirable to remove our usage of Vuex as we update and make changes to our code base.

However, because of the extent of our usage of Vuex, this should be done incrementally.

As the primary concerns are removal of an implicit API, and mutations to shared state across different pages within apps, these should be addressed first - so removal of the core Vuex state, getters, mutations, and actions is the first focus of this tracking issue. Individual plugins can then be independently responsible for registering Vuex and instantiating the store, and can take their own path to removing dependence on vuex.

Core Vuex API

Preview Give feedback

1. Create equivalent of getters for all accessed session state and all getters in useUser composable #11723
   DEV: frontend help wanted +2
   
2. Migrate all existing references to session getters and state to the useUser composable #12203
   DEV: frontend TAG: tech update / debt help wanted +3
   
3. Move login/logout logic into the useUser composable and update references #12204
   1 of 1
   DEV: frontend TAG: tech update / debt help wanted +3
   
4. Create composable for connection monitoring and replace existing logic with it #12205
   DEV: frontend TAG: tech update / debt help wanted +3
   
5. Create composable for snackbar state and replace existing logic with it #12206
   DEV: frontend TAG: tech update / debt help wanted +3
   
6. Remove core vuex channel fetching logic and state and move to coach #12557
   +0
   
7. Refactor FacilityConfig and Facility fetching out of core into the plugins that need it #12708
   DEV: frontend TAG: tech update / debt +2
   
8. Create a composable for total progress fetching and points calculation #12619
   DEV: frontend help wanted +2
   
9. Move core notifications handling into NotificationsRoot component #12626
   DEV: frontend TAG: tech update / debt help wanted +3
   
10. Create composable in kolibri-common for pageSessionId handling and samePageCheck generator
11. Move pageVisibility state and monitoring code into the browserInfo utilities module
12. Update session scope setting to use the useUser composable kolibri-sentry-plugin#3
    +0
13. Update error capturing to no longer rely on Vuex state kolibri-sentry-plugin#4
    +0
14. Migrate core error handling to a composable

[nick2432]

can i try this one?

[MisRob]

Hi @nick2432, thank you for volunteering. This is already assigned to @rtibbles. I recommend searching for "help wanted" issues.

[nucleogenesis]

It may be worth looking at the changes to how the promises are handled in CoachToolsModule in #12755 - the issue that I ran into there was in part related to the fact that the handleApiError action ends with throw error - which led me to run into weird UncaughtError issues when the handleApiError was dispatched within the beforeRouteEnter guard.

When I removed that throw error line, however, the issue was resolved.

But, there are too many uses of the handleApiError action in Kolibri for me to make that change to fix that particular problem, but during work on this issue it'd be worth considering whether or not we need or want it to throw the error back at us.

FWIW - when I removed that throw error the tests passed... but that doesn't mean we've covered error-throwing cases in particular though so it'll require some manual review in service of this issue.