Coming to jQuery from a functional background, I am fond (perhaps unreasonably so) of elegant chains of functions. I often find myself dealing with arrays of elements, such as those that may result from $.map, and my ability to manipulate these arrays in the DOM seems quite limited. Here's some sample code that runs through the results of a Google search, rendering the result titles:
var newResultsDiv = $('<div id="results" />');
$.each(searcher.results, function() {
newResultsDiv.append('<p>' + this.title);
});
$("#searchresults").append(newResultsDiv);
I find this excessively verbose. Ideally, I would do something along these lines instead:
$.map(searcher.results, function(elem) {
return $('<p>' + elem.title);
}).wrapAll('<div id="results" />').appendTo('#searchresults');
I've tried this out, along with several variants using different forms of append and wrap. They all appear to be incapable of handling the plain-old-Javascript array that jQuery.map spits out. They're designed to work with jQuery's own set collection. At least, that's my guess, as messing around with these functions in the Firebug console seems to confirm the problem.
I am hoping that someone here has the wisdom to show me an elegant way to do what I'm trying to do. Is there one?
Using the $.map method you presented, you could return the actual DOM element instead of a jQuery object. This is done by grabbing the [0] index item in the jQuery object. Then wrap the entire $.map with $().
This works because jQuery will accept an array of DOM elements.
Your <p> creation was a little off. I changed it to pass an object literal to set the text. Otherwise, you would need to concatenate the ending tag as well.
Finally, you would need to traverse up to the wrapper #results you created using .parent().
$($.map(searcher.results, function(elem) {
return $('<p>',{text:elem.title})[0];
})).wrapAll('<div id="results" />').parent().appendTo('#searchresults');
EDIT: IF you don't mind the look of it, you could do this as well:
$('<div id="results" />').append(
$.map(searcher.results, function(elem) {
return $('<p>',{text:elem.title})[0];
})).appendTo('#searchresults');
Hm...not sure if this will work, but give it a try:
$("<div id='results'>" + $.map(searcher.results, function(elem) {
return '<p>' + elem.title + '</p>';
}).join("") + "</div>").appendTo('#searchresults');
OK, just tested it here:
http://jsfiddle.net/xxxST/1/
And it seems to work. I should mention, however, that while this is perhaps not very "verbose" in terms of number of lines, it's a bit opaque with regard to its clarity. It's a jQuery function result, joined together to a string, inside a jQuery wrapper with an appendTo function running on it. I think it would be much more readable if you were to do something like this:
var resultString = $.map(searcher.results, function(elem) {
return '<p>' + elem.title + '</p>';
}).join("");
$('#searchresults').append("<div id='results'>" + resultString + "</div>");
But that's just my opinion.
Related
In practice, what are the advantages of using createElement over innerHTML? I am asking because I'm convinced that using innerHTML is more efficient in terms of performance and code readability/maintainability but my teammates have settled on using createElement as the coding approach. I just wanna understand how createElement can be more efficient.
There are several advantages to using createElement instead of modifying innerHTML (as opposed to just throwing away what's already there and replacing it) besides safety, like Pekka already mentioned:
Preserves existing references to DOM elements when appending elements
When you append to (or otherwise modify) innerHTML, all the DOM nodes inside that element have to be re-parsed and recreated. If you saved any references to nodes, they will be essentially useless, because they aren't the ones that show up anymore.
Preserves event handlers attached to any DOM elements
This is really just a special case (although common) of the last one. Setting innerHTML will not automatically reattach event handlers to the new elements it creates, so you would have to keep track of them yourself and add them manually. Event delegation can eliminate this problem in some cases.
Could be simpler/faster in some cases
If you are doing lots of additions, you definitely don't want to keep resetting innerHTML because, although faster for simple changes, repeatedly re-parsing and creating elements would be slower. The way to get around that is to build up the HTML in a string and set innerHTML once when you are done. Depending on the situation, the string manipulation could be slower than just creating elements and appending them.
Additionally, the string manipulation code may be more complicated (especially if you want it to be safe).
Here's a function I use sometimes that make it more convenient to use createElement.
function isArray(a) {
return Object.prototype.toString.call(a) === "[object Array]";
}
function make(desc) {
if (!isArray(desc)) {
return make.call(this, Array.prototype.slice.call(arguments));
}
var name = desc[0];
var attributes = desc[1];
var el = document.createElement(name);
var start = 1;
if (typeof attributes === "object" && attributes !== null && !isArray(attributes)) {
for (var attr in attributes) {
el[attr] = attributes[attr];
}
start = 2;
}
for (var i = start; i < desc.length; i++) {
if (isArray(desc[i])) {
el.appendChild(make(desc[i]));
}
else {
el.appendChild(document.createTextNode(desc[i]));
}
}
return el;
}
If you call it like this:
make(["p", "Here is a ", ["a", { href:"http://www.google.com/" }, "link"], "."]);
you get the equivalent of this HTML:
<p>Here is a link.</p>
User bobince puts a number of cons very, very well in his critique of jQuery.
... Plus, you can make a div by saying $(''+message+'') instead of having to muck around with document.createElement('div') and text nodes. Hooray! Only... hang on. You've not escaped that HTML, and have probably just created a cross-site-scripting security hole, only on the client side this time. And after you'd spent so long cleaning up your PHP to use htmlspecialchars on the server-side, too. What a shame. Ah well, no-one really cares about correctness or security, do they?
jQuery's not wholly to blame for this. After all, the innerHTML property has been about for years, and already proved more popular than DOM. But the library certainly does encourage that style of coding.
As for performance: InnerHTML is most definitely going to be slower, because it needs to be parsed and internally converted into DOM elements (maybe using the createElement method).
InnerHTML is faster in all browsers according to the quirksmode benchmark provided by #Pointy.
As for readability and ease of use, you will find me choosing innerHTML over createElement any day of the week in most projects. But as you can see, there are many points speaking for createElement.
While innerHTML may be faster, I don't agree that it is better in terms of readability or maintenance. It may be shorter to put everything in one string, but shorter code is not always necessarily more maintainable.
String concatenation just does not scale when dynamic DOM elements need to be created as the plus' and quote openings and closings becomes difficult to track. Consider these examples:
The resulting element is a div with two inner spans whose content is dynamic. One of the class names (warrior) inside the first span is also dynamic.
<div>
<span class="person warrior">John Doe</span>
<span class="time">30th May, 2010</span>
</div>
Assume the following variables are already defined:
var personClass = 'warrior';
var personName = 'John Doe';
var date = '30th May, 2010';
Using just innerHTML and mashing everything into a single string, we get:
someElement.innerHTML = "<div><span class='person " + personClass + "'>" + personName + "</span><span class='time'>" + date + "</span></div>";
The above mess can be cleaned up with using string replacements to avoid opening and closing strings every time. Even for simple text replacements, I prefer using replace instead of string concatenation.
This is a simple function that takes an object of keys and replacement values and replaces them in the string. It assumes the keys are prefixed with $ to denote they are a special value. It does not do any escaping or handle edge cases where $ appears in the replacement value etc.
function replaceAll(string, map) {
for(key in map) {
string = string.replace("$" + key, map[key]);
}
return string;
}
var string = '<div><span class="person $type">$name</span><span class="time">$date</span></div>';
var html = replaceAll(string, {
type: personClass,
name: personName,
date: date
});
someElement.innerHTML = html;
This can be improved by separating the attributes, text, etc. while constructing the object to get more programmatic control over the element construction. For example, with MooTools we can pass object properties as a map. This is certainly more maintainable, and I would argue more readable as well. jQuery 1.4 uses a similar syntax to pass a map for initializing DOM objects.
var div = new Element('div');
var person = new Element('span', {
'class': 'person ' + personClass,
'text': personName
});
var when = new Element('span', {
'class': 'time',
'text': date
});
div.adopt([person, when]);
I wouldn't call the pure DOM approach below to be any more readable than the ones above, but it's certainly more maintainable because we don't have to keep track of opening/closing quotes and numerous plus signs.
var div = document.createElement('div');
var person = document.createElement('span');
person.className = 'person ' + personClass;
person.appendChild(document.createTextNode(personName));
var when = document.createElement('span');
when.className = 'date';
when.appendChild(document.createTextNode(date));
div.appendChild(person);
div.appendChild(when);
The most readable version would most likely result from using some sort of JavaScript templating.
<div id="personTemplate">
<span class="person <%= type %>"><%= name %></span>
<span class="time"><%= date %></span>
</div>
var div = $("#personTemplate").create({
name: personName,
type: personClass,
date: date
});
You should use createElement if you want to keep references in your code. InnerHTML can sometimes create a bug that is hard to spot.
HTML code:
<p id="parent">sample <span id='test'>text</span> about anything</p>
JS code:
var test = document.getElementById("test");
test.style.color = "red"; //1 - it works
document.getElementById("parent").innerHTML += "whatever";
test.style.color = "green"; //2 - oooops
1) you can change the color
2) you can't change color or whatever else anymore, because in the line above you added something to innerHTML and everything is re-created and you have access to something that doesn't exist anymore. In order to change it you have to again getElementById.
You need to remember that it also affects any events. You need to re-apply events.
InnerHTML is great, because it is faster and most time easier to read but you have to be careful and use it with caution. If you know what you are doing you will be OK.
Template literals (Template strings) is another option.
const container = document.getElementById("container");
const item_value = "some Value";
const item = `<div>${item_value}</div>`
container.innerHTML = item;
I know that the empty method removes all children in the DOM element.
In this example however, why does removing the empty method result in duplicate entries:
and putting it in results in a normal page:
var renderNotesList = function()
{
var dummyNotesCount = 10, note, i;
var view = $(notesListSelector);
view.empty();
var ul = $("<ul id =\"notes-list\" data-role=\"listview\"></ul>").appendTo(view);
for (i=0; i<dummyNotesCount; i++)
{
$("<li>"+ "" + "<div>Note title " + i + "</div>" + "<div class=\"list-item-narrative\">Note Narrative " + i + "</div>" + "" + "</li>").appendTo(ul);
}
ul.listview();
};
I don't know why empty() doesn't work but I found this
... so until this is sorted everyone should just use:
el.children().remove(); instead of el.empty();
( jQuery.empty() does not destroy UI widgets, whereas jQuery.remove() does (using UI 1.8.4) )
Without seeing how your JavaScript is being used in your page, I suspect that you must be calling the renderNotesList() function twice and thus generating to unordered lists.
When you use the .empty() method, you are removing the first ul list, so you only see one instance. Without the call to .empty(), you retain both.
However, I can't say where or how this is happening in you web page without seeing more, but at least you now have some idea of what to look for.
Demo Fiddle
I built a demo using your JavaScript, but I was sort of guessing as to how you are using it.
Fiddle: http://jsfiddle.net/audetwebdesign/UVymE/
Footnote
It occurred to me that the function ul.listview() may actually be appending a second copy of the ul to the DOM. You need to check the code or post it for further review.
I am using Javascript(with Mootools) to dynamically build a large page using HTML "template" elements, copying the same template many times to populate the page. Within each template I use string keywords that need to be replaced to create the unique IDs. I'm having serious performance issues however in that it takes multiple seconds to perform all these replacements, especially in IE. The code looks like this:
var fieldTemplate = $$('.fieldTemplate')[0];
var fieldTr = fieldTemplate.clone(true, true);
fieldTr.removeClass('fieldTemplate');
replaceIdsHelper(fieldTr, ':FIELD_NODE_ID:', fieldNodeId);
parentTable.grab(fieldTr);
replaceIdsHelper() is the problem method according to IE9's profiler. I've tried two implementations of this method:
// Retrieve the entire HTML body of the element, replace the string and set the HTML back.
var html = rootElem.get('html').replace(new RegExp(replaceStr, 'g'), id);
rootElem.set('html', html);
and
// Load the child elements and replace just their IDs selectively
rootElem.getElements('*').each(function(elem) {
var elemId = elem.get('id');
if (elemId != null) elemId = elemId.replace(replaceStr, id);
elem.set('id', elemId)
});
However, both of these approaches are extremely slow given how many times this method gets called(about 200...). Everything else runs fine, it's only replacing these IDs which seems to be a major performance bottleneck. Does anyone know if there's a way to do this efficiently, or a reason it might be running so slow? The elements start hidden and aren't grabbed by the DOM until after they're created so there's no redrawing happening.
By the way, the reason I'm building the page this way is to keep the code clean, since we need to be able to create new elements dynamically after loading as well. Doing this from the server side would make things much more complicated.
I'm not 100% sure, but it sounds to me that the problem is with the indexing of the dom tree.
First of all, do you must use ids or can you manage with classes? since you say that the replacement of the id is the main issue.
Also, why do you clone part of the dom tree instead of just inserting a new html?
You can use the substitute method of String (when using MooTools), like so:
var template = '<div id="{ID}" class="{CLASSES}">{CONTENT}</div>';
template.substitute({ID: "id1", CLASSES: "c1 c2", CONTENT: "this is the content" });
you can read more about it here http://mootools.net/docs/core/Types/String#String:substitute
Then, just take that string and put it as html inside a container, let's say:
$("container_id").set("html", template);
I think that it might improve the efficiency since it does not clone and then index it again, but I can't be sure. give it a go and see what happens.
there are some things you can do to optimise it - and what #nizan tomer said is very good, the pseudo templating is a good pattern.
First of all.
var fieldTemplate = $$('.fieldTemplate')[0];
var fieldTr = fieldTemplate.clone(true, true);
you should do this as:
var templateHTML = somenode.getElement(".fieldTemplate").get("html"); // no need to clone it.
the template itself should/can be like suggested, eg:
<td id="{id}">{something}</td>
only read it once, no need to clone it for every item - instead, use the new Element constructor and just set the innerHTML - notice it lacks the <tr> </tr>.
if you have an object with data, eg:
var rows = [{
id: "row1",
something: "hello"
}, {
id: "row2",
something: "there"
}];
Array.each(function(obj, index) {
var newel = new Element("tr", {
html: templateHTML.substitute(obj)
});
// defer the inject so it's non-blocking of the UI thread:
newel.inject.delay(10, newel, parentTable);
// if you need to know when done, use a counter + index
// in a function and fire a ready.
});
alternatively, use document fragments:
Element.implement({
docFragment: function(){
return document.createDocumentFragment();
}
});
(function() {
var fragment = Element.docFragment();
Array.each(function(obj) {
fragment.appendChild(new Element("tr", {
html: templateHTML.substitute(obj)
}));
});
// inject all in one go, single dom access
parentTable.appendChild(fragment);
})();
I did a jsperf test on both of these methods:
http://jsperf.com/inject-vs-fragment-in-mootools
surprising win by chrome by a HUGE margin vs firefox and ie9. also surprising, in firefox individual injects are faster than fragments. perhaps the bottleneck is that it's TRs in a table, which has always been dodgy.
For templating: you can also look at using something like mustache or underscore.js templates.
I have a var saved in my JS custom object (code below is from inside the class):
var toolbar;
this.create_toolbar = function() {
self.toolbar = document.createElement('div');
$(self.toolbar)
.html('<ul>' +
'<li id="insert_bold"></li>' +
'<li id="insert_em"></li>' +
'<li id="insert_hyperlink"></li>' +
'<li id="insert_code"></li>' +
'<li id="insert_image"></li>' +
'</ul>')
.insertBefore(self.editTextarea); // just a textarea on the page
}
The toolbar gets created and placed successfully, and self.toolbar now holds the object for the new div. However, when trying to bind the <li>'s to clicks I can't seem to get anything to happen:
$(self.toolbar).children("li#insert_bold").click(function() {
alert("just checking");
});
To be clear, after the above, nothing is happening when I click <li id="insert_bold">
Is there something that I am missing? I am fairly new to jQuery....am I allow to put a variable that holds an [object object] in the $()? If not, how should I do this?
You need to use .find() here, like this:
$(self.toolbar).find("li#insert_bold").click(function() {
alert("just checking");
});
.children() only looks at immediate children, <li> is beneath the <ul> though, so it's not an immediate child.
Be aware though if you intend on having multiple instances of this on a page (I'm guessing this is likely the case), you should use classes instead (IDs need to be unique), then use a class selector, for example: $(self.toolbar).find("li.insert_bold").
While Nick has solved your question, I don't think this is a good idea, especially if you have a large number of HTML elements binding.
When I have a rather small number, I do gather the items in an object inside the main constructor function
this.el = {
$button : $('.button','#div'),
$submit : $('.submit','#div')
};
Then when I need an element, I just call it with (this), assuming you are using prototype functions.
this.el.$button.click(function () {
});
If you many elements to deal with, 20 or more, I'll recommend that you opt for a JavaScript FrameWork. Backbone Js is a good one.
I have some jquery that works fine, but I'd like to highly optimize it. Basically I'm
doing standard appending list items to unordered lists. Can anyone recommend the fastest
way to optimise the following code e.g. createDocumentFragment ?
for (key in data) {
li = $('<li><span class="item">' + data[key]["Name"] + '</span><img src=' + options.deleteIcon + ' alt="remove" class="delete"/></li>');
$('.item', li).data('ID', data[key]["Id"]);
$(list).append(li);
}
var sb = new Array();
for (key in data) {
sb.push('<li><span class="item" id="', data[key]['Id'], '">', data[key]["Name"], '</span><img src=', options.deleteIcon, ' alt="remove" class="delete"/></li>')}
$(list).append(sb.join(""));
I would suggest reducing the number of writes to the DOM to just one. By that, I mean storing the list into a temporary variable and then appending the entire list in a single operation. Also, instead of using .attr to set the ID of each element, you can use concatenation as you have used it to set the text of each LI.
var tmpList = '';
for (key in data) {
li = '<li><span class="item" id="' + data[key]['Id'] + '">' + data[key]["Name"] + '</span><img src=' + options.deleteIcon + ' alt="remove" class="delete"/></li>';
tmpList += li;
}
// if you are appending to an existing list, use append
// if you have just built one up from scratch, just use `.html`
$(list).append(tmpList);
I would recommend reading this:
Optimizing JavaScript For Execution Speed
From the article:
Unlike other programming languages,
JavaScript manipulates web pages
through a relatively sluggish API, the
DOM. Interacting with the DOM is
almost always more expensive than
straight computations. After choosing
the right algorithm and data structure
and refactoring, your next
consideration should be minimizing DOM
interaction and I/O operations.
For a start, you could make one large chunk of li elements and then append them in a single operation instead of appending them one at time.
Thanks everyone, the one point everyone seems to miss is that I'm associating the Id with the DOM element ... using the jquery.data method. This isn't to be confused the the ID attribute for the span element. Because of this I'm not sure how the concatenation would work as I understand that I need to have a reference to the DOM element to set the data on it. Is this correct?