Replace $el and $refs with methods. Without $el and $refs accessing the DOM in Vue 3 get's much harder

[lyle45]

Taken from here, to create a discussion vuejs/core#3868

---

What problem does this feature solve?
I have posted the following message in Quasar framework discussion board and thought of bringing it here for discussion as well as this is relevant for any Vue 3 application and especially relevant for ui frameworks

Since template refs are now declarative only, there is no standard way of accessing at the minimum, root elements.

My Post from quasarframework/quasar#9500:

Point for thought, now that this.$el and this.$refs are deprecated or removed from Vue 3, accessing the DOM get's much harder

Take for example very simple situations where you'd want to access the DOM of QPage to attach events programmatically, or maybe you want to focus on QBtn after an action or want to set the caret inside a QInput as discussed and solved specifically here

In Vue 2, this was a relatively easy task,

If I wanted to measure the width and height of QCard I could easily do this.$refs.myCard.$el.clientHeight or even the riskier this.$refs.myQInput.$refs.input to access native input element

There are many reasons we'd need access to the DOM and I certainly don't expect QBtn to implement focus() method or any other specific solutions

This is a problem with whole Vue 3 IMO and not specific to Quasar, but might be preemptively solved or discussed here

So my general direction for solution for this was having all or most components expose getRootElement() method systematically and others should also have getNativeElement() if relevant. This could relatively easily be implemented with shared composables, but the template ref part would still need to be implemented in all components individually

The only oversight I currently think of for this, and the reason this.$el was removed from Vue 3, is that components can now have more then 1 root element. Not sure of best way to solve this systematically but simplest solution would be to simply return an array of refs for getRootElement(). Maybe it should always return array for consistency

I would love to hear thoughts on this as I mulled over it for some time. I truly think this might have been an oversight on the Vue's team front

What does the proposed API look like?
So my general direction for solution for this was having all or most components expose getRootElement() method systematically and others should also have getNativeElement() if relevant. This could relatively easily be implemented with shared composables, but the template ref part would still need to be implemented in all components individually

The only oversight I currently think of for this, and the reason this.$el was removed from Vue 3, is that components can now have more then 1 root element. Not sure of best way to solve this systematically but simplest solution would be to simply return an array of refs for getRootElement(). Maybe it should always return array for consistency

In Vue 3 built with composition api only, would $el still be relevant? Are declared refs in composition api go to $refs object?

i.e.

<q-card ref="myCard"></q-card>
...
setup() {
const myCard = ref(null)

function attachNativeDOMEvents() {
    myCard.value.{one of cards native DOM element?}.addEventListener(...)
}

return {myRef}
}

• If someone were to access the following component using a template ref, would myCard be registered with $refs?

• would you access myCard.value.$refs.cardContainer if card used a composition template ref to register its container (which of course is dangerous by itself but sometimes unavoidable)?

• If it's using fragments and you want to calculate width and height or set scroll position, would you do myCard.value.$el.scrollTop?
  since it's from a third party library, you can't rely on card insides (options or composition).

• Would each library have to solve this periodically for it self creating many different standards?

@LinusBorg Moved this over here

[LinusBorg]

Point for thought, now that this.$el and this.$refs are deprecated or removed from Vue 3, accessing the DOM get's much harder

These options are not deprecated and, I clarified that fact in the original issue already.

Now, to your questions:

If someone were to access the following component using a template ref, would myCard be registered with $refs?

Yes.

would you access myCard.value.$refs.cardContainer if card used a composition template ref to register its container (which of course is dangerous by itself but sometimes unavoidable)?

Yes, you can. Or use myCard.value.$el

If it's using fragments and you want to calculate width and height or set scroll position, would you do myCard.value.$el.scrollTop?

For a component using fragments, $el returns the placeholder element that Vue uses to "wrap" the root nodes (see docs). You could get the first "real" root node with $el.nextSibling. See this playground for an example.

Would each library have to solve this periodically for it self creating many different standards?

Since the APIs are still there and available, I don't see anything major libraries would have to solve here.

[lyle45]

@LinusBorg Ok thx for explanation sorry for all the bs

probably should improve docs relating to $refs with composition apis, it is not clear that template refs are actually registered both under $refs and inside your declared setup variable (any caveats for having double references there?)

also, placeholder element for fragments is not written anywhere in the docs (no mention of nextSibling, or how to use it)

But this still raises a few questions like in the previous scenario

<q-card ref="myCard"></q-card>

If I don't know anything about the inside of the component, and want a generic solution for checking scrollTop for e.g.

• Is there an isPlaceholderElement boolean or method somewhere?
• Is there placeHolderEleme.length? I saw DOMs api childNodes.length is 0
• maybe there's a place to consider a generic method/getter for $mainEl that will either return root element if single root component, or the first element that contains v-bind="$attrs" if fragmented component? That way, normalized api for both fragments or other parts and usage becomes simple

what do you think?

[LinusBorg]

also, placeholder element for fragments is not written anywhere in the docs (no mention of nextSibling, or how to use it)

it's a DOM text fragment, its API is documented on MDN and you can quickly inspect it in the console like I showed.

Yes, that's not a nice way, but you said yourself you already are in kinda dangerous territory so at this point of the discussion I'm not convinced that offering an official API to do this is indeed a good idea.

For many scenarios, another approach like wrapping the fragment component in a div in the parent, getting a ref to that element and then querying for what you need in that component with vanilla DOM APIs might be a good enough escape hatch for these types of edge-case scenarios (of which I haven't come across many - feel free to share real-life use cases, please).

You are already reaching into the component's implementation Details, which could change and break your code on the next patch release because its author did not intend for the consumer to i.e. use an internal ref in that way, or might reorder or restyle (root or other) elements in a way that your logic breaks.

And If you "don't know anything about the inside of the component", then getting the first element, or the one with v-bind="$attrs" might not really be helpful or what you need either (and very hard to implement for us).

For example, the element with v-bind="$attrs" might be a small input field in a much larger component, so getting its dimensions might now be what you want. Or the first element in the component is actually hidden with v-show but thats not a problem because you really need the second element anyway. etc. pp.

[lyle45]

@LinusBorg

A bit short on time so short answer for now,

let's put accessing internal $refs aside as that clearly shouldn't be indulged with formal api,
but using components $el is generally less dangerous as (or at least was) as it's consistent

small example that comes to mind would be integrating with 3rd party libraries that work with html elements

<q-img ref="myImg" />
...
setup() {
  Panzoom(myImg.value.$el)
}

sometimes applying on outer div wouldn't be desired

For example, the element with v-bind="$attrs" might be a small input field in a much larger component maybe v-container directive is desired to indicate $mainEl devland desire?

[leopiccionia]

@lyle45 I think it's more robust to use something like myImg.value.$refs.img or myImg.value.$refs.wrapperEl.

[lyle45]

@leopiccionia Disagree.
using third party libraries internal refs is quite dangerous as they are unstable, can change without notice and don't have clear standards. that's why I'm suggesting a standard solution that would be used the same way for all third party libraries

[LinusBorg]

The only thing a hypothetical v-container directive would give you over a normal ref is a "default" name for parents to use. Even then its the third-party aurhor's job to use this directive in the first place.

Third party components can and already do document some refs explicitly for the parent to use. All your proposal adds is a "default" - a default which would have to be implemented in a way that doesn't break existing code/ 3rd party APIs.

[lyle45]

@LinusBorg Heres another example of where it's needed and there are definitely many more. This should be solved somehow

<q-input ref="myInput" v-model="value" dir="auto" />

...

setup() {
  ...
  watch(value, () => {
    isRTL.value = window.getComputedStyle(myInput.value.$el, null).direction === 'rtl';
  })
  ...
}

in following situation, if q-input uses fragments, this assertion would silently fail

[LinusBorg]

What, exactly, woudl you want a solution to provide? An array of all the root elements of the fragment?

[lyle45]

@LinusBorg Do you not think this has merit?

Third party components can and already do document some refs explicitly for the parent to use. All your proposal adds is a "default" - a default which would have to be implemented in a way that doesn't break existing code/ 3rd party APIs.

You are saying this like "just" giving a default has no contributed value while same can be said about $el in comparison to refs entirely. what is it if not a default ref for root? defaults have allot of value for uniformity

I agree with you that this would still need library owners to explicitly use the following directive but i can't seem to think of a better solution. if you have an idea on how to solve this problem then have at it...

array of root elements would definitely be better then the text node representing a place in the DOM (while giving close to no other value) but i dislike thinking that $el would return single html element for some components while returning array for others. this would break existing functionalities... the problem with text node is that with fragments it will silently pretend to be the dom element you want so there needs to be a way to differentiate it from actual dom elements

[LinusBorg]

You are saying this like "just" giving a default has no contributed value while same can be said about $el in comparison to refs entirely. what is it if not a default ref for root? defaults have allot of value for uniformity

It has value, it's just not that big in my view. $el, as you say yourself, is "the root element". you always know what you get, and it's set for you.

Something like v-container has to be set manually, and then still has to be documented to tell you as the consuming developer what element it is you're getting - one of the root elements? a nested <input>? The <h1>? It all depends on where the author has decided to put it, and the use case they had in mind for it.

So in that view, reading the following in docs, it doesn't seem to me that the former is necessarily more useful than the latter:

$container - the actual input field used by <lb-input> internally

vs.

$refs.$input - the actual input field used by <lb-input> internally

One could even argue that the later is preferable as the ref's name tells you what you get, vs. the more generic $container would have you look up in the docs what it's supposed to point to after comoing back to older code.

---

Now, about a more general ref that returns an array of all the fragment's root elements, I can see a certain value in that. However I'm personally not seeing a lot of situations where it would be really beneficial and at this point, we are hesitant to increase API surface for Vue unless it brings a really palpable benefit for many/most users. That's why I'm not immediately on board with this, is all.

[lyle45]

@LinusBorg Loud and clear. Thank you for listening to all of this :)