Есть ли в jQuery эквивалент конструктора Element () в MooTools?
Я собираюсь запустить механизм отчетности javascript для своего веб-сайта и начал создавать прототипы с помощью MooTools. Мне очень нравится делать такие вещи:
function showLeagues(leagues) {
var leagueList = $("leagues");
leagueList.empty();
for(var i = 0; i<leagues.length; ++i) {
var listItem = getLeagueListElement(leagues[i]);
leagueList.adopt(listItem);
}
}
function getLeagueListElement(league) {
var listItem = new Element('li');
var newElement = new Element('a', {
'html': league.name,
'href': '?league='+league.key,
'events': {
'click': function() { showLeague(league); return false; }
}
});
listItem.adopt(newElement);
return listItem;
}
Из того, что я видел, методы типа jQuery "принимают" принимают только строки html или элементы DOM. Есть ли какой-нибудь jQuery, эквивалентный Элемент MooTools?
EDIT: The big thing I'm looking for here is the programmatic attachment of my click event to the link.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 2
Вот то же самое в jQuery. В основном, чтобы создать новый элемент, вы просто вставляете нужный HTML-код.
function showLeagues(leagues) {
var $leagueList = $("#leagues");
$leagueList.empty();
$.each(leagues, function (index, league) {
$leagueList.append(getLeagueListElement(league));
});
}
function getLeagueListElement(league) {
return $('<li></li>')
.append($('<a></a>')
.html(league.name)
.attr('href', '?league=' + league.key)
.click(function() {
showLeague(league);
return false;
})
)
;
}
обратите внимание, код «<li />» не оптимален, и, глядя на код, видно, что jquery выполняет регулярное выражение, чтобы расширить его обратно до «<li> </li>»;)
синтаксически может быть лучше использовать jQuery для этого, но, вероятно, более эффективно использовать
document.createElement('li')
И устраняет необходимость как минимум в тесте сравнения строк и небольшом разборе токенов.
Flydom также может вызвать у вас интерес, если вы настаиваете на создании большого количества узлов dom. (Теоретически должно быть быстрее, но не тестировал)
Примечание. Внутри jQuery ("<html> </html>") выглядит так, как будто он действительно делает это (упрощенно):
jQuery(matcher) --> function(matcher)
{
return jQuery.fn.init(matcher) --> function(matcher)
{
return this.setArray(
jQuery.makeArray(
jQuery.clean(matcher) --> function(matcher)
{
div = document.createElement('div');
div.innerHTML = matcher;
return div.childNodes;
}
)
);
}
}
Таким образом, можно было бы предположить, что «document.createElement» является «требованием», и если вы знать вы хотите получить (то есть: не сравнивать некоторые сторонние данные с $( datahere )), тогда document.createElement будет таким же логичным и с повышением скорости, чтобы избежать многочисленные регулярные выражения и медленные манипуляции со строками.
Для сравнения: jQuery(document.createElement('div'))
похоже, что он эффективно делает это (упрощенно):
jQuery(matcher) --> function(matcher)
{
return jQuery.fn.init(matcher) --> function(matcher)
{
this[0] = matcher;
this.length = 1;
return this;
}
}
Есть ли какой-нибудь браузер, достаточно современный для поддержки основных js-библиотек, который не включает эти методы DOM? Мое желание использовать специфичный для фреймворка код было двояким: во-первых, чтобы сохранить согласованный синтаксис в моем коде, и во-вторых, чтобы убедиться, что мне не нужно заботиться о различиях в браузерах.
Ответ расширен. Насколько я могу судить, если браузер не поддерживает document.createElement, то даже jQuery не будет работать с ним.
Чтобы быть уверенным в своих намерениях, вы говорите, что вместо: $ ('<a> </a>') .attr ('href', '? League =' + league.key) ... вы бы порекомендовали : $ (document.createElement ("a")). attr ('href', '? league =' + league.key) ...?
Я хотел бы добавить - я видел несколько статей (и провел несколько собственных тестов), и выполнение $ (document.createElement ('a')) последовательно быстрее создает новые элементы для jQuery, а затем полагается на jQuery для сделай это за тебя. Обычный JS, вероятно, всегда будет быстрее, чем полагаться на библиотеку, которая сделает это за вас (включая настройку атрибутов элементов, но иногда мы говорим о миллисекундных различиях, поэтому это почти спорный вопрос, если только вы не стремитесь сжать как можно больше).
@keif да, скорее всего проблема будет, если он будет в цикле, и это немного похоже на преждевременную оптимизацию. Но использование явного JS кажется мне даже склонным к ошибке меньше. И это Javascript, до недавнего времени он все равно был очень медленным по умолчанию;) каждая микрооптимизация помогает.
Вместо $ ('<li> </li>') вы можете просто использовать $ ('<li />') btw