Using modifyClass for objects which are initialized early in boot
When using modifyClass in an initializer, you may see this warning in the console: (type) has already been initialized and registered as a singleton. Move the modifyClass call earlier in the boot...
View ArticleUsing modifyClass to change core behavior
I presume it is impossible or at least unreliable to attempt use modifyClass (within the legal use cases mentioned above) within a plugin on another plugin’s Component in the same install? Even if it...
View ArticleUsing modifyClass to change core behavior
If both plugins are installed and enabled, it should work with no problems. If the target isn’t installed/enabled, you’ll get a warning in the console. But you can use the ignoreMissing parameter to...
View ArticleUsing modifyClass to change core behavior
So how does that work, it defers the application until all components from all plugins have been registered and loaded? I think I have a case which doesn’t appear to work. Read full topic
View ArticleClik here to view.
Using modifyClass to change core behavior
All ES6 modules (including components) are defined first, then we run pre-initializers, then we run regular initializers. So yeah, by the time any initializer runs, all components are resolvable....
View ArticleClik here to view.
Using modifyClass to change core behavior
My bad, you need to be careful you provide the full path! e.g.: api.modifyClass("component:chat/modal/create-channel", neither: api.modifyClass("component:create-channel", nor even...
View Article