こんにちは、フロントエンドチームの @syo_igarashi です。
今週のフロントエンド定例の内容を記載します。
フロントエンド定例について、以前の記事（ランサーズのフロントエンドチームが取り組んでいること）でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。
以下、今週の内容です。
自分なりにUserAgentの扱いを今後を見据えて対応を考える
前提としてUserAgentとは
以下はMDNより引用
User-Agent リクエストヘッダー は、サーバーやネットワークピアがアプリケーション、オペレーティングシステム、ベンダーや、リクエストしているユーザーエージェント のバージョン等を識別できるようにする特性文字列です。
警告として
警告: ブラウザーによって異なるウェブページやサービスを提供することが、通常は悪い考えである理由については、ユーザーエージェント文字列を用いたブラウザーの判定 をお読みください。
ともありUser Agentを元にUIを変えることは実際よくないとも言われている
とはいえ、モバイルのアプリリンクを表示したい際などでUser Agentで識別されることが多い
Navigator.userAgent – Web API | MDN
JavaScriptではよくNavigator.userAgentで判定することが多いが、非推奨になる予定もありGoogle ChromeではUser-Agent Client Hints APIを使うべきではと話が進んでいる？がまだ他のブラウザでは対応していないため、User-Agent Client Hints APIで値が取れないブラウザではNavigator.userAgentで判定するようになるというのが現状で良い対応だと思う。
User-Agent Client Hints APIでmobileがtrueならほぼAndroidのChrome、User-Agent Client Hints APIの値がなくてNavigator.userAgentの中身を見た結果iPhone, iPad, macosかなんか識別する文字列かつmedia queryの画面サイズ的にはmobileのサイズなら多分iOSなんだなというような表示条件でいいと思う
ユーザーエージェントクライアントヒント API – Web API | MDN
またPHPなどのサーバ側でも$_SERVER[‘HTTP_USER_AGENT’]という変数でUserAgentを取得可能であるが今後を考えるとUserAgentをリクエストのデータとして送られるのかはわかっておらず、予定では$_SERVERに
- HTTP_SEC_CH_UA
- HTTP_SEC_CH_UA_MOBILE
- HTTP_SEC_CH_UA_PLATFORM
が追加される想定らしいが本当にブラウザ側がこのデータをリクエストしてくれるかというと別な気もするのでUserAgentの判定はサーバでするよりもよりブラウザ挙動に近いフロントで動いているJavaScriptでするべきなのでは？というのを薄々思ってたりする。
前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います。
