The vast majority of frontend code in Kolibri is accessed via module that acts as the driving Single Page App for that particular URL endpoint.
These SPAs all define the following functionality:
URL Routes under their Django defined entry points
Instantiating a Vuex Store for client side state management
An entry component that acts as an initial render point and controller for the SPA
As such, I propose we create a SinglePageApp subclass of the KolibriModule class that implements the following functionality:
Router initialization based on a routes hash
Store initialization based on the core store module and the SPA's own store (ideally, this would depend on #2022, and not actually require the initialization of the store to be delegated to the SPA, rather the SPA would register these new Vuex modules against a store that has already been instantiated in the core app - using the Vuex2 functionality that allows for dynamic registration of modules).
This seems like a good move to me. I think it might be best to wait until after Vuex upgrade/refactor, so that any changes or new patterns can be factored in first.
Summary
The vast majority of frontend code in Kolibri is accessed via module that acts as the driving Single Page App for that particular URL endpoint.
These SPAs all define the following functionality:
As such, I propose we create a SinglePageApp subclass of the KolibriModule class that implements the following functionality:
routes
hash