当前位置：文江博客话题详情

jsdom有哪些用例

发布于 2024-11-09 06:16:56 字数 490 浏览 0 评论 0原文

阅读这篇微模板已死文章后。我很好奇：

在服务器上使用 DOM 是否会产生比模板更干净、更易于维护的代码。
使用 jsdom 代替模板引擎是否更有效。
如何将 jsdom 纳入标准 MVC 设置的视图中。

一般来说，在什么情况下最好使用服务器端 DOM 抽象，例如 jsdom 而不是模板引擎，例如 EJS 或

该问题特定于 node.js 和其他 SSJS

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

痴情 2024-11-16 06:16:56

嗯，我周末在 Node.js 中构建的一个小项目实际上需要 JSDom。因此，在我的服务器上，我必须接受要获取的 URL，从给定 URL 中获取所有 HTML，对其进行解析，并向用户显示图像，以便用户可以从该 URL 中选择缩略图。（有点像当您将链接放入 Facebook 输入框中时）因此，我使用了一个名为 Request 的模块，它允许我在服务器端获取 HTML。然而，当该 HTML 到达我的程序时，我无法像使用客户端 JavaScript 那样遍历它。因为没有实际的 DOM，所以我不能说 document.getElementById('someId')。因此，JSDom 派上了用场，它为我提供了一个“临时”DOM，允许我遍历返回的 HTML。现在，即使我仍在服务器端，JSDOM 创建了一个与浏览器中的 window 对象非常相似的 window 对象，并根据返回的 HTML 创建了一个 DOM。现在，即使在服务器上，我也可以通过调用 window.$('img') 来获取所有图像。我可以像平常一样定位和解析元素。所以，这只是 JSDom 被证明是解决方案的一个问题，但它的效果出奇的好。希望这对一些人有帮助！

回复收藏 0 原文

桜花祭 2024-11-16 06:16:56

这是一个很好的抽象，与客户端工程师对 dom 的构建和修改方式的理解相匹配。从这方面来说，它是“干净的”，因为有一种心理模型。也很好，因为我们不必在干净的声明性标记之上混合来自模板语言的大量不同语法，即使是“最愚蠢”的模板系统（例如 Mustache）也是如此。
我不会说使用 jsdom 进行模板化更有效。例如，看看 google wrt 的“jsdom 内存泄漏”。 jsdom 非常出色，对于爬行网站的周末项目、执行与服务器无关的任务等任务非常有用，但我认为从高性能 Web 服务器的角度来看它慢得要命。
有十亿种方法可以分解它。还没有一种方法成为“标准”方式。我见过的一种方法是发送一个空的“模板”，即以某种方式表示模型的 html 块，然后使用它来引导从模型构建最终视图。例如，从那篇文章中可以看出：

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

这是经典方面的‘见’。在典型的 Web 应用程序中，它可能看起来更像是：

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

要使用 mvc，需要设置一个控制器，该控制器模糊地了解上述视图及其表示的模型的语义。该视图被解析为 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、socket. io等）。

编辑

您可以使用 jsdom 围绕集成测试和蜘蛛抓取做一些真正有用的事情：

https://github.com/ mikeal/spider - 通用网络蜘蛛，利用节点基于事件的处理，并为您提供 jsdom/jquery 来帮助您以编程方式轻松访问 DOM
https://github.com/assaf/zombie - 使用 jsdom/jquery 进行无头浏览器测试进行集成测试
https ://github.com/LearnBoost/tobi - 类似的无头浏览器测试

就我个人而言，我希望看到一个采用 tobi 方法的项目，但将其映射到类似 https://github.com/LearnBoost/soda 这样我们就可以在没有selenese的情况下进行基于云的selenium测试（因为在我看来，它很糟糕）。

Its a nice abstraction that matches a client side engineers take on how the dom is built and modified. In that respect it is 'cleaner' because there is one mental model. Its also nice because we don't have to mix a kluge of disparate syntaxes from a templating language on top of otherwise clean declarative markup as is the case with even the 'stupidest' templating system, such as mustache.
I would NOT say its more efficient to use jsdom for templating. Go take a gander at google wrt to 'memory leaks with jsdom' for instance. jsdom is rad, and is super useful for tasks like weekend projects for crawling sites, doing non-server related tasks, but I think its slow as shit from a high performance web server perspective.
There are a billion ways to factor this. No method has emerged as a 'standard' way. One way that I've seen is to send down an empty 'template', i.e. a block of html that represents a model in some way, and then use that to bootstrap building your end view from a model. From that article, for example:

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

This is the 'view' in the classic respect. In the typical web application, it might look something more like:

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

To use mvc, one sets up a controller that is vaguely aware of the semantics of the above view and the model it represents. This view is parsed into the/a DOM and accessed via your favorite selector engine. Each time the model this represents changes, you might use change events or callbacks to update the view. For instance:

Lets imagine that 'model' fires a 'change' event every time a property changes.

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);
});

These are what systems like Weld and Backbone.js do for you. They all have varying degrees of assumptions about where this work is taking place (server-side, client-side), what framework you're using (jquery, mootools, etc), and how your changes are being distributed (REST, socket.io, etc).

Edit

Some really useful things you can do with jsdom revolve around integration testing and spidering:

https://github.com/mikeal/spider - general purpose web spider that makes use of node's event based processing and gives you jsdom/jquery to help you easily access the DOM in a programatic way
https://github.com/assaf/zombie - headless browser testing using jsdom/jquery for integration tests
https://github.com/LearnBoost/tobi - similar headless browser testing

Personally, I'd like to see a project that took tobi's approach, but mapped it on top of something like https://github.com/LearnBoost/soda such that we can do cloud based selenium testing without selenese (since imo, it sucks).

回复收藏 0 原文