サーバサイドレンダリングによるscala-jsフロントエンドフレームワークの作成。サーバー上でscala-js-domを使用できません

Question

私はscala-jsフロントエンドフレームワークを作成しています。その主な機能はサーバー側のレンダリングです。その考えは、document.createElement、element.appendChildなどでdomを操作するコンポーネントがあるということでした。サーバー上でHTMLDocument、Elementなどをサブクラス化し、そのメソッドをプレーン・ストリングhtmlに変換できるサーバー・ドームの実装でオーバーライドします。そこで、サーバモジュールにscalajs-dom_sjsの依存関係を追加し、それを試みました。しかし、HTMLDocumentとElementがあり、他のクラスではコンストラクタの内部にjs.nativeが呼び出され、「ライブラリのJVMバージョンを使用する」という例外がスローされます。明らかに存在しないもの。私は別の方法を使用して自分自身のDOMライブラリを実装することができますが、それは2倍の作業であり、サーバーとクライアントで実装する必要があるため、サーバーで一度しか実装しませんでした。

私の質問は、サーバー上でscala-jsライブラリのバージョンを厳密に使用することは禁じられていますが、回避策はありますか？

Answer 1

これが禁止されている理由は、気付いたように、DOM APIがjs.nativeでいっぱいであることです。これらのクラスはScalaでは実装されていません。これらはブラウザのDOM APIに含まれていますが、これはJVMに相当するものではありません。 scalajs-domで定義されている型をJVM上で使用することはできず、何か有用なことを期待しています。メソッドの実装はどこから来ますか？

実際には、JVM側に独自のDOMライクなライブラリを実装する必要があります。クライアント側で "再実装"したくない場合は、クラスにorg.scalajs.dom名前空間を再利用し、scalajs-domと全く同じ構造と型を与えることができます（明らかにjs.Anyは拡張されません）。

これは意味的に疑わしいことに注意してください。拡張型のjs.Anyは、通常のScala型と同じセマンティクスを持ちません。あなたは、通常の使用のためにいくつかの "互換性のある" APIを考え出すことができるかもしれませんが、それでも疑わしいです。

通常、サーバーとクライアントでいわゆる同形DOM操作を可能にするために、DOMに依存しないクロスコンパイルライブラリを作成します。クライアント側では、実際のDOMノードに「レンダリング」機能を提供します。サーバー側では、HTML内のクライアントに送信される文字列にレンダリングされます。

これはまさにScalatagsの機能です。