ほとんどの人とは異なる理由で、私は労働者にDOM APIが必要です。多くの人々は、DOMを更新してメインスレッドをブロックしないように、WorkersのDOMを望みます。 HTMLを出力するためにXMLデータを効率的に解析し操作することができるように、私はそれが必要です。

最近のプロジェクトでは、できるだけ多くのロジックをサーバー、サービスワーカー、クライアントの間で共有したいと思っていました。このプロジェクトは本質的に単純なRSSフィードリーダーであり、RSSフィードを取得し、データを解析し、（TweetDeckによく似た）列の素晴らしいセット、および単一のマージされたリストにマージします。

このプロジェクトは、3つの場所でRSSフィードデータを使用して動作します。

1.クライアントで＆mdash;ページが初めて読み込まれると、AJAXは私が実行しているプロキシサービスからRSSフィードデータを要求し、その後、クライアントでそれをレンダリングする前に window.cachesオブジェクトに生データをキャッシュします。 2.サービスワーカーで＆mdash; 1.メインページが読み込まれ、サービスワーカーがインストールされると、サービスワーカーはシェルをロードしてRSSフィードデータにマージし、2回目のロードでAJAXリクエストを作成する必要がないようにします。 1.クライアントからプロキシへの要求が行われると、サービスワーカーはインストールされると、要求をインターセプトし、 window.cachesからデータを提供します。これにより、サイトはオフラインで作業できます。 3.サーバー上で＆mdash;ページが要求されると、サーバー上にキャッシュされたデータの一部を取得し、クライアントに送信する応答に直接マージすることができます。サーバから直接コンテンツの一部をレンダリングすることで、最初のロード時に安定したビューポートを持つことができます。これは通常、モバイル（およびSpeedIndex）上の低速接続では重要です。

それぞれの場合、RSSデータとマップをJSONオブジェクトに変換する単純なプロセスがあり、それをテンプレートに適用してHTMLを生成することができます。 1つのテンプレートと統合されたロジックをクライアント、サーバー、およびサービスワーカーに保持することが重要な要件でした。 1組のテンプレートを維持するということは、データをレンダリングするすべての場所で入力データが一貫していなければならないことを意味します。

私はプロキシサーバーを実行するので、シンプルなソリューションがあります。すべてのRSSフィードをサーバー上の一貫したJSONフォームに変換するだけです。私はこれを以下の理由で割り引いた：

*データ変換は処理に集中する可能性があります。 RSSフィードがhttpsにあり、CORSをサポートしている場合、プロキシサービスを経由する必要はありません。*データ変換はクライアント上で共有負担を軽減するために行うことができます。これは、フィードリーダーがユーザーの認証を必要とする可能性のあるコンテンツを表示することができるため、将来私が入りたい状態です。

ブラウザにはDOMParserというAPIが少ししか使われていないので、クライアント上でデータを処理することは可能です（私の場合は必要です）。 DOMParserは名前の通りです：DOMを構築する生のXMLとHTMLのパーサー。いったんDOMを持っていれば、通常のDOM（appendChild、getAttributeなど）を使って何かを行うことができます。

let parser = new DOMParser();
let dom = parser.parseFromString('<a><b>hello</b></a>', 'application/xml');
let bString = dom.querySelector('b').textContent;

かなりシンプルなものですが、これを使ってRSSデータを単純なJSON構造に変換して、テンプレート機能に渡すことができます（コードを見たい場合はここにあります。）

これはクライアントでは完全に機能しますが、Webワーカー、サービスワーカー、またはネイティブDOMにはDOMはありません。

幸いにもどこでも動作するnpmライブラリがあります。 xml-domは、レベル3機能を備えたW3C DOMのレベル2準拠の実装であり、期待どおりに動作します。それは世界の終わりではありませんが、ブラウザが既に組み込まれているもののために、JSの64kbをインポートするのはばかげているようです。

私は従業員のDOM APIのための ‘VDOM’ユースケースしか見ていませんが、重要なユースケースだと思うのですが、別の重要なユースケース、すなわちメインスレッドからのデータ操作になると思います。ネイティブ実装と同じ速度で実行されない膨大なポリフィルをインポートせずに、HTMLやXMLドキュメントを処理するためにワーカーを使用することはできません。 OSSのコントリビュータに依存して、維持する必要があるように見えます。

xml-domを管理してくれてありがとう。ヒーローズの仕事。

Paul Kinlan

Trying to make the web and developers better.