Google Developers Japan: Maps JavaScript API

React アプリケーション内での Maps JavaScript API の使用を効率化する

2025年2月3日月曜日

この記事は Google Maps Platform、デベロッパーリレーションズエンジニア Ken Nevarez とUbilabs、ソフトウェアエンジニアMartin Schuhfuss 氏による Google Maps Platform Blog の記事 "Streamline the use of the Maps JavaScript API within your React applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform と vis.gl チームによって開発された @vis.gl/react-google-maps ライブラリは、Google マップを React に統合するための強力で効率的な方法を提供し続けています。このライブラリは、React の宣言型という特性と Google マップの豊富な機能が魅力的な方法で組み合わされています。

デベロッパーにとっての主なメリット

React とのシームレスな統合: Google マップを完全に制御された React コンポーネントとして直接埋め込むため、React ワークフローとの十分な調和が確保されます。

拡張性: カスタムコンポーネントを活用し、React フックとコンテキストを使用して、ライブラリの機能を簡単に拡張できます。

vis.gl の強力な機能: 他の vis.gl ライブラリ（deck.gl など）と簡単に統合して、Google マップ上で直接、魅力的な 2D および 3D データ可視化を実現できます。

設計の移行: React の哲学を Maps JavaScript API に取り入れる

React と他のコンポーネントベースのアプローチに関する重要なポイントとして、宣言型 / リアクティブプログラミングと単方向データフローの 2 つの考え方があります。

React の宣言型スタイルで簡単な Google マップ実装を実行する TypeScript の例。

React では、アプリケーションのユーザーインターフェースとその複雑さおよび詳細すべてが、アプリケーションの状態を形成する一連の変数に基づいて完全に記述されます。この状態には、表示されているデータ（場所のリストなど）だけでなく、「この InfoWindow は現在開いているか？」や「マウスカーソルは現在これらの地点情報のいずれかに合わせられているか？」などの詳細も含まれます。これらの状態変数のいずれかが変更されるたびに、React は新しい状態に基づいて UI を更新します。

状態の変更は常に、コンポーネント階層を通じて下向きに伝播されます。たとえば、コンポーネント <PlacesList> は場所のリストを保存し、それらをフィルタリングして並べ替えてから、リスト内の単一の場所の表示を記述する複数の <Place> コンポーネントに渡します。この階層の下位にあるコンポーネントは、そのデータスライスにのみアクセスでき、データに関する変更が必要な場合にイベントをパブリッシュする必要があります（たとえば、場所の詳細のある地点に存在する [お気に入りに追加] ボタンをクリックするなど）。これは単方向データフローパターンとして知られています。データは常に下向きに流れ、イベントは常に上向きに流れます。

ユーザーインターフェースを構築するこの動的なアプローチは、大規模なアプリケーションにも非常にうまく適応します。そのため、一般的には再利用可能なコンポーネントと非常に堅牢なアプリケーションアーキテクチャが実現し、アプリケーションが大きくなってもメンテナンス性と開発者にとっての効率性は維持されます。表示全体を状態変数のみから引き出すと、状態のデータがどこかに保存されている場合にもかなり役立ちます。状態を復元すると、UI とその中にあるあらゆるものも復元されることが保証されます。これにより、元に戻す / やり直し機能、ページ再読み込み後の永続性、その他多くのユースケースを簡単に実装できるようになります。


命令型スタイルで簡単な Google マップ実装を実行する TypeScript の例。

Maps JavaScript API は、命令型 API と呼ばれる異なるアプローチを採用しています。このアプローチでは、開発者はオブジェクトを作成してメソッドを呼び出すことで API をより直接的に操作し、望ましい結果を記述するのではなく、API に何をすべきかを段階的かつ効果的に指示しています。

命令型アプローチと宣言型アプローチのこのギャップを埋めるため、@vis.gl/react-google-maps ライブラリには、React でマップの外観と動作を記述するために使用される <Map> や <AdvancedMarker> などの一連のコンポーネントが用意されています。この記述は命令型 Maps JavaScript API の対応する指示に変換されます。

これは、場合によっては単純です。<AdvancedMarker> コンポーネントが React のコンポーネントツリーに追加されると、ライブラリは内部で google.maps.AdvancedMarkerElement オブジェクトを作成し、それを <Map> コンポーネント用に作成されたマップインスタンスに追加します。このコンポーネントが後で階層から削除されたタイミングで、マーカーもマップから削除されます。

他のケース（たとえばマップ自体の場合）では、もう少し複雑になります。マップは通常、たとえば動画プレーヤーのように、ページ内の独立したコンポーネントとして機能しているため、マップコンテナ内で、マップは独自のイベント処理とユーザーインタラクションを定義し、Maps API のユーザーにはほとんど表示されない独自の状態変数セットを維持するようにします。

さらに、一般的なユースケースでは、マップとそのコンテンツが初期化され、ユーザーに表示された後は、マップ内で起きることをアプリケーションが制御する必要はありません。ほとんどの場合はこれで問題ありませんが、マップがアプリケーションにさらに深く統合されている場合もあります。その場合、マップのビューポートを制御するプロパティをアプリケーション状態から取得する必要があります。同時に、マップが通常どおりにユーザーインタラクションを処理することも引き続き許可します。

@vis.gl/react-google-maps ライブラリは、これら両方のユースケースに加えて他のユースケースにも対応します。なんらかのコンテンツを含むマップを表示するためだけにライブラリを使用した後、そこからすべてをマップに処理させることができますが、マップを完全に制御し、マップ自体のユーザーインタラクションの処理を無効にする程度にまで、マップに表示される内容を、アプリケーションに保存されている状態変数と常に完全に同期することもできます。

持続性を念頭に置いた構築: @vis.gl/react-google-maps の維持の背後にある哲学

初めて使用するユーザーは、@vis.gl/react-google-maps ライブラリでは選択できるコンポーネントがそれほど多くないことに気づくでしょう。これは意図的であり、このライブラリがオープンソースの世界で今後長期間にわたって拡大し、維持され続けるための計画の一部です。

まず、初期段階では、ライブラリが小さいほどメンテナンスが明らかに容易になります。よって、メンテナンス担当者は最も重要な機能を実装してから機能の拡張に取り組むことができます。ライブラリが小さいとバンドルも小さくなるため、すべてのユーザーにとってメリットがあります。しかし、これについてはもう一つ重要な点があります。このライブラリの目的は、明確に定義されたユースケース向けに固定されたコンポーネントコレクションを提供することではなく、あらゆる種類のユースケースをできるだけ簡単に構築するのに必要なフレームワークとツールを提供することです。

これは、新機能の実装方法として選択されたアプローチにも反映されています。つまり、新機能は、まずその使用方法を示すサンプルとして実装する必要があります。ライブラリを使用して機能を実装するのが難しいことに気づいた場合、それを利用して、改善点や低レベルの機能をライブラリに追加し、汎用性とデベロッパーエクスペリエンスを向上させることができます。また、再利用性を考慮して例を記述し、開発者がサンプルからコンポーネントをコピーしてアプリケーションで使用できるようにすることも目指しています。安定していて普遍的に有用であることが実証された機能は、後日ライブラリに追加することができます。

このような方法で機能を開発することで、以下の2 つのメリットをもたらします。まず、すべての新機能について、サンプル事例がドキュメントとして用意されています。また、同様のユースケースを持つすべての人がコードをコピーし、ニーズに合わせて変更できるように工夫されています。開発者はコードをコピーして必要に応じて調整することでコードの所有権を得るため、サンプルコードはバージョニングや互換性を損なう変更などの一般的な問題の制約を受けません。そのため、より自由に反復して、可能な限り最適な実装を見つけることができます。

オープンソースと OpenJS Foundation について

@vis.gl/react-google-maps はその登場以来、オープンソースの価値を擁護してきました。OpenJS Foundation の実績（Node.js、jQuery、vis.gl 自体など）に基づき、私たちはこのライブラリの管理を OpenJS Foundation に委託しました。その結果、ベストなアイデアが開花するコラボレーション環境が生まれ、ライブラリの品質と長寿命性が保証されています。

Google は、@vis.gl/react-google-maps が最新かつ堅牢な状態を維持できるよう引き続き尽力しています。ライブラリの原動力である vis.gl チームは、pull リクエストとリリースを積極的に管理しています。

使ってみる

@vis.gl/react-google-maps のバージョン 1.0 へのバージョンアップは重要なマイルストーンですが、エキサイティングな取り組みの始まりでもあります。このライブラリを実際にお試しいただき、その発展に貢献していただければ嬉しく思います。React でのマップ作成の未来を一緒に作っていきましょう。

インストールは、npm install @vis.gl/react-google-maps または yarn add @vis.gl/react-google-maps を実行するだけです。

プロダクトのドキュメントと例については、React Google Maps ウェブサイトをご覧ください。コードサンプルを含む構造化されたチュートリアルについては、Google Maps Platform デベロッパーサイトの Codelab をご覧ください。ぜひ @vis.gl/react-google-maps を使用した体験やサービスを共有してください。皆様がどのようなものを構築されるかとても楽しみにしております。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。

Posted by 丸山智康 (Tomoyasu Maruyama) - Developer Relations Engineer

Maps JavaScript API の読み込みの制御を強化する

2023年9月22日金曜日

この記事は Google Maps Platform Tech Lead, Maps JavaScript API Chris J. Shull による Google Cloud Blog の記事 "More Control Loading the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今回は、Maps JavaScript API の読み込み方法に関する 3 つの大きな改善点をご紹介します。3 つの改善点とは、柔軟なライブラリ読み込み用の API、新しいインラインブートストラップローダ、一連のパフォーマンスの向上です。

柔軟なライブラリの読み込み

Maps JavaScript API は、API を読み込むときに開発者が指定して追加できるライブラリで構成されています。これらのライブラリは、ウェブサイト上に地図を表示する以外のことも行います。たとえば、開発者は Places API にアクセスするために、プレイスライブラリを読み込むことができます。ただし、これらのライブラリの読み込みは柔軟性が低く、これまでは Maps JavaScript API の初期読み込み時にしか指定できなかったため（libraries=places URL パラメータを介するなど）、起動時の読み込みに時間がかかっていました。

そこで、今回、ライブラリを動的にインポートするための API を提供することになりました。たとえば、次のようなものです。

await google.maps.importLibrary("places");

このように定義することで、ユーザーが必要であると判断したときにプレイスライブラリが読み込みまれるように変更されます。たとえば、ユーザーのアクションの後に、場所に関する情報が必要になった場合です。さらに良いことに、以下のコマンドを介して google.maps.places.Place のような長い名前空間の使用を避けることもできるようになりました。

const {Place} = await google.maps.importLibrary("places");

ただし、google.maps.places 名前空間は引き続き設定されます。

また、複数のライブラリを並行してインポートできるようにもなりました。

const [placesLibrary, geocodingLibrary] = await Promise.all([

google.maps.importLibrary("places"),

google.maps.importLibrary("geocoding")

]);

さらに、ドキュメントに書かれている google.maps.importLibrary() を介して Maps JavaScript API のすべてのクラスを利用できるようにしました。たとえば、ユーザーは次のコマンドを介して StreetViewPanorama クラスにアクセスできます。

const {StreetViewPanorama} = await google.maps.importLibrary("streetView");

これで、Maps JavaScript API の依存関係を読み込むタイミングをより正確かつ効率的に制御できるようになります。

新しいインラインブートストラップローダ

もう一つの問題は、Maps JavaScript API <script> ローダを使用するには、グローバルに定義された関数に対するコールバックパラメータを定義しなければならないことです。現在、開発者の皆様には、API の読み込みを待たずにすぐに google.maps.importLibrary() を使用できる新しいインラインブートストラップローダの使用をおすすめしています。これにより、面倒なグローバルコールバックを回避し、Promises または async/await を使用して、Maps JavaScript API の準備が完了するタイミングを追跡することもできます。

URL で <script> タグを指定する代わりに、ほんの小さなインライン JavaScript である新しいインラインブートストラップローダを含めることができます。このコードは構成パラメータを受け取り、ブートストラップ URL を構築して、すぐに使用を開始できるように google.maps.importLibrary() を定義します。最初に google.maps.importLibrary() が呼び出されるまで、Maps JavaScript API のどの部分も読み込まれません。この新しいインラインブートストラップローダはページごとに複数回使用することもできます。なお、最初の構成のみが使用されます。また、新しいローダを使用すると、Maps JavaScript API の読み込み時に問題が発生した場合（古いコールバックメカニズムがではサポートしてされていなかったもの）、google.maps.importLibrary() Promise によって適切に拒否されます。

パフォーマンスの向上

今年は、エンドユーザーの読み込み時間を自動的に短縮できるように、Maps JavaScript API にもいくつかの変更を加えました。静的 JavaScript ファイルの Brotli 圧縮を有効にし、画面外のマップに対して自動遅延読み込みを導入しました。また、今年の後半には、より新しいコードの出力ができるように JavaScript をアップグレードし、より多くのブラウザの組み込み機能を利用してファイルサイズを削減する予定です。

Maps JavaScript API が <script> ローダを使用する理由

多くの開発者から、なぜ npm 経由で配布しないのかと質問されることがあります。Google は API にアクセスするためのオプションを定期的に評価しており、ほとんどの JS パッケージが npm 経由で配布されている世界では <script> タグが時代遅れに見える可能性があることを十分に認識しています。

Google が得た重要なインサイトに、Maps JavaScript API を採用している多くのウェブサイト（大小問わず）は積極的にメンテナンスされていないというものがあり、Google はこうしたウェブサイトの機能を維持できるようにできる限りのことを行いたいと考えています。UI レンダリングを構成するコードはかなり複雑で、内部で多数のバックエンドサービスを利用します。長年にわたってブラウザやバックエンドサービスに無数の変更が加えられたため、正しい動作を続けるためには、Maps JavaScript API の内部動作を更新する必要がありました。アクセシビリティ、プライバシー、セキュリティに関する重要な更新もありました。また、各ウェブサイトは API を Google から直接読み込むため、こうした更新をすべて自動的に取得できています。積極的に管理されているウェブサイトであっても、Maps JavaScript API を使用する価値の一つは、この種の変更によって引き起こされる予期せぬ破損の多く（およびその結果として生じる、修正を見つけてデプロイするというストレスのかかる作業）を回避できることです。これは、依存関係の管理に取り組む代わりに、自分自身の目標に集中してより多くの時間を費やすことができることを意味します。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山智康 (Tomoyasu Maruyama) - Developer Relations Engineer

Maps JavaScript API のユーザー補助機能に関する最新情報

2022年7月7日木曜日

この記事は Maps JavaScript API 担当ソフトウェアエンジニア Aleh Medzviadziuk による Google Cloud Blog の記事 "The latest accessibility updates in the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先月グローバルアクセシビリティアウェアネスデーを迎えたことにちなみ、昨年の取り組みからの進捗状況と、Maps JavaScript API と Maps Embed API のユーザー補助機能の向上に関する最近の更新情報についてお知らせします。

Google Cloud は昨年より Embed API の根本的な改善に焦点を絞り、「タブ」の順序、キーボードとスクリーンリーダーのインタラクティブな機能、ユーザー補助ラベルの追加、各種マップコントロールのカラーコントラストの強調といった改善に取り組んできました。このような改善により、目の不自由な方に加え、スクリーンリーダーやキーボードナビゲーションを使うすべての方に、よりインクルーシブなマップをご利用いただけるようになります。この記事では、これまでに実現できた改善点の詳細をいくつかご紹介します。

タブが左から右、上から下の順に並べられ、スペースバーでボタンをアクティブにして選択でき、色のコントラストが上がって視認性が増しています。

ハイコントラストモードでの UI 表示

ハイコントラストモードのマップも改善し、一部のボタンとチェックボックスを見やすく、認識しやすくしました。このために、マップがハイコントラストの設定に合うようにコードベースの CSS に変更を加えました。

ハイコントラストモードでもボタンとチェックボックスの視認性が保たれます。

情報ウィンドウの改善

また、マップで特に使用される UI コンポーネントである情報ウィンドウ（InfoWindow）のさらなる改善にも引き続き取り組みました。デベロッパーはユーザー補助ラベルを指定して、情報ウィンドウが表示されているときにフォーカスするようプログラムで設定できるようになりました。

const infoWindow = new google.maps.InfoWindow({

ariaLabel: 'Hello Accessibility',

content: '<h2>Hello Accessibility!</h2>',

});

infoWindow.addListener('visible', () => {

infoWindow.focus();

});

infoWindow.open({

anchor: marker,

shouldFocus: false,

});

情報ウィンドウにユーザー補助ラベルを指定して、情報ウィンドウが表示されているときにフォーカスするようにプログラムで設定できます。

スクリーンリーダーとマーカーの連携

最後に、キーボードでのマーカー操作を支援するためにスクリーンリーダー向けの使用手順を追加しました。この機能は、初めて利用するユーザーで、キーボードを使ってインタラクティブなマーカー（登録したクリックイベントリスナーがある場合）を移動する方法についてご存知ない方に特に便利です。マーカーをより使いやすくする方法について詳しくは、「マーカーをアクセス可能にする」ガイドと「マーカーのユーザー補助機能」コードサンプルをご覧ください。


	キーボードでのマーカー操作を支援する、スクリーンリーダーの使用手順。

ユーザー補助機能の改善にご協力ください

新たに改善した機能をお試しいただき、変更点に関するフィードバックや新しいバグの報告にご協力いただけますと幸いです。それらを参考にして、最も影響が大きい領域に優先して対応してまいります。皆様のウェブサイトに影響する既存のバグに [+1] で投票するか、新しいバグレポートを提出してください。

ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。Maps JavaScript API と Maps Embed API のユーザー補助機能や改善点の最新情報もご確認ください。

今後導入予定の機能

ウェブでは毎日、世界中の何百万人ものユーザーが Maps JavaScript API によって提供される Google マップの基本地図を利用しています。Google の目標は、多くのユーザーに受け入れられる主題図を容易に作成するために必要となるツールをデベロッパーに提供することです。

Google Maps Platform チームは、Maps JavaScript と Maps Embed の UI と API のユーザー補助機能の向上に向けて、まだまだできることがあると認識しています。詳細については、Maps JavaScript API と Maps Embed API の更新状況は、リリースノートページでご確認ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山智康 (Tomoyasu Maruyama) - Developer Relations Engineer

クラウドベースのマップスタイル設定に追加された新機能によりオプションの幅が広がり、制御性、柔軟性、ユーザーエクスペリエンスが向上

2021年8月25日水曜日

この記事は Google マップ、Google Maps Platform プロダクトマネージャー Alicia Sullivan による Google Cloud Blog の記事 " New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディングフットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。ランドマークの表示によりすばやく現在地を把握することが可能にウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ（左）とローマ（右）のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイルエディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。

ビルディングフットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイルエディタのオプションとしてビルディングフットプリント機能を追加しました。ビルディングフットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディングフットプリント

ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディングフットプリントを有効にするには、スタイルエディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。

スタイルエディタのメニューで [Landscape] から [Human-made] を選択し、ビルディングフットプリントを有効にした地図。

業界別に最適化された地図のスタイルでは、ランドマークとビルディングフットプリントに加えて詳細なストリートマップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディングフットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイルエディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリートマップが利用可能になります。この機能は、2020 年 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリートマップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。

詳細なストリートマップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリートマップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディングフットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディングフットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

丸山智康 (Tomoyasu Maruyama) - Developer Relations Engineer

Google Maps Platform の JavaScript API と Promise

2021年7月5日月曜日

この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Google Maps Platform JavaScript API and Promises" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
四半期毎のリリースで更新された Maps JavaScript API のバージョン 3.45 並びに、Weekly リリースの最新バージョンにおいても、非同期メソッドの既存のコールバックパターンに加えて、Promise もサポートされるようになりました。Promise は便利な構文による複雑さの軽減や深く入れ子になったコールバックの排除など、多くの利点をもたらします。今回の Promise の追加は、TypeScript のサポートや Maps JavaScript API の動的な読み込みといった、Maps JavaScript API で最新の JavaScript プログラミング手法やパターンをサポートするうえでの、大きな取り組みの一環となります。

以下の例で示すように、Promise の便利な機能の一つである、async / await を使用することができます。この機能を利用すると、API 呼び出しが成功せず、Promise が拒否された場合に例外が発生します。

const app = async () => {

const elevationService = google.maps.ElevationService();

const locations = [{lat: 27.986065, lng:86.922623}];

const response = await

elevationService.getElevationForLocation({locations});

console.log(response.results);

};

app();

次のパターンは、Promise オブジェクトの then、catch、finally メソッドを使用するもので、エラー処理を改善します。ここでは、catch メソッドが明示されていて、catch なしで Promise が拒否された場合には、未処理の promise 拒否イベントがグローバルスコープに送信されます。

const elevationService = google.maps.ElevationService();

const locations = [{lat: 27.986065, lng:86.922623}];

const promise =

elevationService.getElevationForLocation({locations});

promise

.then((response) => {

console.log(response.results);

})

.catch((error) => {

console.log(error);

});

.finally(() => {

console.log('done');

});

最後に、以下の例は、既存のコールバックパターンの使用法を示しています。今後、新しい非同期メソッドは Promise のみをサポートする可能性がありますが、コールバックは引き続きサポートされる予定です。

const elevationService = google.maps.ElevationService();

const locations = [{lat: 27.986065, lng:86.922623}];

const callback = (results, status) => {

if (status === 'OK') {

console.log(results);

} else {

// このケースを処理する

}

};

elevationService.getElevationForLocation({locations},

callback);

Promise をサポートしている機能の一覧については、Maps JavaScript API の Promise のドキュメントをご覧ください。こちらの内容は、今後の機能拡張に合わせて更新されますので、定期的に確認することをおすすめします。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山智康 (Tomoyasu Maruyama) - Developer Relations Engineer

Maps JavaScript API のユーザー補助機能の向上

2021年6月28日月曜日

この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Improved accessibility in the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Maps Platform JavaScript チームが行っている、Maps JavaScript API のユーザー補助機能の改善に重点を置いた最近の機能変更をいくつかご紹介します。当チームは 2020 年に、すぐに使えるユーザー補助機能と、デベロッパーがユーザー補助エクスペリエンスを作成するために利用できるフックを増やす新たな取り組みを開始しました。Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。お客様にはこうした新機能を毎週の最新バージョンでお試しいただき、変更点に関するフィードバックの提供と新しいバグの報告にご協力いただけますと幸いです。それらを参考に、最も影響の大きい領域に優先順位を付けさせていただきます。みなさんのウェブサイトに影響を与える既存のバグに +1 し、新しいバグレポートをご提出ください。ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。
2020 年最初の機能変更は、特に根本的な問題に焦点を絞っていました。タブの順序の最適化、キーボードの有効化とスクリーンリーダーの対話的な機能、スクリーンリーダーに関する説明の追加、各マップコントロールのカラーコントラストの強調を図りました。機能変更の前後での違いをご覧ください。

タブの順序は標準的ではなく、スペースバーでボタンがアクティブになりませんでした。

タブの順序は左から右、上から下に並べられ、スペースバーでボタンがアクティブになり選択でき、色のコントラストが上がって視認性が増しています。

また、デベロッパーがマップに追加するマーカーについても詳しく調べました。マーカーは、img ロールか、インタラクティブな場合（クリックイベントリスナーが登録されている場合など）は button ロールにデフォルト設定されました。インタラクティブなマーカーもキーボードで矢印キーを繰り返し押して操作できます。デベロッパーがマーカーにタイトルを指定すると、このテキストはユーザー補助ラベルにも使用されます。こうした改善は最適化されていないマーカーにのみ適用されm。詳細については、新しい「マーカーを利用可能にする（Make a marker accessible）」ガイドと「マーカーのユーザー補助機能（Marker Accessibility）」コードサンプルをご覧ください。

ユーザー補助のラベルとロールが適用された、キーボードの矢印キーで操作できるマーカー。

マップで特に使用される UI コンポーネントは InfoWindow です。改善点の中で特筆すべきなのは、InfoWindow が開いたり閉じたりした際に、InfoWindow から出入りするタブ選択を自動的に管理する機能です。デフォルトではこれまで多くのユーザーから寄せられたフィードバックを元に、open() が自動的にフォーカスを移動するかどうかを決定します。デベロッパーの皆様は、InfoWindow を開く際に shouldFocus オプションを使用して明示的に選択することをおすすめします。

const infoWindow = new google.maps.InfoWindow({

content: "Hello Accessibility!",

});

infoWindow.open({

anchor: marker,

shouldFocus: true,

});

InfoWindow を開くと、最初のフォーカス可能な要素（デベロッパー指定のコンテンツか、組み込みの閉じるボタン）が開きます。閉じると、フォーカスが復元されます。

Maps JavaScript API は 2005 年以降、パンやズームなどのマップ操作のキーボードコントロールをサポートしていますが、ユーザーがキーボードショートカットを見つけるのは困難でした。今月、UI に新しいキーボードショートカットのダイアログを追加し、使用できるショートカットをユーザーが見つけやすくしました。こうしたキーボードショートカットは、マップ自体にフォーカスがあるときに有効になります。