You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently worked on support for static analysis of nuxt plugin hooks when using the object syntax. This massively improved hooking for us and allowed us to discover one short-coming of plugin hooks / plugin execution order.
Imagine the following situation: Your Nuxt App uses two modules, one is the official @pinia/nuxt module which is used for creating a store that hold the locale of the application. The other module is one you write yourself and handles authentication. The authentication module allows you to hook into an event whenever the signed in user identity changes. You now want to update your stored locale whenever the locale of the identity changes to reflect the preferences of your user.
To make that happen you create a plugin in your app that listens to the event, gets the store and updates the locale if necessary.
You now realize that this won't work, as you depend on the pinia plugin to have been executed before your hook callback is executed, otherwise there is no active pinia instance. Since the authentication module is generic and doesn't need pinia, it doesn't depend on pinia and might run in parallel with it.
To solve this I'm proposing the following solution
Emit an event whenever a plugin has been resolved, app:plugin:resolved, with a callback parameter of the plugin name.
Keep track of the resolved plugins
Add a nuxtApp method runAfterPlugin that allows a user to register a callback that is executed either immediately (if the plugin has been resolved already) or whenever the app:plugin:resolved event for the relevant plugin is called.
This allows a user to side-step any race-conditions like described above. It is basically the runtime inverse of the statically defined dependsOn. Instead of defining which other plugin you might rely on before executing them, it allows for depending on plugins at runtime.
Additional information
Would you be willing to help implement this feature?
Describe the feature
I've recently worked on support for static analysis of nuxt plugin hooks when using the object syntax. This massively improved hooking for us and allowed us to discover one short-coming of plugin hooks / plugin execution order.
Imagine the following situation: Your Nuxt App uses two modules, one is the official
@pinia/nuxt
module which is used for creating a store that hold the locale of the application. The other module is one you write yourself and handles authentication. The authentication module allows you to hook into an event whenever the signed in user identity changes. You now want to update your stored locale whenever the locale of the identity changes to reflect the preferences of your user.To make that happen you create a plugin in your app that listens to the event, gets the store and updates the locale if necessary.
You now realize that this won't work, as you depend on the
pinia
plugin to have been executed before your hook callback is executed, otherwise there is no active pinia instance. Since the authentication module is generic and doesn't needpinia
, it doesn't depend onpinia
and might run in parallel with it.To solve this I'm proposing the following solution
app:plugin:resolved
, with a callback parameter of the plugin name.runAfterPlugin
that allows a user to register a callback that is executed either immediately (if the plugin has been resolved already) or whenever theapp:plugin:resolved
event for the relevant plugin is called.This allows a user to side-step any race-conditions like described above. It is basically the runtime inverse of the statically defined
dependsOn
. Instead of defining which other plugin you might rely on before executing them, it allows for depending on plugins at runtime.Additional information
Final checks
The text was updated successfully, but these errors were encountered: