Develop Reference

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?

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.

Is it possible that a tag exists in the dom but not on the page?

I came across a situation where I found an "anchor" tag in the DOM using xpath but the corresponding element was nowhere to be found on the page and while testing the particular tag, the click() operation worked. Is that even possible?

Check out for the CSS property, specifically
display : none

There are many possible options.
Like in the previous answer, it could have display : none. If this is not the case for your specific element, it would likely inherit this from a parent node. It's CSS class could contain this, multiple CSS classes may be involved, just to name a few that came to mind.
And now about the click() method actually working...this is because Selenium WebDriver doesn't use the regular mouse cursor (the one you're seeing on screen) to do the actual clicking or hovering on element, but everything is done internally.

oop in javascript binding dom elements to objects

Hi I really could do with a point in the right direction with this question.
I'm trying to fathom object orientated javascript, but am having trouble getting my head around binding dom elements to objects.
I would like to make a little animated widget type thing for my web page. the widget will be just simple drop down tabs , (like tabs from an actual folder) I want the tab to drop down a bit with a mouseover event then raise up with mouseout.
here is my current implementation, it doesnt work well at the moment it's just a mock up
http://bombinglish.com/
I want to make a class for the tabs , which will include the open and close animation methods, methos to add events, and other necessary fields. then instanciate a new object for each tab. but how do I do I tell each object that it must must respond to the corresponding mouse events, or to put it another way how do I bind the DOM element to the object?

If you are using Javascript just for presentation logic, then I don't think it's worth anything to try and get wild with OO.
If you have that at the top of every page, you could simply label the tabs with a unique class name. Then in your Javascript file you bind a mouseover event on every DOM element with that class name.
Perhaps, others have differing opinions on this however.

Javascript - best way to handle post-load generated content

I've been wondering how to efficiently and generically process content that is generated after any user action.
For instance, let's say my script processes all paragraphs of Facebook at page load in order to make them blink. What would be the most responsive way to make the text that is displayed later (because of infinite scroll e.g.) blink ?
Thanks in advance for your ideas,
Rolf

Personally, I define a function called dom_mods() that modifies the page in order to apply any special effects such as autocompletion, default value for <select>, auto-resizing textareas and so on. Whenever I add content to the document, I call dom_mods().
The only catch is to make sure you don't affect the same elements twice, or if you do it needs to not make a difference. For instance, there might be a class that defines a set of elements to affect, so the class should be removed by dom_mods() so it doesn't get the treatement twice.

You would add the blink function to the parent object that would encompass all the children.
In other words if you use jquery you would specify the event selector as (".parent .child") when registering the child blink event. This way, you don't need to register any additional jquery "dom_mods" function or call anything else which wastes memory and time.

Is it more efficient to keep DOM elements on the page or to re-render them as needed?

I have a dialog box that has settings associated with it. When the user clicks the "settings" button, a form is displayed so they can modify them.
What is more efficient:
to have the settings div exist hidden on the page and display when needed
OR
to create the settings div and populate it with data when needed?
In the first scenario you don't need to create the DOM elements and populate them every time, but if there are many dialog boxes open at once (a common situation) then the amount of elements on the page is pretty large and many of them are not going to be used often. But in the second situation, elements are created and appended to the DOM which gets expensive.

I'd suggest you to "cache" your html on the page, but enforce browser to do not render it until necessary (until user request the data, or simply scroll to it). The main idea is to add your html (with data) to the page, but comment it out. For example,
<div id="cached-html">
<!--
<div>
...some custom html here
</div>
-->
</div>
Then once user requested the html, you can do the following:
var html = document.getElementById('cached-html'),
inner = html.innerHTML;
html.innerHTML = inner.substring(4, inner.length - 4);
Pros. is that you don't bother your browser with initial rendering (later you can simply user display:none to hide it again), so your page renders faster.
And another note - if your data (and as a consequence inner html) changes frequently, then it will be better to re-render it each time user request it, but if it is almost static, then hide/show should be more effective.

There can be problems either way, it depends on your page. If you already have a lot of elements on the page, it may be better load add them when you need them. If your page is already very "scripty" you may want to load the elements and show them when needed.
The real question is what would be better for your page, more script, or more dom elements.

When you have to display same setting div at multiple places.
Keeping that hidden is a better solution.
Remember that creating a new dom element or cloning a existing dom element gives almost same performance, but for code clarity/maintainence cloning or template is better.
Implementation using template: Make a template of div setting and keep that hidden:
<div class="template_setting">
Your settings(children of template_setting)
</div>
Javascript/Jquery code:
-Whenever someone opens a dialogue box, make a clone of childrens of template_setting and append to div_dialogue.
-As you may have multiple templates on the same page( which is not always true).
Apply a custom event on the id of newly created setting div.( keep id of each setting div different, you can increment each one by some character/number).
$('#dialogue_opener').click(function(event){
$('.template_setting').children().clone().appendTo(div_dialogue)
.trigger('adjustSettingID');

Consider a hybrid solution. Load the "settings" div after the page is ready. This way, the user won't feel the extra "expense", and you'll have the div ready for when you need it.

I've typically seen that rendering from JavaScript is pretty darn fast. I've built lots of "just in time" menus, grids, and forms and the users can't tell the difference. The nice thing about it is that you don't have to keep a form current, just blow it away and default everything to the data in you settings object. Makes for cleaner code in my opinion.