注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
以下は、Slate に関するよくある質問です。 一般的な情報については、Slate ドキュメントを参照してください。
--
多くの点で、Slate は開発者が利用できる Foundry ツールの中で最も複雑なツールです。Slate は、シングルページ Web アプリケーションを構築するためのツールを扱いやすい形でまとめていますが、組み込みの制約やガードレールは少なく、その代わりにさまざまなパターンを自由に実装できます。この柔軟性は強力な機能であり、Slate で多種多様なアプリケーション、ダッシュボード、ワークフローツールを構築できます。一方で、パフォーマンスの低下や混乱、非決定論的なアプリケーションの動作を引き起こすアンチパターンも容易に実装できてしまいます。
こうした実装上の問題の中でも特に複雑なものの根本原因を突き止めるには、Slate 開発のベストプラクティスと Web アプリケーション開発の一般原則を踏まえて、アプリケーションのロジックをリバースエンジニアリングする必要があります。
以下では、これらを分類して、アンチパターンが見られる箇所を取り上げ、よりよい方法や解決に向けた指針を示します。まず、関連する Web 技術の項目から始めます。
これらの知識は Slate 固有のものではありませんが、こうした基礎への誤解が、Slate アプリのパフォーマンス、レイアウト、スタイル設定に関する多くの疑問の根本にあります。Slate アプリは、実質的に独自に構築された Web アプリケーションです。
W3Schools ↗ をはじめ、多くの情報源でこれらのトピックに関する基本的なチュートリアルが提供されています。
SQL と、Postgres データベースがクエリを組み立てて実行する仕組みを理解しておくことも役立ちます。ほとんどのアプリケーションは、アプリケーションへのアクセスのために Foundry データセットからデータが同期される Postgres インスタンスに対してクエリを実行し、データを取得するためです。
クエリの開発、エラー、パフォーマンスに関する多くの疑問は Slate 固有のものではなく、一般的な検索クエリで答えを見つけられます。多くの場合、Postgres + [question] の形式で検索できます。
ただし、Slate は Postgres が生成するエラーメッセージをパースして提示する点では、特に使いやすいとはいえません。これらの問題の一般的な原因と対処方法については、以下のセクションを確認することを推奨します。より詳しい情報については、Postgres のパフォーマンスとチューニングのガイドラインを参照してください。
Slate で複雑なアプリケーションを構築するには慣れが必要です。Slate が提供するフレームワークの中で作業するのではなく、ほかのアプリケーション開発の概念を Slate に「押し付ける」ことで、多くのアンチパターンが生じる可能性があります。特定の機能を実装する際には、これらの Slate の基本概念に最もよく適合する、暗黙の「正しい」パターンが存在することがよくあります。
こうした複雑さの多くは、依存関係を理解するで説明されています。このドキュメントでは、Slate の中核となるコンポーネント（依存関係グラフ、イベントフレームワーク、ウィジェット、クエリ、関数など）、一般的なパターン（および一般的なアンチパターン）、設計と実装のベストプラクティスを取り上げています。
よくある疑問の多くは、すでに詳しく説明されている内容で解決できるため、開発者とサポートエンジニアはこのドキュメントを理解しておくことを推奨します。多くの場合、疑問に答える最善の方法は、個別の事例を解決しようとすることではありません。たとえば、アプリを開いてユーザーの開発上の判断をリバースエンジニアリングしようとするのではなく、ユーザーが直面している問題がどのようなカテゴリーに属するかを理解し、以下のいずれかの関連する説明へ案内することです。
特によくある事例の一部については、この FAQ ドキュメントから、簡潔な説明や役立つ参考資料にすばやくアクセスできます。
クエリに関する疑問にはさまざまなものがあり、根本原因を特定することで、さまざまな解決方法が見えてきます。明確なエラーメッセージが表示される場合もありますが、エラーメッセージが表示されなかったり、失敗の条件が非決定論的であったりする場合（発生することもあれば、発生しないこともある場合）もあります。以下のトラブルシューティング手順では、よくある根本原因と、それに対応する解決方法を紹介します。
トラブルシューティングを行うには、次の手順を実行します。
クエリが同期ネットワークリクエストの一般的な使用パターンに沿っていない場合があります。
この一般的なカテゴリーの疑問については、インデックスとスキーマ設計を最適化するドキュメントを参照してください。また、ブラウザーに返されるデータが JavaScript 関数での大幅な加工を必要とせず、最終的な形式になっているようにアプリケーションを構成することを検討してください。
問題が、Postgres によるリクエストの解釈や応答方法に関連している場合もあります。
このような疑問は、多くの場合、Postgres + [error message] または Postgres + [desired query] を検索することで解決できます。クエリのパフォーマンスのトラブルシューティングや調査に関するすべての疑問については、Postgres のクエリパフォーマンスとチューニングガイドを参照してください。
また、開発者の設定に従って Slate がクエリを実行する方法やタイミングに問題がある場合もあります。
20s で赤くなった場合は、Slate がクエリをタイムアウトさせたことが失敗の原因だと判断できます。{{#if}} 文、または関数内のロジックによって、null 値やその他のエッジケースから保護されていることを確認してください。クエリがタイムアウトする場合、主に2つの要因が関係しています。
アプリケーション開発者は、これらの要因と、クエリへの影響を理解する必要があります。どちらも Slate や Foundry 固有の要因ではないため、Postgres SQL query performance を検索することで解決に向けて進められます。また、Postgres のクエリパフォーマンスとチューニングガイドで、一般的なベストプラクティスやヒントを確認できます。
トラブルシューティングを行うには、次の手順を実行します。
アプリ開発者によく見られる問題に基づく、役立つヒントをいくつか紹介します。
データの規模：Postgres に同期するデータセットの規模を制限します。たとえば、1年分のデータだけが必要な場合は、全期間のデータセットを同期してからクエリで絞り込むことは避けます。
データの規模：テーブルの列数を減らします。たとえば、クエリで数列だけを選択する場合は、オーバーヘッドを避けるため、テーブルを同期する前にトランスフォームで列を削除します。
データの規模：返す行数をできるだけ少なくします。生の行を表示する場合は、クエリへのレスポンスとして数百行を超える行を返すのではなく、OFFSET と PAGING を使用して追加の行を取得します。
クエリの最適化：可能な限り、コストの高い SQL コマンドを避けます。よく問題になるのは、COALESCE、DISTINCT、「完全」ではない列（一部の値が null であるなど）に対する JOIN、先頭のワイルドカード（%）や複雑な一致式を含む WHERE 句のフィルターです。
クエリの最適化：処理を上流に移します。データのクリーンアップ（null の削除、日付の書式設定、表示値のマッピング）やメトリクスの計算（月ごとの合計、バケット間の平均など）は、可能な限りトランスフォーム層に移す必要があります。ユーザーがフィルターを通じてこれらをカスタマイズできるようにする必要がある場合でも、いくつかのディメンションにわたってメトリクスを「事前集計」しておき、その条件を満たす数行だけを対象に合計や平均などを計算する、はるかに単純なクエリを実行できます。
クエリの最適化：EXPLAIN ANALYZE を使用してクエリプランを取得し、Postgres がクエリをどのように解釈しているかを理解します。これにより、時間がかかっているボトルネックを特定でき、最適化の対象をさらに絞り込めます。こちら ↗は、結果を読み取って理解するために役立つ入門記事です。
クエリの最適化：Postgres のクエリを最適化するを確認してください。
Postgres では、列名は小文字と見なされます。Foundry では列名の大文字・小文字やスペースを柔軟に使用できるため、テーブルを Postgres にインデックス化すると、大文字・小文字を保持するためにテーブルが "（二重引用符）で囲まれます。
そのため、列名に大文字が含まれている場合は、SQL クエリ内の参照も二重引用符で囲む必要があります。
この動作の詳細については、StackOverflow ↗を参照してください。
トラブルシューティングには、次の手順を実行します。
列識別子の扱いが適切でないクエリでは、多くの場合、次のようなエラーが発生します。
ERROR: column mixedcasecolumn does not exist HINT: Perhaps you meant to reference the column "Mixed Case Column"
この場合のベストプラクティスは、該当するデータセットを更新して、Postgres のデフォルトに準拠した列識別子を使用することです。通常は小文字を使用し、スペースをアンダースコアに置き換えます。それ以外の場合は、識別子が二重引用符で適切に囲まれていることを確認してください。
Foundry データセットへのデータのライトバックを伴う複雑なアプリケーションを構築する上級ユーザーは、Phonograph サービスを使用します。Foundry インスタンスで Phonograph Reference Application が利用可能であることを確認してください。
よくある質問のほとんどには、そこでクエリの例やウィジェットのパターンを使って回答しています。また、リファレンス例の内容のほとんどは、Foundry にライトバックする方法でも確認できます。
トラブルシューティングには、次の手順を実行します。
この機能は奥深く複雑ですが、よくある問題のほとんどはドキュメントで扱っているため、ドキュメントを注意深く読んでください。質問や問題がある場合は、Palantir サポートにお問い合わせください。
エッジケースに該当する設定では、テキストエリアウィジェットを1つ以上参照するライトバッククエリが、テキストの一部だけを含む Phonograph リクエストを送信することがあります。たとえば、ユーザーが This is a test message for writeback のような長いテキストを入力し、すぐに送信ボタンを押してライトバッククエリをトリガーすると、This is a te だけが含まれる場合があります。
根本的な原因は、テキストエリアウィジェットで使用される0.5秒のデバウンス遅延です。これは、ウィジェットへの入力でキーを押すたびに依存関係グラフが再評価されるのを防ぐためのものです。この遅延により、次の条件を両方とも満たす場合に限り、テキスト全体が含まれないままクエリが送信されます。
トラブルシューティングには、次の手順を実行します。
最も簡単な解決策は、長いテキストを入力してから0.5秒以内に送信の選択肢を使用できないように、ユーザーエクスペリエンスを調整することです。たとえば、クエリを送信する前に確認ダイアログを追加したり、フォーム要素の順序を変更して、テキストエリアウィジェットの後に入力する別の項目を配置したりします。
ほかの解決策としては、テキストエリアウィジェットを、デバウンス遅延のないテキスト入力ウィジェットに置き換える方法があります。また、送信ボタンを押してからクエリが実行されるまでの遅延バッファーとしてトーストウィジェットを使用し、テキスト全体が含まれるまで十分な時間が経過するようにすることもできます。
Slate の関数は、アプリケーションのほかの部分から隔離されたサンドボックス内で実行される基本的な JavaScript です。関数はすべてユーザーが生成したコードであるため、関数に関する問題の大半は、根本的には誤解や、目的の機能を JavaScript で正しく実装できていないことに起因します。
トラブルシューティングには、次の手順を実行します。
デバッグの基本的な手順は、期待される動作になるまで関数を単純化し、その後、予期しない動作が再び発生するまで少しずつ複雑な処理を戻していくことです。これにより、目的の動作を正しく実装する方法を理解するために、さらに調査が必要な箇所を特定できます。
デバッグに使用できるもう1つのツールは、Chrome DevTools Debugger ↗ です。関連するDevTool を使用してデバッグするセクションも参照してください。debugger; ステートメントを使って、関数に「ブレークポイント」を追加します。
次に、Chrome DevTools パネルを開いた状態で、関数ウィンドウのテストボタンをクリックします。関数の実行はブレークポイントで一時停止し、その後は関数のコードをステップ実行しながら変数の値を確認できます。
関数とイベントフレームワークの相互作用は、直感的ではありません。通常の使用では、関数は呼び出されるのではなく、入力に対して最新でなくなったときに依存関係グラフによって実行され、下流の依存関係で使用できるように出力が JSON に変換されるためです。
トラブルシューティングには、次の手順を実行します。
関数が予期しない動作をする場合は、既存のベストプラクティスのドキュメントを確認して、依存関係グラフとイベントフレームワークにおける関数の役割を理解していることを確認してください。
イベントが [f_myFunction].run アクションを呼び出すパターンが必要になることは、非常にまれです。このパターンに依存しようとしているアプリケーションは、依存関係グラフの通常の解決処理を使用するようにリファクタリングする必要があります。関数を直接トリガーするのではなく、クエリをトリガーしたり、参照されている変数の値を設定したりして、上流の依存関係を更新します。
入力のない関数は、再計算イベントで再実行されません。Slate がすでにそのパラメーターの組み合わせに対する結果をキャッシュしている場合は、関数を再実行せずにその結果を返します。関数を一定の間隔で実行するには、タイマーで更新される変数やタイムスタンプなど、間隔ごとに変化する入力を1つ以上指定します。
マップウィジェットは、ポイントやジオメトリなど、適切に定義された geojson の地図フィーチャーの表示をサポートしています。これらは動的に生成したり、データベースから取得したりできますが、書式が固有のものであるため、手作業や新しいアルゴリズムで作成する場合は、適切な書式にするのが難しいことがあります。
トラブルシューティングには、次の手順を実行します。
「マップウィジェット内の GeoJSON」のリファレンス例を確認します。Foundry インスタンスで検索し、利用できない場合は Issue を登録してください。
[x] をオーバーライドするにはどうすればよいですか？Slate のすべてのスタイル設定は、最終的に CSS に変換されます。Chrome の Inspector ツール（右クリック > 任意の要素を検証）を使ってアプリケーションの任意の要素を調べ、その要素に適用されているクラスを確認し、ドキュメントの階層構造を把握できます。
トラブルシューティングには、次の手順を実行します。
スタイルに関するドキュメントのセクションを確認して、Slate でスタイルがどのように、どこで定義、適用、表示されるのかをより深く理解します。
一部の設定では、ウィジェットの幅と高さを「動的」に設定しようとすると、ページの読み込み時にウィジェットが小さなボックス内に表示されることがあります。[w_myWidget.resize] アクションを実行すると、ウィジェットが期待されるサイズで表示されます。
この動作は、ウィジェットのさまざまな要素の幅と高さをパーセント（通常は100%）で指定する CSS と、1個以上の親コンテナの Flex プロパティとの競合によって発生します。この競合により、Slate はレンダリング時にウィジェットを囲む要素の正しい寸法を特定できず、ウィジェットを小さすぎるサイズで表示します。
トラブルシューティングするには、次の手順を実行します。
ウィジェットの寸法をレスポンシブにする適切な実装方法は、親コンテナと子ウィジェットで Flex の設定のみを使用することです。CSS を使用して、ほかの width プロパティや height プロパティを手動で設定しないでください。解決するには、ルート直下の子ウィジェットから始めて、すべての親ウィジェットを順にたどり、位置や寸法を指定する CSS ルールを削除します。
margin プロパティと padding プロパティを使用して、子ウィジェットを内側に配置したり、位置を揃えたりできます。Flexbox の CSS ルールに慣れている場合は、Chrome Inspector を使用して対象となる要素とクラスを特定し、オーバーライドや追加の Flexbox ルールを指定することで、希望どおりの動作を実現できます。
Slate は迅速なアプリケーション開発に最適化されています。基盤となるフレームワークでは、レイアウトやスタイルの設定にほとんど制限がありません。そのため、Slate はすべてのアプリケーションを印刷媒体やエクスポートに適した形で一律にレンダリングすることはできません。アプリケーション開発者は、印刷に対応するためにアプリごとに時間をかける必要があります。
トラブルシューティングするには、次の手順を実行します。
最初に検討すべき最善の選択肢は、アプリを印刷する要件や要望がある理由を考えることです。ユーザーは単に、作成した表示を保存し、後で参照したり、プレゼンテーションで使用したりする方法を必要としているだけではないでしょうか？
その場合は、標準の共有可能なビュー機能の使用を検討してください。この機能は、すべてのウィジェットの選択内容と変数の状態を保持する一意の URL を生成します。ユーザーは、表示モードの操作ドロップダウンメニューからこの機能にアクセスできます。
どうしても印刷やエクスポートが必要な場合は、アプリケーションが適切にレンダリングされるように、メディア用の CSS スタイルを追加で定義する必要があります。
まず、少なくとも次の内容をグローバルスタイルに追加する必要があります。
@media print {
@page {
size: A4;
}
html, body , .ws-root-container.ws-sandbox {
height: 600mm !important;
}
sl-app-view-actions {
display: none !important;
}
}
レスポンシブなアプリケーションや、複雑なスタイルやレイアウトを持つアプリケーションを印刷することは非常に困難です。このような場合は、URL パラメーターを通じて必要な入力を受け取り、印刷に最適化された簡素な表示を生成する別のアプリケーションとして、「印刷用表示」を作成することを検討してください。開発コストと保守の負担は増えますが、満足のいく動作を実現できます。
すべての Web アプリケーションと同様に、Slate はエンドユーザーのコンピューター上のブラウザーリソースを使用して JavaScript コードを実行し、HTML で定義されたドキュメントモデル（DOM）を CSS で指定されたスタイルでレンダリングします。これらのリソースの一部は一定であり、Slate フレームワーク内で動作するためのオーバーヘッドにあたります。ただし、パフォーマンスが低下する場合、その根本原因はほとんどの場合、アプリケーションの過負荷です。アプリケーションの開発中に定義した設定が、アプリケーションのレンダリング、JavaScript の実行、あるいは多数の大規模なクエリの結果をメモリーに保持するだけの処理に対しても、ブラウザーに過剰なリソースを要求している状態です。
単一の関数やクエリが原因となる場合もあります。その場合は、アプリケーションの依存関係タブにあるパフォーマンスメトリクスを使用して、さまざまなクエリや関数の Time in Node を確認できます。このメトリクスは、ページの読み込み時にそのノードの解決にかかった時間を表しており、アプリケーションのボトルネックとなっている可能性のある箇所の特定に役立ちます。
一般的なベストプラクティスは、軽量で、対象範囲が明確な、単一の目的を持つアプリケーションを優先し、小さなアプリケーションをディープリンクで相互に接続した「クラスター」から、大規模なワークフローやアプリケーションを作成することです。
Slate はアプリケーションの設定を JSON ドキュメントとして保存します。このドキュメントには通常、UTF-8 でエンコードされた文字で2,000,000バイトのサイズ制限があります。設定がサイズ制限を超える Slate アプリケーションを保存しようとすると、保存に失敗します。サイズを減らすために、アプリケーションの設定を変更する必要があります。開いている Slate アプリケーションの JSON ドキュメントは、エクスポートによって取得できます。
Slate アプリケーションのすべての部分は、程度の差はあれ設定のサイズを増やすため、編集者は、作成する Slate アプリケーションの規模と、アプリケーションの設定に埋め込むリソースの両方に注意する必要があります。設定のサイズが過大になる主な原因と、提案する解決策は次のとおりです。
画像を Foundry にアップロードし、画像ウィジェットを使用して画像を参照します。
関数をリファクタリングして、共通のロジックを関数ライブラリに抽出することを検討してください。
また、大規模な関数は、Platform エディター経由で利用する Foundry Functions として実装する方が適している場合があります。
関数ライブラリは容量を節約するために Slate アプリケーションのすべてのページで共有されますが、JavaScript ライブラリは非常に大きくなることがあります。カスタムライブラリをリファクタリングして共通のロジックを使用するか、外部ライブラリの圧縮版を使用してください。