-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Javascript initializer doesn't have access to certain data #169
Comments
An alternative solution could be making core's boot process be handled by an initializer as well. On one hand, that makes all boot processes first class citizens, and increases flexibility for extensions. It also simplifies registering "post initializers". On the other hand, there is a certain value to keeping core's boot separate in the code, as that implies authority/importance. We'd also need to choose a priority at which core's boot should happen that doesn't break any extensions that may have registered their initializers after that. |
While we're on this, I think that we should move initializers from using an ItemList to forcing boot in order of execution, so that JS would be booted in the same order as backend code. We might need a bit more work done on flarum/framework#1318 before that's feasible, but it would ensure consistency across backend and frontend boot. Perhaps we could introduce something similar to backend ServiceProviders with |
I believe there are valid use cases where an extension needs to be initialized last in the frontend. Like a theme type of extension, so that it's the last one to make changes to components after all extensions. ItemList allows that by specifying a priority. |
But which priority? IMO, numerical priorities are fine for stuff like component ItemLists where order is more-or-less arbitrary, but with boot, it's preferable to be precise. For themes, I'd prefer some sort of theme extender, that would apply JS/CSS after all other types of extensions |
The initialization callback is called before the store, forum and session are filled/populated, so you cannot access for example serialized setting values. The workaround for that is to directly use
app.data.resources
, but that's inefficient.@askvortsov1 proposed to add second stage initializers that would run later, which seems to be the best way to go about this.
https://github.com/flarum/core/blob/fd5de6929ec8fd0fb2ff71d0abad70e20007c096/js/src/common/Application.js#L167-L177
The text was updated successfully, but these errors were encountered: