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

Destroy hook in plugin for hotReload #1471

Open
jdoubleu opened this Issue Dec 12, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@jdoubleu
Copy link

jdoubleu commented Dec 12, 2018

What problem does this feature solve?

So far it is only possible for a plugin to be registered through a single function. On the other hand it is not possible to hook into a plugins destroy/replacement.
In production mode there is no need for such hook, because it's not possible to remove a plugin (this might be reconsidered after #467 (comment)).

But given the plugin example which registers event handlers on the socket and taking hot reloading into account, the handlers are registered multiple times.
There is no way to unregister an event handler before the plugin gets replaced.

I'm not sure if this is a general problem with a HMR system (like webpack's) or if its caused by the store.hotUpdate() function. I suspect, that even store.subscribe() gets called multiple times causing the code to be executed multiple times after some hot replacements.

Workaround:
Store event handlers in a local variable outside the plugin's context.

What does the proposed API look like?

Either additional methods exposed by the plugin (similar to this):

const myPlugin = {
  init(store) {
     registerAllEventListeners()

     store.subscribe((mutation, state) => {
        doSomething()
     })
  },
  beforeDestroy(store) {
     unregisterAllEventListeners()
  }
}

Or as a store instance method:

const myPlugin = (store) => {
   registerAllEventListeners()

   store.subscribe((mutation, state) => {
       doSomething()
   })

  store.subscribeBeforeDestroy(() => {
     unregisterAllEventListeners()
  }
}

The latter wouldn't introduce breaking changes of the plugin API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment