Vue 3 - Can't use `setup()` in Node View

What happens? If you create a Vue 3 component for a node view with a setup() method, it is never called.

This seems to be because when doing this to extend the component it doesn’t inherit the setup method:

https://github.com/ueberdosis/tiptap-next/blob/6d665711289f46933be6ca0063d45597972ad6e4/packages/vue-3/src/VueNodeViewRenderer.ts#L144-L151

I tried extends: (component as any) rather than unpacking and it didn’t work. (Haven’t been able to get my head around Vue 3 types on components, Component and DefineComponent don’t seem to work…)

This however sort of does:

    const extendedComponent = defineComponent({
      extends: { ...component },
      props: Object.keys(props),
      components: {
        NodeViewWrapper,
        NodeViewContent,
      },
      setup() {
        if((component as any).setup) {
          return (component as any).setup()
        } else {
          return {}
        }
      }
    })

However, a quick test with a component like this:

<template>
  <node-view-wrapper data-type="counterLine">
    <node-view-content as="p" class="counter-content"></node-view-content>
    <p class="counter-output" contenteditable="false">
      Counter: {{ counter }}
    </p>
  </node-view-wrapper>
</template>

<script>
import { defineComponent, ref, onBeforeUnmount } from 'vue';

export default defineComponent({
  name: 'CounterLine',
  
  setup() {
    const counter = ref(0);

    const interval = setInterval(() => {
      counter.value++
    }, 1000)

    onBeforeUnmount(() => {
      clearInterval(interval)
    })
    
    return { counter }
  }
  
})
</script>

Shows that we are getting a mismatch on components to node views, when I add new lines in the middle the the nodes at the bottom are the new ones with a zero counter:

https://user-images.githubusercontent.com/31130/109534874-bcc9ab80-7ab3-11eb-8b67-32994c40e1c4.mov

[philippkuehn]

The initial issue is fixed so I’m closing this for now.

But the caching problem still exists, of course. And I can’t imagine right now that we can really fix it. But we should probably open a new issue on that (there is already this one in v1: https://github.com/ueberdosis/tiptap/issues/372)

[samwillis]

Yep, sorry didn’t explain that very well.

I believe we may be able to change the <teleport :to= target to another element, moving the component. So when prosemirror creates a new node view (rather then moving it and even before removing the old one) we may be able to detect that and move the component instance to the new location in a new container element (leaving behind the old container to be removed by prosemirror).

With this we can’t do the unwrapping we currently do (so requiring attribute mapping onto the container element) but may enable retaining state within the component as it is moved.