SheetForge Web
SheetForge は、コンパニオンの Web アプリを web.sheetforge.workers.dev で提供しています。これは、オーサリング・検証・シートのリフレクションをブラウザーにもたらします——Unity も、インストールも不要です。
同一のコア、再実装ではない
Web アプリは、まったく同じ C# コアのソース——ヘッドレスの .NET テストハーネスが実行するのと同じソース——を、.NET の browser-wasm アセンブリへコンパイルしています。パーサーやバリデーターの第二のコピーは存在しないため、両者が乖離することは決してありません: 一度直したルールは、両方の場所で直っています。
この設計から、二つのことが直接導かれます。
- あなたのコンパイル済みプラグイン DLL は、無改修のまま読み込まれ、ここでもエディターと 同じスロット を有効化します(下記)。
- このサイトのシート構文ルールは、ブラウザーでも同一に成立します。 マーカー、型システム、
@overlap、@style、@enum,@loc、参照整合性のすべてが同じように振る舞います。答えているのが同じコードだからです。これにはIntId@Tab,LocRef@Tabの整合性も含まれます——シート構文 を参照してください。
一つのプラグイン、十二のスロット、二つのホスト
プラグインに「Web 用のサブセット」は存在しません。組み立て——インスタンス化、順序付け、隔離、互換性ゲート——は、両方のホストが呼び出す、一つの純粋な Core の関数です。異なるのは 発見 の方法だけです: Unity はプロジェクトの型をインデックス化し、ブラウザーはあなたがアップロードしたアセンブリをスキャンします。
そのため、プラグインが埋められる十二のスロットは、両側で同じです:
| スロット | ブラウザーでは |
|---|---|
| enum・セルパーサー・ラッパー型 | セルは、あなた自身の記法を通じてパース・検証・ラウンドトリップされます |
| ドメインバリデーター | あなたのルールが、コアのルールと並んで Problems に表示されます |
| エッジコントリビューター | あなたの記法の内部に埋め込まれたリンクが、キャンバスに描画され、参照インデックスに数えられます |
| 構造マーカー | あなたの @marker 行が受け入れられ、検証されます |
| シートテンプレート | あなたのテンプレートが Create sheet に表示されます |
| キャンバスオーグメンター | 仮想ノード、追加のエッジ、レイヤーと表示のヒント |
| コードレジストリ | コードの中に存在するキーは、壊れた参照として描画されなくなります |
| カラープリセット | アプリの CSS 変数にマッピングされます |
| 宣言的な Studio UI | あなたのアクション・パネル・列バッジ・セルエディターの hint が、React で描画されます |
| UI 文字列 | あなたのラベルは、t() が参照するのと同じオーバーレイを通じて、ユーザーの言語に追従します |
| パイプラインオブザーバー | エディターの場合とまったく同じく、インポートサイクルの終了時に通知されます |
宣言的サーフェスこそが、プラグインの オーサリング 拡張がここに存在できる理由そのものです。UIToolkit の要素を返す契約は、ブラウザーには決して読み込めません。そのため外殻はデータとして記述され——id、ラベルキー、配置、トーン——各ホストは自身のウィジェットでそれを描画します。
語彙では語れない何かをパックが必要とする場合、同じ id の下に、エディター専用のリッチパネルを登録します。エディターはそちらを描画し、ブラウザーは記述された方を描画するため、その拡張が単純に欠落することは決してありません。
描画時には二つのルールが成立します。プラグインから届くテキストはエスケープされ、描画されてから状況が変わったアクションは、古い id に対して行動する代わりに、正直な no-op で答えます。
プラグインアセンブリは、自身がどの世代のプラグインフォーマットに対してビルドされたかも宣言できます。それがこのホストの読み取れる範囲から外れている場合、アセンブリ全体 が、半分だけ読み込まれるのではなく、読める理由とともに拒否されます。これは、マーケット経由のインストール・サイドロード・ローカルファイルのいずれの経路でも、同じ宣言を読み取る同じゲートです。プラグイン作成 を参照してください。
Unity 側に残るもの
ローカライズについても、同じ正直さが貫かれています: ローカライズシート はここで完全にオーサリングされ検証されますが、Unity Localization の StringTable を同期するのはエディターの仕事です——ブラウザーには、書き込み先となる Unity プロジェクトがありません。
コード生成とベイクは、引き続き Unity だけの責務 です。ブラウザーは .cs ファイルを出力することも ScriptableObject を書き込むこともできず、それができるふりもしません。プロジェクトそのものを必要とするものについても同じです: アセットピッカー、Project ウィンドウからのドラッグ&ドロップ、そしてそれらがステージングする Addressables への登録は、エディターにしか存在しません。AssetRef@Group<Type> の <Type> は、ブラウザーでもパースされて表示されますが、解決——そして型チェック——されるのは、プロジェクトの型が読み込まれている場所だけです。そしてエディターのアセット サムネイル・拡大表示・オーディオ再生 には、Web 側の対応物がありません。ブラウザーには読み取るべきプロジェクトアセットがそもそも存在しないためです——Web のグリッドにおけるアセットセルは、そのアドレステキストにすぎません。
Web の出力は、リフレクションされたシート——検証され、ラウンドトリップされたソース——であり、ベイクされたアセットではありません。ブラウザーでオーサリングと検証を行い、強く型付けされたクラスとベイクされた SO が欲しくなったら、Unity でインポートを実行してください。どちらの場合も、シートが唯一の信頼できる情報源であるため、二つのサーフェスはシートで出会います。
Web アプリができること
すべては、WebAssembly のコアに対する 単一の JSON 境界契約 を通じてラウンドトリップされるため、ブラウザーの UI が、コアがすでに所有しているルールを再導出することは決してありません。
| 領域 | 手に入るもの |
|---|---|
| オーサリングセッション | インポート、プロジェクション、そして同じインポートバリデーターが供給する Problems パネル——別の検証ではなく、pre-flight の診断結果です。インポートは TSV・CSV ファイルと .xlsx ワークブック を受け付けます——ワークブック内のすべてのシートは、エディターが使うのと同じリーダー(WebAssembly にコンパイルされたもの)によって読み取られ、それぞれ独自のタブとして届きます。何かを解釈しなければならなかった場合——数式のキャッシュされた値、yyyy-MM-dd テキストとしての日付、読み取られなかった書式——インポートダイアログは 「How this workbook was read」 という注記でその旨を伝えます。 |
| テーブル編集 | 型ごとのセルウィジェット、undo、列の固定、並べ替え、検索、@style によるグルーピングと色分け——さらに、エディターが持つスプレッドシートの列機能一式も備えます: ヘッダーのハンドルをドラッグして列の幅を設定し(ダブルクリックで自動調整、このブラウザーにシートごとに保存されます)、記号と境界線を正直に保ったまま列を非表示・表示にでき、列ごとの値フィルタは検索と組み合わさり、列のデータのクリアは一つの undo ステップです。+ Row は、提案されたキー——整数 id 列はあらかじめ入力済み——を持つ行を一度にステージングし、キーセルでの名前変更を待つ状態にします。キー列のないシートは、その理由とともにこれを無効化します。Enum セルと任意の真偽値セルは、参照セルが使うのと同じ検索可能なピッカーを開きます。そして ピッカーウィンドウは常に一つだけ開きます: 別のものを開くと最後のものが閉じ、ほかの場所をクリックするか Esc を押すと閉じます。行番号と列記号は選択できます(Ctrl でトグル、Shift で範囲指定)。ヘッダーと本体は選択範囲をハイライトし、選択されたセルはキーボード操作に追従する枠を描きます。選択は挿入線とともに 新しい位置へドラッグできます——連続していない選択は、選択した順序のままドロップ地点にまとめられて到着し、これは一つの undo ステップです——一方、右クリックメニューは、幅・自動調整・非表示・移動・削除・データのクリアを選択されているすべての列に適用します(移動と削除は選択されているすべての行に)。一度に一つの対象にしか意味を持たない項目は、それぞれ独自のセクションに分かれています。Enum 定義シートは、データシートと同じ列幅の軸を持ちます——ドラッグ、ダブルクリックでの自動調整、正確な幅の指定、データへの自動調整、非表示。200 行を超えると、グリッドは表示ウィンドウ(とオーバースキャン)だけを描画し、スペーサーが真のスクロール高さを保持します——エディターのテーブルと同じ閾値であるため、大きなシートでもどちらも同じ感触になります。 |
| 視覚的な値 | Color、AnimationCurve、Gradient のセルは、セルいっぱいに広がるプレビュー——スウォッチ、カーブの折れ線、グラデーションバー——を表示し、ポップオーバーで完全なエディターを開きます: カラーエディターには HSV スクエア、色相とアルファのスライダー、HEX 入力欄があります(ブラウザーのネイティブなカラー入力にはアルファがないため使用していません)。カーブエディターにはズーム可能なグリッド、ドラッグ可能なキーとタンジェントハンドル、タンジェントモード(Free、Auto、Linear、Constant、ClampedAuto——キーを右クリックするか選択を使います)、分離と重み付きのトグル、数値入力欄、開始前/終了後ラップ、そして リニア / イーズイン・アウト / 一定 のプリセットがあります。グラデーションエディターには、ドラッグ可能なカラーキーとアルファキー(それぞれ最大 8 個)、モード選択、色空間選択があります。あらゆる変更は WebAssembly のコアを通じてラウンドトリップされます——パース、タンジェントの再計算、サンプリングはすべて JavaScript ではなく C# です——そしてコミットされるテキストは、エディターが書き込むのとバイト単位で同一の正規形です。変更はその場でただちにコミットされます——エディターのネイティブフィールドとまったく同じです: エディターが開いている間、セル・キャンバス・Problems はそれに追従し、一つの編集セッションはどれだけ多くの変更を行おうと一つの undo ステップにまとまり、エディターを開き直すと新しいステップが始まります。Apply はなく、唯一のボタンは Close です(Esc でも閉じられ、カラーエディターでは Esc を押すとそのセッション開始前の値にも復元されます)。元に戻すのは Ctrl+Z です。何も変更せずに開いて閉じても、何もステージングされません。任意列は、空のときは — を表示し、右クリックメニューで クリア（デフォルト） を提供します。三つの型の List<> はチップリストで、追加・削除・並べ替え・編集のジェスチャーはそれぞれが一つの undo ステップです。プレビュー帯は、エディターのテーブルと同じく、標準の行の高さに収まります。キャンバスの value row も同じコンポーネントを使います。 |
| 構造編集 | 列の追加/削除/移動、四項目の ✎ 列フォーム、タブの名前変更(相互入れ替えと循環も含み、xlsx タブはブロックされます)、シートの作成/削除、アクティブな設定のドロップダウン——それぞれが一つの undo ステップとしてステージングされます。Enum 定義シートも同じように——新しい Enum の定義、名前変更(参照するすべての @type が同じバッチで書き換えられます)、削除、列の並べ替え、基になる型と説明の編集——エディターと同じルールでオーサリングできます。判定を下しているのが同じコードだからです。 |
| タブ横断検索 | サイドバーの All エントリは、すべてのシートの id とフィールド値を部分一致で検索し、シート・キー・フィールド・値を 50 行ずつのページで一覧表示します——エディターと同じマッチング・順序・ページサイズです。そのセッションが今まさに表示している値——ステージング済みの編集も含みます——を読み取るため、たった今変更した値も即座に見つかります。結果をダブルクリックする——または選択して Enter を押す——と、一致したセルが選択された状態でそのシートが開きます。検索がセッション自体を読み取るため、どの結果にもジャンプできます。 |
| ローカライズ | ローカライズシート は、ここでも通常のシートです——オーサリング、検証、ロケールごとのカバレッジも含めて。データシートの LocRef セルはエントリのソースロケールのテキストをインラインで表示し、他の参照と同じ検索可能なキーピッカーを開きます。空のセルに入力すると、エディターとまったく同じように、キー・ソーステキスト・参照を一つの undo ステップとしてミンティングします。ロケールレンズ は表示するロケール列を切り替え(表示のみ)、翻訳ワークブック は選んだロケールを xlsx にエクスポートし、返ってきたファイルをロケール列のみのマージとして再インポートします。Unity Localization の StringTable の同期は、引き続きエディター側のものです。 |
| レコードキャンバス | レコードの材料と消費者はカードとして表示され、ワイヤーをドラッグして接続します——キャンバスは、エディターと まったく同じ 純粋なレイアウト・配線・編集チェーンのコードを再利用しているため、ピクセル単位の計算は JS のグラフライブラリではなく C# の中にあります。カードはテーブルと同じ投影を表示します: このバッチでステージングされた列は、ペンディングとしてマークされた状態ですでにカード上に現れ、ステージングされたリネームは元の値の上に新しい名前を表示し、ステージングされた削除はここでもその行を取り除きます。 |
| 出力 | シートごとの TSV / CSV ダウンロード、選択したすべてのシートを一つのファイルにまとめた .xlsx ワークブックのダウンロード(ワークブックの規則が扱えないシート名は調整されて報告され、サイレントに改名されることは決してありません)、そして Google シートの読み書き——push のたびにシートのデータ入力規則のドロップダウンが自動的に更新されます(下記参照)。 |
似ているのではなく、同一に作られている
Web の UI は、共有されるロジックのレベルに至るまで、意図的にエディター内の Data Studio と一致させてあります。
- 共有される答え。 ヘッダーの述語(
pending/edited)、diff モーダル、プロジェクションの合成順序は、共有された C# であるため、両方のサーフェスは同じ問いに同じ答えを返します。 - 共有される文。 Web が Studio の画面を鏡写しにする場合、Studio 自身の文字列キー を使います。値は、書き直されるのではなく、ビルド時にエディターの言語テーブルから生成されます。両方のサーフェスに表示される文を追加するには、
Lang*.csに一つのキーを足すだけです——乖離は、単に推奨されないのではなく、構造的に不可能です。二つのものは意図的に分離されたままであり、ビルド時のガードがその境界を強制します:- 純粋に Web 専用の文字列は、Web のカタログにとどまります。
- 診断とレポートは WebAssembly のコアが描画するのであって、UI 側で言い換えられることはありません。
- 共有される見た目。 グラフとシートは、サイズ変更可能な分割パネルに一緒に表示され、エディターのキャンバスのクランプ挙動を鏡写しにします。すべての色は、エディターの
.aw-rootトークンセットという単一の信頼できる情報源から来ています——ハードコードされたパレットはありません。 - 共有されるコンポーネントキット。 UI は、自社製の
awキットの上に構築されています。そのクラス名・トークン・ポップアップの配置は、エディターの USS と、正規の HTML モックアップに一対一で一致します。今では一つのモックアップが二つの窓口——Web アプリと UIToolkit のエディター——に供給されており、Web が独自に乖離することはありません。web/Docs/ui-parity.mdは、変更があったときに Web が Studio にどう追従するかを記録しています。 - 共有されるセルエディター。 あるセルがどのウィジェットを得るかは、Core のセルエディター hint によって決まります——まずパックの登録、次に組み込みのテーブル(
BuiltinCellEditorHints)の順です——そのため、ColorPicker、CurveEditor、GradientEditorのいずれかのアーキタイプを宣言したプラグインの型は、ここでも Unity で開くのと同じエディターを開き、両方のホストが同じ型名に対して異なるウィジェットを選んでしまうことはありません。 - キャンバスの整合性。 ドラッグ&ドロップは、エディターと完全に同等になりました: 中ボタンドラッグまたは Alt ドラッグでのパン、空白部分でのカスケードメニュー、ワイヤーとノードのインスペクター、選択中のワイヤーのゴースト表示、確認ダイアログ付きの terminus 削除です。ズーム範囲はエディターと同じ(25〜200%)であり、カードの寸法は JavaScript 側の第二のコピーではなく Core から来ています。
- 共有される型一覧。
@typeのドロップダウンは、パーサーレジストリ が実際に知っているものを、エディターがグルーピングするのとまったく同じように提示します: 組み込みのスカラー(Color、AnimationCurve、Gradientを含む)、RecordId/IntIdキー、RecordId@TabとIntId@Tabの参照、Enum<…>、AssetRef@Group、そして読み込まれたプラグインが登録したあらゆる型やラッパーです。そのため、新しい型を登録するプラグインは、Web 側の変更なしにブラウザーに現れます。(WebAssembly のコアが起動を終える前は、最初の描画は組み込みの四つのスカラーにフォールバックします。)
どちらを使うべきか
- ブラウザー は、どこからでも素早くオーサリング・検証・シート編集を行いたいとき、そして Unity を開かないチームメイトのために使ってください。
- Unity は、生成された C# クラスとベイクされた ScriptableObject——インポート・コード生成・ベイクの各段階——が必要なときに使ってください。
どちらも同じシートに書き込むため、一方で行った変更は、次に読み取ったときにもう一方にも反映されます。
関連ページ
- シート構文 — ブラウザーのコアが強制するルール、変更なし
- ローカライズシート — ブラウザーとエディターの両方における、ゲームテキストのシート
- Web プラグインマーケット — ブラウザーでのプラグインのインストールとサイドロード
- Web Google シートアクセス — デプロイ済みサイトからのシートの読み書き
- Data Studio — Web アプリが鏡写しにしている、エディター内蔵のオーサリングサーフェス