ui.element.id is only reflected for some elements in HTML - what's the reason / concept?

[Alyxion]

Question

Recently I was trying to localize an ui.input on the screen using

ui.run_javascript(f'getElement({element.id}).getBoundingClientRect();')

to attach a custom (hovering) suggestion view to it.

The execution always failed because getElement fails as the element.id is represented in the DOM of some html elements like in case of a ui.label like in your documentation example or ui.column <div id="c4" class="nicegui-column">... (in this case for element.id with a value of 4) where as for elements like ui.input the id field is missing so getElement will fail because the id attribute is missing.

I assume this is intended but is there a reliable concept behind it? What kind of elements really also have theirs ID assigned as attribute in the DOM and which ones not?

I now ended up wrapping my input field in a container, but (I assume so) had there been another solution to localize my input field without doing so?

Thanks in advance,
Michael

[falkoschindler]

Hi @Alyxion,

Vue translates a Quasar components like QBtn into an HTML element <button> which receives all props like the id attribute. But, for reasons I don't fully understand, other components like QInput are translated into <label> without any user-defined props. The <input> element itself is nested somewhere within <label>, receives props, but the id attribute is randomly generated to match the for attribute of the <label> element.

See #3842 (comment) for reference:

Even worse, there is no guarantee that there will be an element in the DOM with the corresponding ID. Take ui.input for example: It gets translated into a <label> tag with several nested elements, none of which has an ID.

Without an ID defined by NiceGUI, getElement won't find the element. I'm not sure what to do about it. Maybe NiceGUI needs to move away from using id and use something like data-id or data-nicegui-id instead. But this would probably count as breaking change.

[Alyxion]

Thank you @falkoschindler for the fast response and sorry for rising this question a second time, searched for it in the Q&A actually but did not stumble over #3842.

A long term solution would really be great, if not guaranteeing an ID for every object may be some standardized way to access the JavaScript object. I am pretty sure I won't be the last one who saw your tutorial at https://nicegui.io/documentation/run_javascript and tried to apply it to other components. So may be a remark next to that tutorial that this can not be applied to all components would also help. Quote from the NiceGUI docu: "To access a client-side object by ID, use the JavaScript function getElement()." ;-).

[falkoschindler]

I noticed that adding :for="id" to <q-input> in input.js causes the <input> HTML element to get the correct NiceGUI ID.

But it doesn't change the result of getElement, because this uses mounted_app.$refs to find the corresponding Vue component. So my statement about the relation between getElement and the id attribute was false. The function works independently.

Still, getElement is a bit unpredictable. It returns a ProxyObject for elements like ui.input (with the HTML element nested in an $el attribute), and a plain HTML element for elements like ui.label. Maybe another function getHtmlElement would be a useful extension, which always returns the HTML element.

[falkoschindler]

I created PR #4123 to add getHtmlElement.