Custom elements are not "cleaned up" when the consuming application removes an element.

[Pixelatedza]

Describe the bug

Hey guys, it appears that custom-elements don't get cleaned up fully when a parent application removes them from the DOM. The issue croped up because of a crash in a child component, specifically a modal that is animated in.

At first I thought it was just the subscriptions to the stores that weren't being removed appropriately. However, in a more complex example, I have nested components with conditional rendering based on the store value, and this logic still gets executed. At least, I assume so, since the components crashing would not be rendered if said logic wasn't applied.

• Site
  • custom-element
    • nested child with logic (subscribes to store)
      • conditionally rendered child (crashes because of missing stylesheet reference).

I assume this is because the components or their subscriptions were not fully cleaned up when the parent removed them from the DOM.

In my project I can work-around the error, for now, by removing the animation. Changing
<div class={`modal ${size}`} transition:fly={{ y: 1000, duration: 500 }}>
to
<div class={`modal ${size}`}>

The error: Uncaught (in promise) TypeError: Cannot read properties of null (reading 'insertRule'). I'm guessing this is because the stylesheet has been removed/cleaned up by either svelte or the browser, but the component still attempts to do it's thing (animate in), because the store value has changed.

Attached a video showing what I'm seeing for what it's worth. I'm running the minaml repo I've linked below.

svelte-bug.mov

Reproduction

Here is a minimal reproduction. You can run svelte as usual, yarn dev. It's in the /vite-project directory. Then open the index.html in the root of the repo in a browser.

If you toggle the content on and click on "change store value", the value of the store will be printed as many times as the content was shown.

https://github.com/Pixelatedza/min-svelte-wc-bug-demo

Logs

No response

System Info

System:
  OS: macOS 11.6.7
  CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Memory: 915.37 MB / 16.00 GB
  Shell: 5.8 - /bin/zsh
Binaries:
  Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
  Yarn: 1.22.19 - ~/.nvm/versions/node/v16.15.1/bin/yarn
  npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm
Browsers:
  Chrome: 109.0.5414.87
  Firefox: 108.0.2
  Safari: 15.6
npmPackages:
  svelte: ^3.54.0 => 3.55.1

Severity

blocking all usage of svelte

[jrmoynihan]

I've been running into the same error:
Uncaught (in promise) TypeError: Cannot read properties of null (reading 'insertRule')

The error is in the /internal module, inside the create_rule function:

// svelte/internal/index.js

function create_rule(node, a, b, duration, delay, ease, fn, uid = 0) {
    const step = 16.666 / duration;
    let keyframes = '{\n';
    for (let p = 0; p <= 1; p += step) {
        const t = a + (b - a) * ease(p);
        keyframes += p * 100 + `%{${fn(t, 1 - t)}}\n`;
    }
    const rule = keyframes + `100% {${fn(b, 1 - b)}}\n}`;
    const name = `__svelte_${hash(rule)}_${uid}`;
    const doc = get_root_for_style(node);
    const { stylesheet, rules } = managed_styles.get(doc) || create_style_information(doc, node);
    if (!rules[name]) {
        rules[name] = true;
        stylesheet.insertRule(`@keyframes ${name} ${rule}`, stylesheet.cssRules.length);
    }
    const animation = node.style.animation || '';
    node.style.animation = `${animation ? `${animation}, ` : ''}${name} ${duration}ms linear ${delay}ms 1 both`;
    active += 1;
    return name;
}

In my case, I have a client-side component (a tooltip) being created through an action on a node that is transitioning in, and rendered inside an {#await} block.

[Pixelatedza]

I did some digging today. I must apologise, it was only after I dug deeper and understood the cause of this, that I realised that there are a few issues that are related to this.

• ondestroy in custom elements #1152
• Prop initialization in web/standalone components #2227
• Call onMount when connected & clean up when disconnected for custom element #4522 - This PR solved some of the gripes.
• Action lifecycle in custom elements #5989

In short, the $destroy is not called when custom elements are removed from the DOM "disconnected", this is intentional. The callback passed to unMount will still be called, that's what the PR above added.

If you need a quick work around for your project, you can use the below code to explicitly call $destroy when the elements disconnect. Just make sure it is run before any elements are defined.

import { SvelteElement } from "svelte/internal";
const _disconnectedCallback = SvelteElement.prototype.disconnectedCallback;
SvelteElement.prototype.disconnectedCallback = function () {
  _disconnectedCallback.call(this);
  this.$destroy();
};

Can we consider adding a compiler option that will add $destroy to the disconnect callback? This leaves it up to the programmer to decide if it's relevant to his project. Potentially also adding it to svelte:options as well.

Something I'm still struggling to figure out is what are the ramifications of doing so? The HTML spec and others have mentioned it doesn't mean the same thing to custom elements, but as far as I can tell, it means no longer in the same DOM. In sveltes case, since the components are isolated by nature, does it matter if it gets destroyed/recreated everytime?

[chronicIntrovert]

I am also running into this issue regardless of custom-element. In my code I have a div that's conditionally rendered by the presence of a $modal store not being null. This div also has transition:fly property and errors on trying to close by setting the store back to null.

[dummdidumm]

Closed via #8457, to be released in Svelte 4