背景
#6002 で追加された sids ベースのディープリンクでは、stations(ids: [Int!]!) で取得した各駅をそのまま stationState.stations に投入する。各駅は GraphQL レスポンスとして stopCondition を持つが、これは「その路線における各駅のデフォルト停車条件」であって、ユーザーが共有したい列車種別(特急・快速など)に応じた停車パターンを再現できない 。
結果、sids で復元した経路では列挙された全駅が「停車」として扱われ、たとえば「新宿 → 池袋 → 渋谷」のように快速通過駅を含む経路を共有しても、受信側ではすべて停車駅として表示されてしまう。
#6002 提案には「(隣接関係が成立しない区間が混ざっていても先頭駅で表示は開く/経路の途切れはアプリ内のUIで分かるようにする/このissueの範囲外)」とあり、停車・通過の表現も同じく後続課題として残されている。
現状の制約
sids には駅 ID のみが入る
各 Station 行は stopCondition (All / Holiday / Not / Partial / PartialStop / Weekday) を持つが、これは線区のマスタ情報。実際の列車種別による停車パターンは表現できない
useDeepLink.openRouteByStationIds は取得した駅をそのまま stationState.stations に投入するだけで、停車情報の上書きを行わない
提案
sids と並列で停車情報を表現する新パラメータを追加する。リンクの可読性と URL 長を抑えるため、以下の 2 案を提示する。
案 A(推奨): 通過駅をインデックスで指定 skips
sids の 0-origin インデックスで「通過扱いにする駅」を列挙する。
TrainLCD://route?sids=1131211,1131310,2800217,2800218&dir=0&skips=1,2
上の例では sids[1] と sids[2] を通過扱い、それ以外は停車扱い
省略時はすべて停車扱い(後方互換: ディープリンクで他路線直通・経路全体を表現できるようにする #6002 と同じ挙動)
値は整数の昇順カンマ区切り、範囲外・重複・非整数は リンク全体を no-op
インデックスが指す Station について stationState.stations[idx].stopCondition を StopCondition.Not に上書きする
メリット
通過駅が少ない典型ケース (各駅停車・快速など) で URL が短くて済む
デフォルトが「全駅停車」で sids 既存挙動と整合する
視認性が高い
デメリット
案 B: 停車マスク stops
sids と同じ長さの 0 / 1 文字列で各駅の停車有無を表す。
TrainLCD://route?sids=1131211,1131310,2800217,2800218&dir=0&stops=1001
1 = 停車、0 = 通過
stops.length !== sids.length の場合は リンク全体を no-op
省略時はすべて停車扱い
メリット
各駅と 1 対 1 で対応するため sids との不整合を検知しやすい
駅数が増えても URL 長は線形
デメリット
駅数が少ないと冗長
パースエラーが起きやすい (桁ズレに気付きにくい)
案 C(将来拡張): 細かい stopCondition を表現
Holiday / Partial / Weekday などの複合条件を含めたい場合は、A・B の延長で「通過=0、平日のみ停車=2、休日のみ停車=3…」のような数値コードを使うか、別仕様(JSON エンコード等)に切り替える。本 issue では一旦 停車 / 通過の 2 値 に限定し、複合条件は別 issue として切り出す。
受け入れ条件
関連
背景
#6002 で追加された
sidsベースのディープリンクでは、stations(ids: [Int!]!)で取得した各駅をそのままstationState.stationsに投入する。各駅は GraphQL レスポンスとしてstopConditionを持つが、これは「その路線における各駅のデフォルト停車条件」であって、ユーザーが共有したい列車種別(特急・快速など)に応じた停車パターンを再現できない。結果、
sidsで復元した経路では列挙された全駅が「停車」として扱われ、たとえば「新宿 → 池袋 → 渋谷」のように快速通過駅を含む経路を共有しても、受信側ではすべて停車駅として表示されてしまう。#6002 提案には「(隣接関係が成立しない区間が混ざっていても先頭駅で表示は開く/経路の途切れはアプリ内のUIで分かるようにする/このissueの範囲外)」とあり、停車・通過の表現も同じく後続課題として残されている。
現状の制約
sidsには駅 ID のみが入るstopCondition(All/Holiday/Not/Partial/PartialStop/Weekday) を持つが、これは線区のマスタ情報。実際の列車種別による停車パターンは表現できないuseDeepLink.openRouteByStationIdsは取得した駅をそのままstationState.stationsに投入するだけで、停車情報の上書きを行わない提案
sidsと並列で停車情報を表現する新パラメータを追加する。リンクの可読性と URL 長を抑えるため、以下の 2 案を提示する。案 A(推奨): 通過駅をインデックスで指定
skipssidsの 0-origin インデックスで「通過扱いにする駅」を列挙する。sids[1]とsids[2]を通過扱い、それ以外は停車扱いstationState.stations[idx].stopConditionをStopCondition.Notに上書きするメリット
sids既存挙動と整合するデメリット
skipsが膨らむ案 B: 停車マスク
stopssidsと同じ長さの0/1文字列で各駅の停車有無を表す。1= 停車、0= 通過stops.length !== sids.lengthの場合は リンク全体を no-opメリット
sidsとの不整合を検知しやすいデメリット
案 C(将来拡張): 細かい
stopConditionを表現Holiday/Partial/Weekdayなどの複合条件を含めたい場合は、A・B の延長で「通過=0、平日のみ停車=2、休日のみ停車=3…」のような数値コードを使うか、別仕様(JSON エンコード等)に切り替える。本 issue では一旦 停車 / 通過の 2 値 に限定し、複合条件は別 issue として切り出す。受け入れ条件
sidsと併用したリンクで通過駅がStopCondition.Notに上書きされるsgid/lid/dir) のリンクは動作変化なし関連