web-dev-qa-db-ja.com

jsdomのユースケースは何ですか

これを読んだ後 マイクロテンプレートは死んでいます 記事。私は興味がありました:

  1. サーバーでDOMを使用すると、テンプレートよりもクリーンで保守性の高いコードが得られるかどうか。
  2. テンプレートエンジンの代わりにjsdomを使用する方が効率的かどうか。
  3. Jsdomを標準のMVCセットアップのビューに組み込む方法。

そして、一般的にどのような状況では、 [〜#〜] ejs [〜#〜] のようなテンプレートエンジンではなく、 jsdom のようなサーバー側のDOM抽象化を使用する方が良いでしょう。または 翡翠

質問は node.js およびその他のSSJSに固有です

38
Raynos
  1. クライアント側のエンジニアと一致するその素晴らしい抽象化は、DOMがどのように構築および変更されるかを引き受けます。その点では、メンタルモデルが1つあるため、「よりクリーン」です。また、口ひげなどの「最も愚かな」テンプレートシステムの場合のように、他の点ではクリーンな宣言型マークアップの上に、テンプレート言語からの異種の構文の塊を混ぜる必要がないので、それも素晴らしいです。

  2. テンプレートにjsdomを使用する方が効率的だとは言えません。たとえば、「jsdomでのメモリリーク」をグーグルで見てみましょう。 jsdomはradであり、サイトをクロールする週末のプロジェクトやサーバーに関連しないタスクの実行などのタスクには非常に便利ですが、高性能Webサーバーの観点からは遅いと思います。

  3. これを因数分解する方法は10億あります。 「標準的な」方法として登場した方法はありません。私が見た1つの方法は、空の「テンプレート」、つまり何らかの方法でモデルを表すhtmlのブロックを送信し、それを使用してbootstrapからエンドビューを構築することです。モデル。その記事から、たとえば:


<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に解析され、お気に入りのセレクターエンジンを介してアクセスされます。これが変更を表すモデルごとに、変更イベントまたはコールバックを使用してビューを更新できます。例えば:

プロパティが変更されるたびに「model」が「change」イベントを発生させると想像してみましょう。

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、ソケット)についてさまざまな程度の仮定を持っています。 ioなど)。

編集

Jsdomで実行できるいくつかの本当に便利なことは、統合テストとスパイダリングを中心に展開します。

個人的には、tobiのアプローチを採用したプロジェクトを見たいのですが、クラウドベースのSeleniumテストを実行できるように、 https://github.com/LearnBoost/soda のようなものの上にマッピングしました。セレンなし(イモ以来、それは吸う)。

12
Josh

さて、私は実際に、週末にnode.jsで構築した小さなプロジェクトにJSDomが必要でした。そのため、サーバーでは、URLを受け入れて、指定されたURLからすべてのHTMLを取得して解析し、ユーザーがそのURLからサムネイルを選択できるように画像を表示する必要がありました。 (Facebookの入力ボックスにリンクをドロップするようなものです)そこで、サーバー側でHTMLをフェッチできるRequestというモジュールを使用しました。しかし、そのHTMLが私のプログラムに到達したとき、クライアント側のjavascriptのようにそれをトラバースする方法がありませんでした。実際のDOMがなかったので、document.getElementById('someId')とは言えませんでした。したがって、JSDomは、返されたHTMLをトラバースできる「仮の」DOMを提供することで役に立ちました。これで、私はまだサーバー側にいましたが、JSDOMはブラウザのウィンドウオブジェクトと非常によく似たwindowオブジェクトを作成し、返されたHTMLからDOMを作成しました。これで、サーバー上でも、window.$('img')を呼び出すことですべての画像を取得できました。通常のように要素をターゲットにして解析することができました。したがって、これはJSDomが解決策であることが判明した問題のひとつにすぎませんが、驚くほどうまく機能しました。これが役立つことを願っています!

13
Hacknightly

あなたの質問のポイント2はこのテンプレートテストケースによって答えることができます:

行く http://jsperf.com/dom-vs-innerhtml-based-templating/3

  • 「テストの実行」ボタンをクリックします。

  • しばらくお待ちください。溶接と他のテンプレートエンジンの多くを比較し、現在のベンチマークを提供します...

1
sebilasse

いくつか頭に浮かぶ:

  1. サーバーとブラウザー間でビュー/コントローラーを共有する
  2. データマイニング/クロール/処理
  3. AJAX /リアルタイムのもので使用されるHTMLのフラグメントの変換
  4. テンプレートタグを回避することによるロジックとコンテンツの絶対的な分離

そしてあなたの質問に答えるために:

  1. 多分。多くのことがコードの品質に影響を与えますが、それは正しい方向への一歩です
  2. いいえ、テンプレートエンジンはテンプレートをプリコンパイルできるため、常に高速になります
  3. これはおそらく新しい質問を正当化するのでしょうか?
1
Ricardo Tomasi