refs are not available on $nextTick when using portal

[sunabozu]

Hi.

This is not very standard issue, but it's definitely caused by portal-vue. Let's see the code:

<portal to="whatever">
  <div v-if="open" ref="div">
  ...
  </div>
</portal>

methods: {
  handler(e) {
    this.open = true

    this.$nextTick(() => {
      const rect = this.$refs.div.getBoundingClientRect()
  }
}

If I click a button somewhere and trigger my handler, I get an error, because this.$refs.div is undefined. The element inside the portal isn't rendered yet at this point. But when I do the same without the portal, it works as intended. So far I couldn't come up with an adequate solution. Any ideas?

[LinusBorg]

I'll have a look at this, but I'm not sure I can find a proper solution.

The reason for this beahviour is that I postpone the rendering update of any portal-target with a setTimeout(..., 0). I do because I have to prevent race conditions as best I can when portal targets or sources are switched dynamically, and to do so I collect all updates, then clean old contents and only after that insert all new contents.

This timeout is what produces your behaviour.

I'll try and find a solution, but can't promise anything yet.

[LinusBorg]

Hm, so I switched the mechanism for my async scheduler to use $nextTick, but that doesn't help.

I have ideas about how to make the wormhole updates happen synchronously, but that might technically be a breaking change, but only a little one.

Anyways and I won't attempt to make this change this before #26 is done, so this will move to the 1.1 Milestone for now.

[LinusBorg]

I will close this in favor of a real feature issue #39

[bimbiltu]

Hey @LinusBorg I may be doing something wrong but I dont think this was ever solved with #39: https://jsfiddle.net/ke9b8j4e/3/ (i inlined portal-vue so youll need to scroll to the bottom of the script section to see the app code)

I found that if I use a second $nextTick then the $ref is populated as expected

[LinusBorg]

Please open a new issue