refs 829e8ed010
- i18n is used everywhere but only requires shared or external packages, therefore it's a good candidate for living in shared
- this reduces invalid requires across frontend and server, and lets us use it everywhere until we come up with a better option
- Having these as destructured from the same package is hindering refactoring now
- Events should really only ever be used server-side
- i18n should be a shared module for now so it can be used everywhere until we figure out something better
- Having them seperate also allows us to lint them properly
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- This one is a little more involved, as the i18n initialisation was unnecessarily spread over several locations.
- I moved it into being part of the ActiveTheme class and called in the constructor, meaning we don't need the services.theme.activated event anymore as the constructor is called in the same cases.
- Also moved the event listener for locales into the bridge, as I don't want that inside of theme-engine, and we don't want circular dependencies. We'll figure out a wayto refactor this soon too.
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this is where it starts to get fiddly as the getActive function in themeService index is required across the frontend/backend mostly due to its use in the getApiVersion method
- for now left one usage of the getActive method in place in ghost-locals middleware ready for the next phase of the refactor, which will move some of the themeService index into a shared location
- This is the beginning of splitting up the theme service into:
- Storage components used by the API (should be a server service)
- Theme engine & rendering components used by the frontend (this new engine service)
- The code to activate a theme which is shared code where the API & frontend need to communicate
- This is needed because currently the frontend theme service is required and used by the API, creating tight coupling.
- In my quest to truly separate the API and frontend, this is one of many battles that needs winning
