Я знаю, что плохо хранить данные в DOM, но почему?

Question

Я снова и снова слышал, что «использовать DOM в качестве базы данных - это плохая практика».

Хотя я в основном согласен с этим мнением, этот вопрос больше касается менее черно-белыхслучаев.Учитывая последние изменения в методах jQuery .data() и спецификации атрибутов данных HTML5, неужели так плохо вставлять некоторые данные в DOM для удобства?

Например, я недавно реализовалфункция «живого» вычисления для таблицы, полной входных данных, которая выполняет что-то вроде этого:

<table>
  <tr>
    <td><input type="text"></td>
  </tr>
  <tr>
    <td><input type="text"></td>
  </tr>
</table>

jQuery:

$('table').bind('calculate',function(){
  var total = 0;
  $(this).find('tr').each(function(){
    total += $(this).data('value');
  });
  // display total
});

$('table input').bind('change keyup',function(){
  $(this).closest('tr').data('value',$(this).val());
  $(this).closest('table').trigger('calculate');
});

Это упрощенный пример, потому что я может пропустить вызовы к .data() и перейти прямо к входным значениям, но давайте представим немного более сложный сценарий, в котором элементы, кроме входных, влияют на значения строк.

Это неправильноиспользовать DOM для хранения простых данных в такой ситуации?

Answer 1

Хорошо хранить данные в объектах DOM.А поскольку ваш вопрос относится к API данных jQuery, важно понять, как работает API data.Я написал ответ , объясняющий его внутреннюю работу некоторое время назад.API данных хранит только ссылку на объекты DOM вместе с данными и ничего не хранит внутри самих объектов DOM.Все данные хранятся в старых старых JavaScript-объектах.

Вопрос о том, хороший это или плохой, зависит от личного вкуса.Джон Резиг, создатель jQuery, выступил с докладом на Tech4Africa в 2010 году, где рассказывает об этой конкретной проблеме и предлагает покончить с отдельной областью хранения и связать все с DOM с помощью API данных.Вы можете посмотреть выступление на YouTube (спасибо @ tine2k за предоставленную ссылку).Если вы послушаете весь доклад, вы найдете несколько хороших примеров того, почему этот подход имеет смысл и делает вещи простыми.

Я полагаю, что аналогичные аргументы могут быть сделаны для другого конца спектра - чтобы вашданные в аккуратно спрятанных объектах и ​​ классах , и должны быть отделены от самого представления.Такое мышление исходит от традиционных архитектур, таких как MVC.

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

Answer 2

Есть несколько фундаментальных аргументов против использования DOM для хранения данных:

1. Предполагается, что DOM - это представление данных. Свойства элементов DOM должны быть метаданными для самих элементов, а не данными из модели.

2. Не следует добавлять случайные свойства к хост-объектам, так как вы не представляете, что они могут с ними делать.

3. У вас та же проблема, что и с глобальными переменными - если это станет обычной практикой, вам придется принять схему, чтобы избежать конфликтов имен.

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

Если у вас есть только небольшие объемы данных и вы имеете полный контроль над своими страницами, тогда идите вперед и поместите данные в атрибуты и свойства данных. Но не храните большие куски или сложные структуры.

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

Answer 3

Не думаю, что есть что-то неправильно с хранением данных в DOM, но я думаю, что проблема заключается в хранении много данных в DOM.Браузер должен перепутать DOM для вывода страниц, которые мы видим, и чем больше данных в нем, тем больше дерьма ему приходится разбирать.

Я уверен, что есть и другие причиныэто мой вывод.

Answer 4

Разработав несколько одностраничных приложений для устройств CE, которые имеют ограниченную мощность браузера, я принял несколько дополнительных личных стандартов по этим вопросам. Главное, что только потому, что JQuery поддерживает сканирование через DOM, это не означает, что это эффективный подход. Если мне нужно знать, на какой фокусе находится LI, я мог бы использовать .index () или .find () или даже .each (), но сохранение этого значения в отдельном объекте модели лучше по следующим причинам:

1. MVC - это реальная вещь, несмотря на безудержное злоупотребление через такие вещи, как использование DOM в качестве держателя штата. Сохранение состояния в модели, как правило, дает смысл MVC.
2. Сканирование с помощью тегов LI обходится дороже, чем использование listItems.focussed в коде.
3. DOM занят манипулированием, и ваши запросы к нему могут быть отложены или вызвать задержки.

По словам Мэтта @ https://github.com/Matt-Esch/virtual-dom, «Чтение некоторых свойств узла DOM даже вызывает побочные эффекты». Я склонен согласиться с этим, но я признаю, что я нахожусь в поиске большего количества доказательств по этому вопросу, поскольку парень, назначенный преследовать наши самые большие проблемы производительности приложений, которые, как я лично убежден, связаны в основном с DOM-зависимым кодом. *