LF-5298: Show a 5-day weather forecast with frost-risk warnings on the Home page by litefarm-pr-bot · Pull Request #4178 · LiteFarmOrg/LiteFarm

litefarm-pr-bot · 2026-05-21T19:41:51Z

Description

Implement the Home page weather widget.

Update the weather API
WeatherForecast container (container) — API call, state, data formatting (utils.ts)
PureWeatherForecast (stories)
- DayPillRow (stories)
- FrostBanner (stories)
- WeatherDetail (stories)
TimeStrip (reusable) (stories)

Data Flow

API returns flat list of slots: { slots: [{ dt, temp, ... }], city: { timezone... } }
Frontend groups slots into days (for the day pill selection):
{ localYmd: "2026-05-27", slotIndices: [0..7], isFrost: false }
Selecting a day passes only that day's slots to TimeStrip with relative indices
e.g. day "2026-05-28" → slots[8..15], selectedSlotIndex 8 → relative index 0

Original description by Claude

The Home page weather widget has been a single-snapshot read of OpenWeather's current-conditions endpoint since the original implementation, and the design system has since moved on to a 5-day forecast model that includes frost-risk surfacing. The legacy code coupled the displayed measurement system (metric/imperial) into the OpenWeather request itself, which forced the frost threshold to be expressed twice (once for each unit) and prevented a single, authoritative metric trigger. The widget also derived all date labels from the browser timezone, so a farm in India viewed from a North-American browser saw days mislabelled.

This change replaces the legacy WeatherBoard with a new WeatherForecast widget under containers/WeatherForecast/ (smart, RTK-Query backed) and components/WeatherForecast/ (presentational, composed of DayPillRow, FrostBanner, DayWeatherSummary, TimeStrip, and a PureWeatherForecast shell). The backend endpoint constant moves from /data/2.5/weather to /data/2.5/forecast, the request hard-codes units=metric, and the controller stops reading row.units.measurement. The frontend converts to display units client-side via pure helpers in containers/WeatherForecast/selectors.ts. The WeatherData shared type is replaced by WeatherForecast (with slots[] and city.timezoneOffsetSeconds), and the RTK Query endpoint is renamed useGetWeatherQuery → useGetWeatherForecastQuery. Day grouping, day-pill labels and time-chip labels use the offset returned by OpenWeather (city.timezone), never the browser timezone.

Pattern to carry forward: when a backend response shape changes in a way that affects an RTK Query hook's name or argument, the breaking edit and every consumer must ship together — the previous one-call API made it tempting to split the rewrite across PRs, but the type rename and Home wiring are inseparable in practice and would leave the legacy widget broken in an interim merge.

Jira: https://lite-farm.atlassian.net/browse/LF-5298

How Has This Been Tested?

Passes test case
UI components visually reviewed on desktop view
UI components visually reviewed on mobile view
Other (please explain)

Type checking (tsc --noEmit) and ESLint were run against the worktree; both reported only pre-existing errors in unrelated files (e.g. stories/Pages/Intro/SetCertificationSummary/CertificationSummary.test.js, stories/Tile/SensorKPITiles.stories.tsx). No new errors were introduced. A non-printable-byte scan (LC_ALL=C perl -ne ...) confirmed all new files contain only the precomposed U+00B0 DEGREE SIGN for the °C/°F glyphs, with no combining diacritics or NUL bytes. No local frontend or backend was started; visual review on Home and Storybook, golden-path slot navigation, balloon-tail anchoring on day-pill rollover, mobile (320–375px) horizontal time-strip overflow, metric-to-imperial unit switching, and locale switching (Hindi, Punjabi) for date string localisation are deferred to manual QA.

Type of change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

Checklist:

I have commented my code, particularly in hard-to-understand areas
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
The precommit and linting ran successfully
I have added or updated language tags for text that's part of the UI
I have ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
I have added the GNU General Public License to all new files

Swap the legacy WeatherBoard for a new WeatherForecast widget driven by OpenWeather's /data/2.5/forecast endpoint. The widget shows a 5-day / 3-hour forecast with five day pills, a horizontal time strip of 3-hour slots, a shared rollover selection (one slot index drives a derived day pill highlight), and a red frost-risk banner whenever the day's minimum forecast temperature is below 2°C. Backend always requests metric units; the frontend converts on display using the farm's measurement setting. All local-day grouping, day pill labels and time chip labels use the farm timezone from city.timezone in the OpenWeather response rather than the browser timezone. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* display spinner while loading

…t when returning 'Today'

* scrollIntoView when slots are updated * update formatTimeChipLabel function

…t risk display

kathyavini

Looks fantastic, and with so many difficult date/time details sorted out 🙇❤️ I also appreciate the extra accessibility added to this one with aria-pressed and the labels; it feels much better than our normal default!

I went down a bit of a rabbit hole with the local storage litefarm_lang (comment below) which was totally inconclusive -- maybe you could set me straight 😅 The last time I did a lot of localization testing I swear it was very easy to produce dates in Japanese throughout app but that seems to have changed??

Also on localization, just for future reference

As of today it's appears still completely broken in Punjabi. But it's 100% desktop Chrome browser and not the component, since it works perfectly on mobile:

Desktop:

Phone:

kathyavini · 2026-06-03T23:02:59Z

+}
+
+export function localTimeOfDay(utcMs: number, offsetSeconds: number): number {
+  const localMs = (utcMs + offsetSeconds) * 1000;


Okay seeing these side-by-side really threw me for a loop for a moment given the matching variable name utcMs, but different parentheses 😅

I think the math is all correct, but the variable name for this second function should be utcSeconds as it is multiplied by 1000 here. The top one is actually in ms, though.

kathyavini · 2026-06-03T23:05:22Z

+};
+
+export function formatTimeChipLabel(utcMs: number, offsetSeconds: number, locale: string): string {
+  const localMs = (utcMs + offsetSeconds) * 1000;


I think this utcMs should also be utcSeconds

kathyavini · 2026-06-03T23:13:00Z

+      slots={visibleSlots}
+      offsetSeconds={offsetSeconds}
+      system={system}
+      locale={i18n.language}


This was an interesting choice by Claude to move us onto i18n.language. I think this will be the first feature that uses this instead of getLanguageFromLocalStorage(). I was assuming that those can be different because I used to see this a lot when testing back in the day (i.e. Japanese dates on home page):

I can still see this for an account with ja as my user table language_preference if I submit an unrelated change on the "My Info" form, but it doesn't survive reload and it doesn't show this when I first log in. I'm quite sure it used to 🤔 Do you know if this behaviour has changed, maybe with the i18n changes we pushed for offline? Are you still able to see this for some accounts?

Only if so, I'm worried it will feel like a regression -- the dates will have appeared in native language on the old Weather Board, but will be strictly in English now -- and maybe we should check with Loïc? But my concern might be out-of-date if i18n is updating local storage differently now.

Edit: Another example: dates like this in transactions... this I remember seeing commonly as well:

(As a side note I wanted to check what we had picked for the date internationalization in Farm Notes, only to realize we didn't internationalize that date string at all! 😱 Oops! I will make a Jira ticket)

I appreciate you testing this and finding that bug!!
I'll replace i18n.language with getLanguageFromLocalStorage for consistency!

kathyavini · 2026-06-04T18:06:27Z


 export const weatherService = {
-  async getWeather({ lat, lon, units = 'metric' }: WeatherParams): Promise<WeatherData> {
+  async getWeather({ lat, lon }: WeatherParams): Promise<WeatherForecast> {


It's not from this PR at all and it's just a minor preference, but what do you think of naming this weatherService.getWeather (which is called from weatherController.getWeather) something distinct?

It just made IDE code search / click-follow a hair more disorienting than it had to be that the two functions had the exact same name. Could the service method be called something like fetchForecast or fetchWeatherForecast?

kathyavini · 2026-06-04T19:51:59Z

+  });
+  let label = formatter.format(date);
+  if (date.getUTCMinutes() === 0) {
+    label = label.replace(/:00/, '');


I know it got the go-ahead from Loïc as not looking weird, but I'm with you on this one -- the plain numbers 2 5 8 in the time strip throw me off when in es or fr! I don't feel like I'm looking at times at all.

Maybe this is something we can double-check with at least one Spanish speaker in bug bash to make sure this is universally understood 😉

Alternatively / maybe simpler... would it be hard to affix the :00 back on ONLY when not in am/pm time? That might be another option that I think Loïc would like if he saw, probably even better than the plain numbers.

I've update the function to keep :00 conditionally. I like it much better 😁

…m/pm

SayakaOno

Thank you Joyce for reviewing! I'm sorry that I confused you with the seconds/milliseconds mix-up 🙏 I think I've addressed all your comments.

For the Punjabi issue (https://issuetracker.google.com/issues/40679433), I don't see any updates from the past year, and it looks like only 10 people have voted, so I don't think we can get our hopes up 😞
I don't think we had any Punjabi users last time we checked, but it looks like there's one currently. I wonder if we should fall back to English when the user is on Chrome desktop and their language preference is Punjabi.
There seems to be some time before the release, so maybe we could ship it?

SayakaOno · 2026-06-02T19:01:15Z

+  const value = convert(rainMm + snowMm)
+    .from('mm')
+    .to(unit);
+  const displayValue = system === 'metric' ? value : Math.round(value * 1000) / 1000;


metric: display the data as-is (2 decimal places)

imperial: round to 3 decimal places

It looks like I'd forgotten to submit this...

I complete forgot! 😳

And my testing farm did have one of those crazy rain amounts that needed all three decimal places 🙏

SayakaOno · 2026-06-04T22:14:55Z

+      slots={visibleSlots}
+      offsetSeconds={offsetSeconds}
+      system={system}
+      locale={i18n.language}


I appreciate you testing this and finding that bug!!
I'll replace i18n.language with getLanguageFromLocalStorage for consistency!

SayakaOno · 2026-06-04T22:17:03Z


 export const weatherService = {
-  async getWeather({ lat, lon, units = 'metric' }: WeatherParams): Promise<WeatherData> {
+  async getWeather({ lat, lon }: WeatherParams): Promise<WeatherForecast> {


SayakaOno · 2026-06-04T22:44:53Z

+  });
+  let label = formatter.format(date);
+  if (date.getUTCMinutes() === 0) {
+    label = label.replace(/:00/, '');


I've update the function to keep :00 conditionally. I like it much better 😁

kathyavini

Ohhh that :00 change really does make such a nice difference 😍

For the Punjabi issue (https://issuetracker.google.com/issues/40679433), I don't see any updates from the past year, and it looks like only 10 people have voted, so I don't think we can get our hopes up 😞

Thank you for the link, I have upvoted it! 🤣

I wonder if we should fall back to English when the user is on Chrome desktop and their language preference is Punjabi.
There seems to be some time before the release, so maybe we could ship it?

I would really like to do this, yes!!! But then I get concerned about ruining the working mobile? I think there is a pre-existing ticket so I'll add it into the epic as a reminder to figure something out if there is time.

kathyavini · 2026-06-05T22:41:07Z

+  const value = convert(rainMm + snowMm)
+    .from('mm')
+    .to(unit);
+  const displayValue = system === 'metric' ? value : Math.round(value * 1000) / 1000;


I complete forgot! 😳

And my testing farm did have one of those crazy rain amounts that needed all three decimal places 🙏

litefarm-pr-bot requested review from a team as code owners May 21, 2026 19:41

litefarm-pr-bot requested review from kathyavini and removed request for a team May 21, 2026 19:41

kathyavini assigned SayakaOno May 21, 2026

LF-5298 Restore comment in weatherApi

73fa20b

SayakaOno marked this pull request as draft May 22, 2026 21:37

SayakaOno added 17 commits May 22, 2026 15:23

LF-5298 Improve formatLongDate function

3d0a8db

LF-5298 Update TimeStrip CSS

5c80652

LF-5298 Update TimeStrip stories decorator

eeb4221

LF-5298 Adjust FrostBanner component and stories

571f80e

LF-5298 Adjust DayWeatherSummary component

8f53bab

LF-5298 Adjust DayPillRow

e095b44

LF-5298 Adjust weather widget spacing

bef6a55

LF-5298 Adjust weather forcast

56f6b4c

* display spinner while loading

LF-5298 [WIP] Update formatDayPillLabel to check browser's time offse…

ad28122

…t when returning 'Today'

LF-5298 Update TimeStrip to check onPrev and onNextand disable arrows

4822b73

LF-5298 Update TimeStrip and stories

35cdf98

* scrollIntoView when slots are updated * update formatTimeChipLabel function

LF-5298 Update PureWeatherForecast to show slots for selected day

4134316

LF-5298 Make TimeStrip reusable

c244efe

LF-5298 Add justify-content: space-around to TimeStrip slotsRow

2fe3164

LF-5298 Move TimeStrip component and stories

cb61e0d

LF-5298 Use existing translation

c2bcce7

LF-5298 Replace Measurement with System

3e9dafe

SayakaOno added enhancement New feature or request new translations New translations to be sent to CrowdIn are present labels May 26, 2026

SayakaOno added 3 commits May 26, 2026 15:22

LF-5298 Rename selectors file to utils

1988a2d

LF-5298 Move frostThresholdLabel function

ecc95cc

LF-5298 Finalize formatDayPillLabel function

bf0c8ba

SayakaOno added 18 commits May 27, 2026 10:47

LF-5298 Remove tempMinC from Weather API response, use tempC for fros…

8e8207e

…t risk display

LF-5298 Include snow data in precipitation

514ca9e

LF-5298 Tweaks

69c5b49

LF-5298 Move logic in PureWeatherForecast to its parent

1e715f9

LF-5298 Rename DayWeatherSummary to WeatherDetail

012ad4d

LF-5298 Remove temp_min from OpenWeatherListEntry

8c71c40

LF-5298 Tweaks and bug fix in WeatherForecast

a90b841

LF-5298 Add probability to WeatherDetail

deebebe

LF-5298 Update precipitation format

8da3e64

LF-5298 Add --Accent-red-lighter color

f3fed84

LF-5298 Replace hard-coded colors

16abcb8

LF-5298 Add styles for mobile view

9846fa1

LF-5298 Adjust WeatherDetail styles

ba32baa

LF-5298 Update TimeStrip component to accept className prop

026db47

LF-5298 Pass className prop to TimeStrip

498253f

LF-5298 Fix metrics dt font size

04cec4f

LF-5298 Rename import for WeatherDetail

1a6a11d

LF-5298 Adjust days depending on browser size

5f11cf0

SayakaOno marked this pull request as ready for review June 2, 2026 20:51

kathyavini reviewed Jun 4, 2026

View reviewed changes

SayakaOno added 4 commits June 4, 2026 15:23

LF-5298 Correct function's parameter names

aa3025e

LF-5298 Rename weatherService's method

63734e3

LF-5298 Replace i18n.language with getLanguageFromLocalStorage()

928ecd3

LF-5298 Update formatTimeChipLabel to keep ':00' for labels without a…

91f040b

…m/pm

SayakaOno reviewed Jun 5, 2026

View reviewed changes

kathyavini mentioned this pull request Jun 5, 2026

LF-5318 Unsupported language user is redirected to welcome page after login despite having farms #4186

Open

16 tasks

kathyavini approved these changes Jun 5, 2026

View reviewed changes

kathyavini added this pull request to the merge queue Jun 5, 2026

Merged via the queue into integration with commit 4a897e3 Jun 5, 2026
6 checks passed

Conversation

litefarm-pr-bot commented May 21, 2026 • edited by SayakaOno Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kathyavini left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kathyavini Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SayakaOno left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kathyavini left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

litefarm-pr-bot commented May 21, 2026 •

edited by SayakaOno

Loading

kathyavini left a comment •

edited

Loading

kathyavini Jun 3, 2026 •

edited

Loading

kathyavini left a comment •

edited

Loading