Каковы случаи использования JSDOM - PullRequest
35 голосов
/ 23 мая 2011

После прочтения Микро-шаблоны мертвы Статья.Мне стало любопытно:

  1. Приводит ли использование DOM на сервере к более чистому и понятному коду, чем к шаблонам.
  2. Эффективнее ли использовать jsdom вместо шаблонизатора
  3. Как включить jsdom в представление стандартной установки MVC.

И вообще, в каких ситуациях было бы лучше использовать абстракцию DOM на стороне сервера, например JSDOM , а не шаблонизатор, как EJS или Jade .

Вопрос относится только к node.js и другим SSJS

Ответы [ 4 ]

13 голосов
/ 24 мая 2011

Ну, мне действительно нужен JSDom для небольшого проекта, который я построил на выходных в node.js.Поэтому на моем сервере я должен был принять URL-адрес для извлечения, получить весь HTML-код с указанного URL-адреса, проанализировать его и отобразить изображения для пользователя, чтобы пользователь мог выбрать эскиз из этого URL-адреса.(Вроде как, когда вы перетаскиваете ссылку в поле ввода Facebook) Итак, я использовал модуль под названием Запрос, который позволяет мне извлекать HTML на стороне сервера.Однако когда этот HTML-код попал в мою программу, у меня не было возможности пройти его, как вы делаете с клиентским JavaScript.Поскольку не было реального DOM, я не мог сказать document.getElementById('someId').Поэтому JSDom пригодился, дав мне «временную» модель DOM, которая позволила мне пересмотреть возвращенный HTML.Теперь, хотя я все еще был на стороне сервера, JSDOM создал объект window, очень похожий на объект окна в браузере, и создал DOM из возвращенного HTML.Теперь даже на сервере я смог получить все изображения, позвонив по номеру window.$('img').Я мог бы нацелить и разобрать элементы как обычно.Итак, это всего лишь одна из проблем, где JSDom оказался решением, но он работал на удивление хорошо.Надеюсь, это поможет некоторым!

12 голосов
/ 24 мая 2011
  1. Это хорошая абстракция, которая подходит для инженеров на стороне клиента, чтобы понять, как DOM построен и модифицирован. В этом отношении он «чище», потому что есть одна ментальная модель. Это также хорошо, потому что нам не нужно смешивать множество разнородных синтаксисов из языка шаблонов поверх чистой декларативной разметки, как в случае с самой «глупой» системой шаблонов, такой как усы.

  2. Я бы не сказал, что более эффективно использовать jsdom для шаблонов. Посмотрите на google wrt, например, на «утечки памяти с помощью jsdom». jsdom - это rad, и он очень полезен для таких задач, как проекты выходного дня, для обхода сайтов, выполнения задач, не связанных с сервером, но я думаю, что это слишком медленно с точки зрения высокопроизводительного веб-сервера.

  3. Существует миллиард способов это учесть. Ни один метод не появился как «стандартный» способ. Один из способов, который я видел, - это отправить пустой «шаблон», то есть блок html, который каким-то образом представляет модель, а затем использовать его для начальной загрузки построения конечного представления из модели. Из этой статьи, например:


<li class="contact" id="contact-template">
    <span class="name"></span>
    <p class="title"></p>
</li>

Это «вид» в классическом отношении. В типичном веб-приложении это может выглядеть примерно так:

<li class="contact">
    <span class="name"><?= $name ?></span>
    <p class="title"><?= $title ?></p>
</li>

Чтобы использовать mvc, нужно настроить контроллер, который смутно знает о семантике вышеприведенного представления и модели, которую он представляет. Это представление анализируется в / a DOM и доступно через ваш любимый механизм выбора. Каждый раз, когда модель представляет изменения, вы можете использовать события изменения или обратные вызовы для обновления представления. Например:

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

controller = new Controller({ 
    view: $('#contact-template').clone(), // Assume jquery or whatever
    model: aContact 
});

// Assume some initialization that sets the view up for the first time
// and appends it to the appropriate place. A la:
// this.view.find('.name').text(model.name);
// this.view.find('.title').text(model.title);
// this.view.appendTo('#contacts')

controller.on('model.name.change', function(name){
    this.view.find('.name').text(name);
});

Это то, что системы типа Weld и Backbone.js делают для вас. Все они имеют разную степень предположений о том, где эта работа выполняется (на стороне сервера, на стороне клиента), какую среду вы используете (jquery, mootools и т. Д.) И как распределяются ваши изменения (REST, сокет). и т. д.).

Редактировать

Некоторые действительно полезные вещи, которые вы можете сделать с jsdom, вращаются вокруг интеграционного тестирования и паутинга:

  • https://github.com/mikeal/spider - веб-паук общего назначения, который использует обработку на основе событий узла и предоставляет вам jsdom / jquery, чтобы помочь вам легко получить доступ к DOM программным способом
  • https://github.com/assaf/zombie - безголовое тестирование браузера с использованием jsdom / jquery для интеграционных тестов
  • https://github.com/LearnBoost/tobi - аналогичное тестирование без браузера

Лично я хотел бы увидеть проект, который использовал подход Тоби, но сопоставил его с чем-то вроде https://github.com/LearnBoost/soda таким образом, чтобы мы могли проводить тестирование селена на основе облачных вычислений без селена (поскольку imo это отстой) .

1 голос
/ 02 апреля 2014

пункт 2 вашего вопроса можно получить с помощью этого шаблонного теста:

go http://jsperf.com/dom-vs-innerhtml-based-templating/300

  • нажмите кнопку «Выполнить тесты».

  • наберитесь терпения, он сравнивает сварные швы с множеством других шаблонных движков и дает вам текущие тесты ...

1 голос
/ 28 мая 2011

На ум приходят несколько:

  1. Совместное использование представлений / контроллеров между сервером и браузером
  2. Интеллектуальный анализ данных / сканирование / обработка
  3. Преобразование для используемых фрагментов HTMLв AJAX / реальном времени
  4. Абсолютное разделение логики и контента, избегая шаблонных тегов

И чтобы ответить на ваши вопросы:

  1. возможно.Многое влияет на качество кода, но это шаг в правильном направлении
  2. Нет, движки шаблонов всегда будут быстрее, так как они могут предварительно скомпилировать шаблоны
  3. Это, вероятно, требует нового вопроса?
...