Repository navigation
Widgets: weather and location from the profile coordinates #119
Description
Live verification (2026-09-15)
GET /api/weather -> 400 {"error":"Latitude and longitude are required","code":"bad_request"}
GET /api/location -> 400 {"error":"Latitude and longitude are required","code":"bad_request"}
Both are bearer-reachable and simply need coordinates.
Source of coordinates
GET /api/user returns latitude/longitude — the profile location (see the Settings epic). The app must not attempt OS geolocation; the web's browser-permission flow has no desktop equivalent, and the documented fallback is a stored profile location.
Documented behaviour (/help/settings)
A Location widget (city, state, timezone) and a Weather widget (current conditions, high/low). Weather comes from the U.S. National Weather Service (api.weather.gov) and is cached server-side for 30 minutes — so the client should not poll aggressively.
Acceptance criteria
- Both service methods take lat/long from
CurrentUser. - With no profile location set, the widgets prompt to set one in Settings instead of showing an error.
- Refresh no more often than the 30-minute server cache warrants.
- Depends on the profile-location work in the Settings epic.
Activity
Adron commentedon Sep 16, 2026
Implemented in #156 — work continues in the PR from here. (#156 is stacked on #153 /
issue-118-widgets, which carries the widget-rail machinery these two cards reuse.)Both service methods take the coordinates as explicit parameters rather than reaching into
CurrentUser, so this landed without waiting on PR #131 —ProfileLocationProviderreadslatitude/longitudeoff the rawGET /api/userenvelope and shares one cached lookup with the transit and bike-share cards. No OS geolocation, per the product docs; with no profile location both cards point at Settings instead of erroring.The notable live finding: both endpoints are United States only, not Seattle-gated. Seattle, NYC, Chicago, Anchorage and Honolulu all returned 200, while Toronto, Tokyo,
0,0and out-of-range coordinates returned404 "Failed to fetch weather/location data"— the National Weather Service's coverage showing through the proxy, so 404 is caught specifically and shown as an empty state. Also worth keeping: the parameters are the long spellingslatitude/longitude, unlike bike-share'slat/lon;humiditywas null in all seven responses across five cities; and the weather card's cache window is exactly the documented 30 minutes, with refresh deliberately not sendingrefresh=true.