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
- [ ] https://github.com/learningequality/kolibri/issues/11723
- [ ] https://github.com/learningequality/kolibri/issues/12203
- [ ] https://github.com/learningequality/kolibri/issues/12204
- [ ] https://github.com/learningequality/kolibri/issues/12205
- [ ] https://github.com/learningequality/kolibri/issues/12206
- [ ] https://github.com/learningequality/kolibri/issues/12557
- [ ] https://github.com/learningequality/kolibri/issues/12708
- [ ] https://github.com/learningequality/kolibri/issues/12619
- [ ] https://github.com/learningequality/kolibri/issues/12626
- [ ] Create composable in kolibri-common for pageSessionId handling and samePageCheck generator
- [ ] Move pageVisibility state and monitoring code into the browserInfo utilities module
- [ ] https://github.com/learningequality/kolibri-sentry-plugin/issues/3
- [ ] https://github.com/learningequality/kolibri-sentry-plugin/issues/4
- [ ] Migrate core error handling to a composable
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.