v-if throws an error if toggled off after the element has been removed from the DOM through other means

[araney]

Version

3.5.24

Reproduction link

play.vuejs.org/

Steps to reproduce

• click "Remove Target" to remove the target element (which has a v-if directive on it)
• toggle "Show Target" to trigger the v-if directive's hide behavior
• note the error that is thrown "Cannot read properties of null (reading 'insertBefore')"

What is expected?

Toggling a v-if for an unbound element should be a no-op. Nothing should change.

What is actually happening?

An uncaught error is being thrown, which can break other parts of a complex application.

---

This bug was encountered when interacting with other custom directives. A local change to Vue to include a null check against the "parent" in "nodeOps.insert" within "runtime-dom.esm-bundler.js" resolves the issue.

[Justineo]

This is not a bug. You can’t remove a node that is meant to be managed by Vue. Vue is a data-driven framework so every change comes from the view model.

[araney]

@Justineo I agree with that, on principal. However, there may be situations where other custom directives have the need to manage DOM elements, including adding or removing them. v-if's current behavior, without a proactive null check, makes it dangerous to manage DOM elements in this way in custom directives.

[Justineo]

However, there may be situations where other custom directives have the need to manage DOM elements

That isn’t supposed to work. The problem isn’t null checks. The whole approach is bound to fail because it mixes two sources of truth. Your suggestion only masks the issue in a very specific case, and it doesn’t address the root cause from the framework’s perspective.

[araney]

Alright -- is there a framework specific suggestion to allow custom directives to manage DOM element rendering in a v-if safe way? Perhaps a way for a custom directive to apply other directives to a component (so that it could use v-if internally and avoid this issue of multiple sources of truth)? This is coming from a library author point of view, where we won't have full control of the user code utilizing the directives.