Commit Graph

16 Commits

Author SHA1 Message Date
Hannah Wolfe
3d47d11fd4
Added clarifying note to bridge
- This question came up in an architecture meeting so I thought I would document it in place, immediately
2021-09-30 15:43:39 +01:00
Naz
dbb78820b3 Removed unnecessary error parameter in bridge
no issue

- The error parameter is passed arround by never used. Removed it to have less type check errors
2021-09-23 18:39:43 +02:00
Naz
035ad01f24 Swapped to American English spellings
refs 16728a3ef1

- initialised -> initialized
2021-09-23 18:36:38 +02:00
Hannah Wolfe
61e1b19d46
Added comments to all usages of lib/common/events
- This is a precursor to trying to split apart into:
   - model events + webhooks system which makes sense
   - frontend events which should be independent or removed
   - maybe some concept of a settings manager that we can use in various places to bind logic 🤔
   - other usages of events that should be refactored to not use events
2021-07-07 16:02:44 +01:00
Hannah Wolfe
e7b80e50dc
Refactored bootstrap.init to require route settings
- The router bootstrap is no longer allowed to fetch it's own settings, but rather is passed them
- This moves the call to the site routes.js file, which isn't much better but it's a start
- The goal is to always pass these in from the boot process, or from the bridge reloader
2021-07-07 10:25:45 +01:00
Hannah Wolfe
bab5764179
Simplified + unified debug naming conventions
- Reduced the number of levels in our debug naming in the frontend
- Unified components like "themes" and "routing" under one name
- Should help to make debug slightly more useful again
2021-07-07 09:57:14 +01:00
Hannah Wolfe
bd597db829
Moved settings/cache to shared/settings-cache
- This is part of the quest to separate the frontend and server & get rid of all the places where there are cross-requires
- At the moment the settings cache is one big shared cache used by the frontend and server liberally
- This change doesn't really solve the fundamental problems, as we still depend on events, and requires from inside frontend
- However it allows us to control the misuse slightly better by getting rid of restricted requires and turning on that eslint ruleset
2021-06-30 15:49:10 +01:00
Hannah Wolfe
2c729e99f9
Added reload frontend wrapper to bridge
- Allows for slight decoupling of API and frontend with route settings being updated
- Activate theme now calls the same codepath to reload the frontend
- Yet another step on the path to make it possible to init/reload/run the frontend independently from the server
2021-06-29 18:45:03 +01:00
Hannah Wolfe
218df4b5a4
Removed i18n.js from the bridge
- part of our work to deprecate our broken i18n implementation
2021-06-28 09:51:39 +01:00
Sam Lord
caea330647 Change to use @tryghost/logging
no issue

Logging is now controlled by a logginrc.js file in the root of the project - and now we can just import @tryghost/logging everywhere
2021-06-15 15:59:11 +01:00
Hannah Wolfe
16728a3ef1
Swapped to American English spellings
- Traditionally all of Ghost's public-facing text was written in British English
 - We're changing that to US English because that's more common
 - US English should also be used in code e.g. properties are called color not colour
 - most of these changes are in comments, but I've changed them so that we have US English in front of us always
 - fixed a few other typos I noticed whilst there
2021-06-09 16:39:06 +01:00
Hannah Wolfe
9ce407966f Improved theme locale handling
- when activating a theme, we need to load the current locale
- this request used to be buried deep in the themeI18n init call
- now we surface it in the bridge and pass it down, which is closer to what we want to do with eventually initialising the frontend
with everything it needs up front (or not initialising it, if it isn't needed)

- in the related helpers we depend on the site.locale value instead of proxy -> themeI18n -> settingsCache drastically simplifying the code and removing deep requires
- site.locale is updated via middleware and can be relied upon
2021-05-05 16:13:26 +01:00
Hannah Wolfe
273e220327 Moved i18n to shared
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
2021-05-04 13:03:38 +01:00
Hannah Wolfe
829e8ed010 Expanded requires of lib/common i18n and events
- 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
2021-05-03 17:14:52 +01:00
Hannah Wolfe
af09d55c7a Moved activate from themes to the bridge
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
2021-04-27 13:52:19 +01:00
Hannah Wolfe
fdefa4964f Moved bridge into its proper location
- Modules in /shared are supposed to be standalone modules that can be required by the server or frontend
- As the server shouldn't require the frontend, and vice versa, shared modules should require neither
- Otherwise it just becomes a crutch for allowing cross-depenencies, and will create circular dependencies

The Bridge
- The bridge file is not meant to be a crutch sat allowing cross-dependencies, but rather a new component that manages the flow of data
- That data flows from the server/boot process TO the frontend, and should not flow in the other direction
- The management of that flow of data is necessarily hacky at the moment, but over time the architecture here should get clearer and better
- Still, for the time being it will need to handle requiring across components until that architecture matures
- Therefore, it should live in core root, not in core/shared
2021-04-26 14:38:57 +01:00