Event "destroy" not exist in Svelte3 anymore.

[stalkerg]

I found one of important lack of functionality during porting my code to svelte3 from the second version. Looks like we have no "destroy" event outside of component anymore. It's an important part of the public component API.
Basically, we have $on the method but without the "destroy" event it's useless
Also, we should have some extra lifecycle hooks outside of the component, it's important for routing and some other cases.

[Rich-Harris]

The difference in Svelte 3 is that component's can't self-destruct — there's no equivalent of this.destroy(). If a component can't destroy itself, that implies that some parent or controller must destroy it, which means you already have a place to put whatever logic you were going to put in the event handler.

Inside a component, you can use onDestroy (or a function returned from onMount) to handle any internal cleanup.

What's a (concrete) scenario in which this is necessary?

[ryanatkn]

Current workaround with a one-liner (+import) for each component that needs an observable destroy event (using public api):

https://svelte.dev/repl/689a66f5a7af4f498a7d4519a63c49af?version=3.5.4

// Comp.svelte
useDestroyEvent();

// other.js
export const useDestroyEvent = () => {
	const dispatch = createEventDispatcher();
	onDestroy(() =>	dispatch('destroy'))
}

[timeshift92]

comp.$$.on_destroy.push( ()=> console.log('asda'))
its work

[Conduitry]

svelte-state-renderer now has a PR to simply call the appropriate code upon destroying the component - TehShrike/svelte-state-renderer#21

As I understand it, this ASR bug was why this issue was opened in the first place. Is there another reason to have this?

.$$.on_destroy.push is not a viable long-term solution, as nothing in $$ is guaranteed to stay the same between versions of Svelte.

[stalkerg]

component.$destroy() is it atomic operation or it's the async method?

[stalkerg]

Current workaround with a one-liner (+import) for each component that needs an observable destroy event (using public api):

https://svelte.dev/repl/689a66f5a7af4f498a7d4519a63c49af?version=3.5.4

// Comp.svelte
useDestroyEvent();

// other.js
export const useDestroyEvent = () => {
	const dispatch = createEventDispatcher();
	onDestroy(() =>	dispatch('destroy'))
}

@Rich-Harris I need something like this, but if I run onDestroy outside I get next error:

Uncaught Error: Function called outside component initialization

probably because I am using splitting code and this js contains in the separate chunk.

[stalkerg]

hmm for me onDestroy not working at all.

[stalkerg]

Sorry, it's happening because it was in my rollup config:

extensions: ['.js', '.mjs', '.json', '.html'],

but in your store.mjs you make local import (from '../internal') in that case rollup didn't check package.json and firstly try index.js after start working commonjs plugin and dublicate set_current_component method.
I fix it just change order for extensions:

extensions: ['.mjs', '.js', '.json', '.html'],

[Conduitry]

Closing this. As Rich mentioned, the only way a component can be destroyed now is if someone destroys it. Re-open if you have a specific case where this event is necessary and you can't just emit it yourself.

[ChrisTalman]

Hey @Conduitry. It crossed my mind that there might be a use case for this, relating to third party libraries.

It's quite common to use a third party library to do something for you in the DOM. For instance, Choices.js or Material Datetime Picker. It's also quite common to wrap the functionality of those libraries in your own generic components, for use in a lot of places, where the consumers don't need or want to worry about the complexity within those components, particularly that concerning the interaction with the third party library.

In such cases, it can often be important to handle the generic component being destroyed. Otherwise, the library might malfunction or exhibit a memory leak, unaware that its elements have been removed from the DOM. If it is possible to listen for a destroy event, the library can be handled automatically by the generic component when that event fires, without any work on the part of consumer of the generic component.

Such manual handling would seem to be problematic in several regards. First, the handling could be quite complex, depending upon the nature of the functionality of the generic component. It might be thought that consumers should not be exposed to such complexity. Second, it would seem to constitute unpleasant boilerplate, required for each and every instance in which the generic component is used. Third, it would seem error-prone, as a consumer could easily forget to implement the boilerplate.

I've used destroy in Svelte 2 for this purpose on several occasions. I would imagine that similar occasions could arise for users of Svelte 3, and thus a destroy event would seem to be of value.