Warning on classes being "lost" / overwritten

[ed2050]

Here's some surprising behavior that just bit me. Sharing it for others.

In some cases, classes added to the DOM outside nicegui get lost. You add a class, verify it's there, then a short time later it's suddenly gone from the element. So far I've seen it with ui.image (QImage) elements. May affect others as well.

I can't say that it's a bug per se. It may be intended behavior (if so, it's rude). Either way, it was greatly unexpected and a violation of normal DOM principles. The fault may lie with QImage (quasar) rather than nicegui, not sure.

Background

I use javascript and brython to add client-side functionality to my nicegui apps. Things that don't make sense or aren't possible server side. Things like hotkeys to scroll the page, rearrange elements, zoom in / zoom out. These things don't affect page data, so nicegui doesn't need to know about them.

Recently I added an image magnification popup to certain images. At first, no problem. Works perfectly on images created in nicegui with ui.element ('img').props ('src={ imgurl }'). This creates a regular <img> tag in the DOM. My javascript adds all the plumbing for the magnification box and marks the image by adding class zoom. All is well.

Problem

The problem arose when I tried to zoom images created in nicegui with ui.image (imgfile). This creates a quasar image, which renders to a div wrapper around the image (plus a bit more stuff):

<div class="q-img">
    <img class="q-img__image">
</div>

Sometimes you have to be aware of this behavior. For instance, doing ui.image (imgfile).classes ("foo") in nicegui puts the foo class on the div not the img tag. Which matters when writing styles.

Annoying, but ok, I can deal with it. Quasar can make whatever structure it wants. My script will process the <img> tag, create the magnify box, and mark the image by adding zoom to the class attribute.

Processing works fine. My client-side javascript finds quasar images and adds zoom to the <img> tag classes (I verified this works correctly). Then nothing happens. No zoom on mouse hover. It turns out the zoom class was later deleted from all quasar images. Here's the sequence:

During Processing : <img class="q-img__image q-img__image--with-transition q-img__image--waiting zoom">
A short time later : <img class="q-img__image q-img__image--with-transition q-img__image--loaded">

Note two differences in the second class list:

• my zoom class is gone
• q-img__image--waiting has been replaced by q-img__image--loaded

Analysis

You might say: Ed, you idiot. Of course you can't use client-side javascript with nicegui. Nicegui manages the page server side. This is all your fault.

To which I say: Poppycock. This is exactly how web technologies are designed to work. The DOM is a standardized model for interacting with the page. Any web developer worth their salt knows that web pages run multiple scripts from different sources. Every script has to play nice with others.

That means you control and modify your own data, but you don't mess with others. Add and remove your own classes from the DOM. Don't obliterate classes from other sources. That's rude and careless behavior. Like stopping your car in the middle of traffic. You just don't do it without an emergency.

Takeaways

Quasar can create and manage elements however it wants. Quasar can change q-img__image--waiting to q-img__image--loaded to keep track of image load status. That's fine. Just don't delete other classes. Other scripts on the page may have data there. To assume your framework is the only one on the page is stupid, thoughtless, and violates web standards.

Not to mention: nicegui works precisely because it combines web technologies. If nicegui only used fastapi, or only used quasar, or only used tailwind, or only used echarts, then it wouldn't be nearly as powerful. The power is in combining things in unexpected ways.

Something to watch out for. If you're a nicegui-only developer, you don't have to worry about it - yet. The day may come when you try to do something simple that nicegui doesn't support and have to resort to javascript. Until then, you can ignore this post.

My takeaway is that quasar elements are not to be trusted. I'll avoid using them in future. However it's a pain to go back now and rip them all out, so I'll manage as best I can (perhaps an attribute <img zoom="true"> will fare better). The annoyance factor is high, especially at time wasted figuring out misbehaving components.

[ed2050]

Addendum: don't use css zoom property. It's the only way in css to resize images relative to their natural height. But it completely destroys your page's bounding box coordinates, because chromium devs can't be bother to fix a simple bug in 10 years.

Zoom will mess up your page. Zoom will mess up your life. Just say no to zoom!

[falkoschindler]

Hi @ed2050,

To assume your framework is the only one on the page is stupid, thoughtless, and violates web standards.

Don't worry, we don't assume we're the only one on the page. But it's pretty hard to have Vue, Quasar, Tailwind and FastAPI play nicely with each other. NiceGUI is using FastAPI and Socket.IO to direct Vue to make Quasar and Tailwind create HTML and CSS for the browser. That's a rather long chain of commands. If you simply modify the generated HTML yourself (like you're the only one on the page), I'm not surprised that things don't go well. And I don't think this would be different in a plain Quasar app without NiceGUI. You can control the Quasar "layer", but Vue controls the generated HTML.

Regarding ui.image based on QImg: There is a Quasar prop called "img-class" for controlling the class list of the generated <img> element. But it's probably still difficult to change it via JavaScript without informing the server, since there is another copy of the class list which is applied when updating the element. So it might be better to emit an event to the server so it can update the class list in Python and update the client.

Anyway, we try to obey web standards where possible. But there are certain constraints when using Vue or even NiceGUI.

[ed2050]

we try to obey web standards where possible. But there are certain constraints when using Vue or even NiceGUI.

I completely understand. Integrating multiple web frameworks is tricky. You've done a great job. I don't fault nicegui's approach.

I agree that it's very easy to have conflict when server side and client side don't communicate. I expect and prepare for it. That's not the issue here. I doubt that Nicegui initiated changing q-img__image--waiting to q-img__image--loaded via FastAPI and socketio to Vue. That change seems like purely a Quasar operation. The issue is two client-side frameworks: Quasar and mine.

Some client-side conflicts are unavoidable. Like two frameworks using the same class name for different things. You accept that and mitigate where possible (don't use that class, or change the name in one framework, or ...).

When one framework (Quasar) assumes it's the only entity using the DOM, that's misbehaving. Competent Quasar devs should never allow it. It's the difference between node.classList.add ("foo") and node.setAttribute ("class", "only my classes matter foo").

Not much nicegui can do about it. Just wanted others to be aware. "Others" includes me in the future, when I forget this issue and run into it again. 😆