Closed h-yoshikawa44 closed 2 years ago
位置情報に関しては、navigator.geolocation から取得できる。getCurrentPosition にコールバックを渡す感じらしい。
SWR を使った例ではあるが、ほぼやりたいことと同じ実装の記事を見つけたので、参考にしてみる。
位置情報が必要になる関係上、データ取得はクライアントサイドでやる。
このフックに関しては React Query は使わず、useEffect で初期化処理を書く。 useState で現在のロケーション情報を保持するイメージ。
まず位置情報の緯度経度からロケーションを検索(Location Search API・~キャッシュキー:'location'~)。 レスポンスの配列のうち最初のものが一番近いロケーションになるので、そのロケーション情報(title と woeId)を保持する。 もし位置情報アクセス不許可の場合は、東京をデフォルトにする。
また、後にメニューを実装する際にロケーション選択をできるようにするので、ロケーション選択関数も用意しておく。
現在のロケーション情報があることを条件として、保持したロケーション情報の woeId を使用して、そのロケーションの天気予報情報を取得(Location API・キャッシュキー:['weather', woeId]) 取得した天気予報情報を使って、UI を構築。
データがない(初期取得中)時に各値は-
にしておくかな。(+画面全体の読み込み中 UI を作るので、表示されることはないかも)
また、今回使用する API はフロント側でアクセスすると CORS ポリシーに引っ掛かるので、API ルートでラッパーを作る必要がありそう。
↓ 2022/01/23 散々悩んだ結果、React Query は除去することにした。
API リクエストを兼ねる処理のうち、 位置情報取得→ロケーション情報の処理を React Query なしに実装していて、 天気予報情報取得は React Query を使う実装をしていて。 2つのやり方が混在するのが気持ち悪かったので、React Query なしで useEffect で対応するやり方に統一する方向に。
この記事を前に見たことあって、useQuery はフェッチャーの指定がなくても使えるらしい。 (デフォルトフェッチャの存在があるから、必須でなくなってる?) 前に共通エラー用のキャッシュ作りたい時があって、その時は無理やりやってたのが少しスマートに書けるかも。
↓ 今回は採用しないことにした。
左側のボタンはメニューを開くものだとわかるが、右側のボタンが何のボタンなのかわからない。 もしかしたら、初期読み込み時のロケーションは完全に固定で、このボタンを押すことで初めて今の場所に近いロケーションを取得する想定なのかもしれない。 そうする方が、初期読み込み時に位置情報取得処理がすっとばせるのでページ表示までは早くなる。
ただ、一般的な天気予報アプリはアクセス時に自動的に近いロケーションを取得したうえで、そのロケーションの天気予報 を表示するイメージ。 今回もそうするつもりなので、別になくてもいいかも。
↓ 今回は、ボタンで手動実行もできるようにした。
作業内容