ArcGIS Maps SDK for JavaScript にて長らく使用されてきたウィジェットの機能は 2026 年の第1四半期に非推奨となり、2027 年の第1四半期に廃止される予定となっております。現在ウィジェットの機能を使用している方は、SDK をバージョン アップする際に、ウィジェットの廃止に伴い新しく登場したコンポーネントへの移行が必要となります。本記事では、ウィジェットからコンポーネントへの移行に関する内容について、米国 Esri 社より投稿された「JavaScript Maps SDK: A full transition to components」の記事を翻訳してご紹介します。
Esri は、ArcGIS Maps SDK for JavaScript のコア API を再利用可能なカスタム HTML 要素(例:<arcgis-map></arcgis-map>)に拡張する、標準ベースの の構築に完全にコミットしています。これは、ArcGIS 製品の内部開発、および ArcGIS Maps SDK for JavaScript の一部として提供されるの両方に適用されます。実際、すべてのコア ウィジェット機能はすでにコンポーネントとして利用可能です。これから SDK を使用して Web アプリを構築するための推奨アプローチは、コンポーネントを使用することです。
このアーキテクチャーの転換は、フロントエンド Web 開発の生産性を最大化します。カスタム要素は、馴染みのある(HTML、CSS、JS)プログラミング体験を提供し、アプリケーション フレームワークとのシームレスな統合を可能にします。内部的なコンポーネントは Calcite Design System のコンポーネントを使用して構築されているため、Calcite のデザイン トークン(CSS 経由)を使用してスタイルを設定できます。さらに、Esri 製品で ArcGIS のエクスペリエンスを Web コンポーネントとしてカプセル化しているため、実証済みのワークフローを SDK の構成可能なコンポーネント(すでにリリースされている Charts コンポーネントなど)として提供できます。SDK の高レベル コンポーネントのコレクションは、時間とともに成長し続けます。
SDK が最初に作成されたとき、Web コンポーネントの標準はまだ成熟しておらず、多くのブラウザーに対応していませんでした。同時に、JS の状況は常に変化するため、特定の JS フレームワークにコミットしませんでした。そのため、ウィジェット アーキテクチャーを開発し、時間をかけて開発者が Web アプリで使用できる 60 以上のウィジェットを作成しました。現在、Web コンポーネントの標準がすべての主要なブラウザーでサポートされているため、SDK の多くの内部機能と同様に、ブラウザーとともに技術を進化させることができます。
最初は、ウィジェットが Web コンポーネントとしてラップされており、時間とともに、レガシー ウィジェット アーキテクチャーの削除を含む最適化された構造でコンポーネント内部が再実装されていきます。この移行を完了したコンポーネントのリストを見るには、リリース ノートを参照してください。コンポーネントの再実装が完了したら、スロットのサポートを追加します。これにより、カスタム コントロールや機能をコンポーネント エクスペリエンス内に統合できるようになります。スロットが SDK のコンポーネントで最終的にどのように機能するかを知りたい場合は、Calcite Design System をチェックしてください。ほとんどの Calcite コンポーネントにはが含まれています。
SDK の多くのリソースはすでにコンポーネント ベースです。これには、入門ガイド、プログラミング パターン/ベスト プラクティス、チュートリアル、サンプルのコレクション、コンポーネント プレイグラウンドと API リファレンスの統合などの新しいおよび更新されたリソースが含まれます。ただし、SDK の Web サイトには 8 年間取り組んできたリソースが含まれているため、完全な移行には複数のリリースが必要です。移行中は、推奨されるコーディング パターン(コンポーネント ベースではない)をまだ反映していないサンプルやコード スニペットが Web サイト全体に表示されます。すべてのリリースで目に見える進歩が期待できます。
最終的に、すべてのウィジェットは非推奨となり、後に削除されます。したがって、開発者はウィジェットや MapView/SceneView の代わりにコンポーネントを使用するように UI コードを移行することを強く推奨されます。コンポーネント ベースの UI への移行に必要な労力は、アプリケーションによって大きく異なります。場合によっては非常に迅速に行うことができますが、その他の場合にはかなりの労力が必要で、計画と優先順位付けが必要です。多くの Esri 製品チームも同様の移行作業を行います。ウィジェットのロードマップには、この必要な労力とコンポーネント開発のロードマップが考慮されています。コンポーネントへの完全な移行のために、次のマイルストーンを目指しています。
UI 要素のプレゼンテーションがウィジェットからコンポーネントに移行される間、(現在はビュー モデルを介して利用可能な)基礎となるビジネス ロジックは引き続き利用可能です。つまり、SDK のビジネス ロジックを使用して、カスタム エクスペリエンスとワークフローを今後も構築できるようになります。ただし、SDK を最新化し継続的に改善するために、ビジネス ロジックをどのように使用しているかを把握し、長期的なロードマップの参考にすることが重要です。たとえば、開発者がビュー モデルを使用する一般的な動機には、Esri が SDK のコンポーネントにオプションを追加することでより簡単に解決できるものがあります。
ビュー モデルは完全なカスタム ワークフローを実装するために使用される場合があります。 一般的な例は、ワークフローのある側面に必要なマップ上でのインタラクティブな描画を処理するために使用される SketchViewModel です。この場合、今後のパターンはカスタム ワークフローのために SDK のビジネス ロジックに依存し続けます。
コンポーネントを使用してアプリを構築する方法を学ぶためのリソースはたくさんあります。以下のドキュメントも併せてご確認ください。