[RFC] Returning onUnmounted within onMounted

[Alfred-Skyblue]

Expecting to return a function in onMounted that will be called in onUnmounted.

PR

expected:

onMounted(() => {
  console.log('onMounted')
  return () => {
    console.log('onUnmounted')
  }
})

[jods4]

What's the motivation? Accessing state inside onMounted?
I believe calling onUnmounted inside onMounted should work (not 100% sure)?

onMounted(() => {
  console.log('onMounted')
  onUnmounted(() => {
    console.log('onUnmounted')
  })
})

If it works, what's the benefit of returning a function?

And in both cases... I wonder: if a component is recycled (unmounted from DOM, then mounted again), both approaches would create multiple unmounted subscriptions, right? That should be avoided (it's not an issue if onUnmounted is called from setup).

[Alfred-Skyblue]

I believe calling onUnmounted inside onMounted should work (not 100% sure)?

Calling onUnmounted within onMounted is effective. I believe that returning a function within onMounted is a more elegant approach; of course, its effect is the same as directly invoking onUnmounted.

And in both cases... I wonder: if a component is recycled (unmounted from DOM, then mounted again), both approaches would create multiple unmounted subscriptions, right?

When the component is unmounted and reinstalled, only one onUnmounted will be registered.

What's the motivation? Accessing state inside onMounted?

I believe it can avoid excessive imports, though I'm not sure if it's a reasonable approach.

This is a breaking change. As for whether it needs to be done, I think it still requires some discussion.

[jods4]

When the component is unmounted and reinstalled, only one onUnmounted will be registered.

How?
When the component is mounted again, mounted event will be called, so onUnmounted will be called a second time, with a different lambda instance.
In fact if the lambda has captured local state, it's important that the previous one is unsubscribed and the new one is subscribed.

I don't see how this would work.

[Alfred-Skyblue]

When the component is mounted again, mounted event will be called, so onUnmounted will be called a second time, with a different lambda instance.

In setup, the onUnmounted will be called for different instances as well, exhibiting the same behavior.

[jods4]

I don't believe so?
https://vuejs.org/guide/essentials/lifecycle.html
That diagram doesn't mention cached components, but it's clear that setup is high up even before create.

[Alfred-Skyblue]

We assume that the 'setup' corresponds to the 'create' hook. When a component is reinstalled, 'setup' is executed, and likewise, 'onMounted' is re-executed. I believe there isn't a fundamental difference between executing 'onUnmounted' in 'setup' or 'mounted'.

[baiwusanyu-c]

This method is functionally consistent with onUnmounted, but I think its semantics are a little harder to understand than onUnmounted.

[dsonet]

I feel like this is more align to react's useEffect...

[Alfred-Skyblue]

Manually invoking onUnmounted is indeed more standardized and easier to understand from a semantic perspective.

[darrylnoakes]

I feel this adds another way to do things without much gain.

I can't just see if I've attached an onUnmounted listener, as it isn't top level with my other lifecycle hooks. I have to look for a return in another one. Inconsistent and confusing.

If I only want to listen for unmount, then I must use a dedicated hook.
If this changes in a refactor, the diff will be confusing.

And I agree with @jods4 about the timing: if a component is unmounted and mounted again, is a new unmount callback registered? What do you do with the existing one?
(The setup only runs on create, and therefore the hooks do too, but the mounted callback can be called multiple times.)

[Alfred-Skyblue]

In Vue, each lifecycle hook can be invoked multiple times, and there is no conflict in doing so.

[HerringtonDarkholme]

I understand the OP's point is that returning an onUnmounted closure can help users reducing one extra import.
While this is elegant, I suspect that the benefit outweighs the drawbacks.

• This introduces a new way to do clean-up on unmount. But these two have almost identical functionality.
• If we want to promote the new return-function style, it may incur unnecessary user churn to learn a new syntax.
• Returning a closure is not in line with other lifecycle methods. Do we want to return a closure of beforeUnmount within beforeMount? The new closure returning syntax also does not look like beforeUpdate and updated.
• There might be potential confusion about this API with React useEffect. useEffect runs every rendering but onMount only runs once. The similar syntax hides the difference in the fundamental mental model. New users coming from React may be confused.

[Alfred-Skyblue]

In svelte, onMount returns a function to execute onDestory, which I think is relatively smooth to use. I don't think this change has a big learning cost. Of course, this is a destructive change. If someone returns a function in onMounted before, it will cause unnecessary confusion in future versions

[Lehoczky]

I feel like this will just make Vue harder to learn and vue apps harder to maintain, because there will be 2 ways of doing the same thing.

If there is nothing to gain from it, I would avoid increasing the complexity of the framework.

[leopiccionia]

I think explicitly calling onUnmounted makes the code more readable.

If we don't want to explicitly import onUnmounted, then we should at least guarantee it's explicitly mentioned on code. A common pattern is the following:

onMounted((onUnmounted) => {
  console.log("mounted")
  onUnmounted(() => {
    console.log("unmounted")
  })
})

I'd rather imported onUnmounted, though.

[Alfred-Skyblue]

Temporarily close this RFC. If someone has passed a function with a return value to onMounted in previous versions, it will disrupt its original functionality.

[dreitzner]

I'm a little late to the discussion, but I'd like to give some insights on actual use cases for this implementation.

The "issue" has to do with variable scoping.

Example where it would be very usfull:

    onMounted(() => {
        const observer = new IntersectionObserver(
            (entries) => {
                // some logic here
            },
        );
        observer.observe(el);

        return () => {
            observer.disconnect();
        };
    });

This would be true for any client side logic that needs cleanup when unmounted.

The extra overhead of the none scoped variable with extra typing and logic of checking if the variable is actually declared is very unergonomic.

Here the above example with the corrent way of doing things:

    let observer: IntersectionObserver|undefined;
    onMounted(() => {
        observer = new IntersectionObserver(
            (entries) => {
                // some logic here
            },
        );
        observer.observe(el);
    });
    onUnmounted(() => {
        if(observer) observer.disconnect();
    })

[jods4]

I think it's common and useful enough to be built-in in Vue, but until then you can create your own easily:

function whileMounted(fn: () => () => void) {
  let cleanup: (() => void) | undefined;
  onMounted(() => cleanup = fn());
  onUnmounted(() => cleanup?.());
}

When doing things let intersection observer I often create a dedicated helper to make the component code more clean, something like:

function useIntersection(fn: (entries) => void) {
  let observer: IntersectionObserver|undefined;
  onMounted(() => {
      observer = new IntersectionObserver(fn);
      observer.observe(el);
  });
  onUnmounted(() => observer?.disconnect());
}