CODEWITHSUNDEEP
javascriptvaadinvaadin-flow
Dario Viva
Dario Viva

Reputation: 267

vaadin readding component creates new element in dom

In Vaadin when readding a component that was removed previously will create a new element in the DOM.

Lets look at it in detail

Button button = new Button("test");
button.getElement().executeJs("""
                this.addEventListener("click", event => {
                    alert("hello");
                });
                """);
add(button);

now after some event on the server we decide to remove the component from the view. So the corresponding element in the DOM gets removed.

then after another event we add the button component again. so vaadin creates a new Element on the client and adds this to the DOM. (the new element is missing the eventlistener)

What I would expect to happen is that vaadin reuses the same element that existed before. But it does not. normally this would not really matter, but in our case we added a eventlistener with js. (yes we could add eventlisteners on the javaside, but let’s suppose that we really need to do it in js because we want to execute some code on the client)

why is vaadin doing this, and is there an option so vaadin uses always the same element. In pure JS I could easily just create a lookup table with the element that I removed, and then later use the elements in the lookup table to add them again to the DOM. Doing this would keep all the event listeners for the element.

What really perplexes me, is that even though the element in the DOM is different everytime, the Element I get with component.getElement() is always the same. Isn’t this element supposed to represent the element on the clientside?

Of course we could just run the same js on the element everytime we add the element to the view, but that is quite cumbersome.

Is vaadin doing this because of performance reasons. What are your explanations for this behaviour?

Upvotes: 0

Views: 150

Answers (1)

Leif Åstrand
Leif Åstrand

Reputation: 8001

This is indeed a mechanism to avoid leaking memory. A mechanism based on server-side reference tracking would be significantly more complex, work with a delay (because the reference is cleared only when GC runs), and make it more difficult for the developer to control what happens. The current design makes it easy for the developer to choose what should happen: hide to preserve it in the browser, detach to let it be garbage collected.

I could also clarify that the same DOM element is reused in cases when the component is detached and then attached back again during the same server visit.

Upvotes: 3

Related Questions