Лучший способ управлять и инициализировать объекты JS, которые представляют элементы DOM - PullRequest
Новая
       10

Лучший способ управлять и инициализировать объекты JS, которые представляют элементы DOM

1 голос
/ 13 октября 2010

При создании веб-страницы, содержимое которой будет динамически создаваться и уничтожаться пользователем, Каков наилучший способ структурировать и инициализировать как функциональность JavaScript, так и элементы DOM?

Пример. Допустим, у вас есть список задач, чьи предметы могут быть переупорядочены, созданы и уничтожены пользователем:

  • Каждый элемент будет иметь визуальное представление (т.е. элементы Dom), которое необходимо будет динамически создавать при добавлении пользователем элемента
  • Каждый элемент также будет иметь представление javascript (т. Е. Объекты javascript с пользовательскими методами и атрибутами), которые будут созданы при добавлении пользователем элемента

Как лучше всего создать исходные элементы DOM и их представление в javascript? Я вижу пару возможностей:

  • чтобы сервер выплевывал структурированный HTML, а JS чистил исходное состояние путем обхода DOM.
  • чтобы сервер выплюнул структурированный HTML и некоторый JS-код, чтобы создать набор объектов и связать их с их представлением DOM.
  • чтобы сервер выплевывал объекты JS и динамически создавал элементы DOM после загрузки страницы.

Ответы [ 2 ]

2 голосов
/ 13 октября 2010

Я не уверен в лучшем способе; это зависит от ваших требований.

Мой любимый подход - иметь шаблон JavaScript для каждой структуры данных; таким образом, если вы делаете вызовы AJAX, единственное, что вам нужно отправить по проводам, это сами данные, а не HTML.

Вы также можете использовать гибридный подход, при котором сервер выкладывает структурированный HTML-код для начальной загрузки страницы, читайте структуру (у вас должно быть достаточно семантического значения в вашем HTML-коде, чтобы знать, с чем вы имеете дело, даже если вы не используете этот подход), но по-прежнему используете шаблоны JavaScript для добавления данных в обновления. Очевидным недостатком этого подхода является то, что вы в конечном итоге дублируете свои шаблоны на стороне клиента и сервера; Тем не менее, существуют инструменты и структуры (например, шаблоны Google Closure), которые позволяют вам написать шаблоны один раз и сгенерируют для вас соответствующие версии сервера и клиента. у вас будет для отправки HTML-кода с сервера, если вы хотите, чтобы ваше приложение работало без JavaScript. Если вам требуется JavaScript, я не вижу причин, чтобы сервер выплевывал HTML, если вы не беспокоитесь о множественных HTTP-запросах.

Если вы хотите отправить структуру JavaScript и HTML для начальной загрузки страницы, это зависит от нескольких факторов: на какие ЦП вы ориентируетесь? (настольный, мобильный) Какой тип пропускной способности будут у ваших клиентов? (скорость ниже 3G?) Если у вас неограниченная пропускная способность, но ограниченный процессор, было бы более разумно отправлять как структуру, так и данные при загрузке первой страницы. Если у вас неограниченный центральный процессор, но ограниченная пропускная способность, вам нужно будет только отправить структуру или данные и сгенерировать другую из них и т. Д.

Вы также можете использовать что-то вроде виджетов GWT или jQuery, чтобы справиться с большинством этих проблем, но все они представляют собой одну и ту же идею: иметь только одну копию макета HTML на каждый виджет / структуру / что угодно, что вы - хочу позвонить, чтобы сами данные оставались скудными и с ними приятно работать.

Конечно, чем меньше HTTP-запросов вы можете получить, тем лучше, но это может привести к некоторой сложности и дублированию в вашем коде, если вы не используете фреймворк или инструментарий или не создаете свои собственные.

1 голос
/ 14 октября 2010

С точки зрения производительности, вам лучше всего использовать третий вариант - динамическое создание элементов DOM. Во-первых, потому что ответ сервера будет меньше и, следовательно, быстрее, и, во-вторых, производительность JavaScript будет выше при создании объектов.

Глядя на производительность, когда вам просто нужно вставить элементы на страницу, сравнивая это: 

element.appendChild(document.createElement("div"));

к этому: 

element.innerHTML = "<div></div>";

innerHTML быстрее. Однако, когда вам нужны ссылки на внедренные элементы, сравните это: 

var child = element.appendChild(document.createElement("div"));

к этому: 

element.innerHTML = "<div id=\"" + childId + "\"></div>";
var child = document.getElementById(childId);

createElement выигрывает конкурс производительности.

Поскольку вам нужны ссылки на элементы, вы получите более высокую производительность, извлекая JSON с сервера и создавая элементы.

При этом вы можете добиться максимальной производительности, создавая только те элементы, на которые вам нужны ссылки, и вставляя html в другое место. Например, для этого HTML: 

<div>
    <div class="a">Item A</div>
    <div class="b">Item B</div>
</div>

Если вам нужна только ссылка на родительский элемент <div>, а не на его дочерние элементы, то вместо динамического создания дочерних элементов создайте динамический родительский элемент <div>, а затем установите его innerHTML для содержимого: 

var item = serverObject[i];
var el = parent.appendChild(document.createElement("div"));
el.innerHTML = "<div class=\"" + 
    item.A.className + "\">" +
    item.A.text + "</div><div class=\"" +
    item.B.className + "\">" +
    item.B.text + "</div>";

Таким образом, вы получаете лучшее из обоих миров с точки зрения производительности.

Редактировать - Добавление информации за пределы производительности

С точки зрения архитектуры, мне не нравится, когда службы много знают о клиенте, только данные, которые он предоставляет. Таким образом, если вы решите изменить свой пользовательский интерфейс, вам не нужно связываться со службой, чтобы заставить ее выплевывать другой HTML. Кроме того, если вы обнаружите, что хотите использовать те же данные в другом месте, у вас уже есть служба, которую вы можете использовать повторно.

...