Dynamic Lifecycle Injection about core HOT 6 CLOSED

Love it as well as the other part of this.

A nice side effect of this approach would be that it solves the problem of naming conflicts when we would introduce new lifecycle hooks in later versions, right?

Right now, in the public discussion about the class API, we are in a back and forth how to namespace lifecycle hooks when using the class API. If we declare lifecycle hooks deprecated, or committed to introducing new hooks as these dynamic lifecylce hooks only, risks of breaking our user's code in the future disappear.

from core.

I don't get why using value instead of state here.

Yes, the fetch example can use state instead.

For the mouse example, if you return a plain object, x and y becomes actual JavaScript values, and they will never update. Then you would have to bind the object like this instead:

data() {
  const mouse = useMousePosition()
  return {
    mouse
  }
}

Then access it as mouse.x and mouse.y. This works of course, but you'd have to do this even if the function only exposes a single value - which essentially is a ref.

Do the same rule for automatic watcher removal apply to hook listeners?

Lifecycle hooks don't need to be explicitly removed if the component is already unmounted (because they would never fire again)

from core.

I could totally see a babel plugin compiling res = to res.value = 😸

from core.

I don't get why using value instead of state here.
Do the same rule for automatic watcher removal apply to hook listeners?

Everything else looks good!

Regarding replacing lifecycle hooks in class declarations, I don't think we should replace them because it's a less intuitive api

from core.

Published: vuejs/rfcs#23

from core.

in vue2

<Child @hook:mounted="doSomething"></Child>

parent components can listen to its children's’ lifecycle hooks. especially for third-party components.

What should we do in VUE3?

from core.