fix(board): fetch departures with correct start time

[emilielr]

Jeg har drodla og skrevet ned tankene mine her, om folk er keen på å se de: https://www.notion.so/bekks/Ekspressbuss-oppdateres-ikke-i-tavla-13e6bd30854180968a75cd83a66fd183?pvs=4 😃

Problemet lå i at startTime som man sender med i query til api-et ikke oppdaterte seg - da fikk man kun hentet de samme avgangene hele tiden. SWR er satt til å fetche hvert 30 sekund, men hvis verken key eller data har endret seg, så vil den bare hente den cachede dataen, og aldri hente noe på nytt (https://swr.vercel.app/docs/advanced/performance#deep-comparison). Siden startTime aldri endret seg, så endret heller aldri key seg, og siden dataen ikke er sanntid så endret heller aldri data seg heller. Siden ikke noe av dette endret seg, så ble komponenten bare rendret én gang og startTime kun satt én gang ved initial load. Nå er kalkulasjonen flyttet inn i fetcher-funksjonen, slik at startTime alltid er +30 sekunder for hver fetch.

Huskeliste

• Sjekk om det funker hos deg (at avganger blir hentet hvert 30. sekund)
• Sjekk at det funker i Chromium 56
• Sjekk at det funker om du setter offset

[SelmaBergstrand]

Tror det er noe krøll med tidssoner når jeg slenger på offset 🤔

Klokka 12:16 skrev jeg inn 30 min offset, men får fortsatt opp avgang kl 12:31:

I requesten ser det sånn ut: den sender med start-time 11:16 tror jeg? Som heller ikke tar hensyn til offset.

Veldig rart, det funka med offset når jeg testa på Stavanger bussterminal

[SelmaBergstrand]

Fant også en annen rar bug, men den har kanskje ikke noe med denne PR-en å gjøre:

Når jeg skriver inn et offset så hender det ganske ofte at tallet endrer seg? Enten umiddelbart (så snart jeg trykker ut av offset-boksen) eller når jeg har trykket lagre og så åpner boksen igjen. Endrer seg feks fra 15 til 12 eller fra 35 til 30. Er dette meningen?

[SelmaBergstrand]

Ellers funka det bra for meg, men finnes det kanskje en enklere måte å bare disable caching av hentet data? Inne på https://swr.vercel.app/docs/advanced/performance#deep-comparison så det ut som om man kan customize comparison-funksjonen, er det kanskje mulig å bare sette den til å alltid være true (altså at queryen "alltid er endret" så caching ikke skjer)?

[purusott]

Tror det er noe krøll med tidssoner når jeg slenger på offset 🤔

Klokka 12:16 skrev jeg inn 30 min offset, men får fortsatt opp avgang kl 12:31:

I requesten ser det sånn ut: den sender med start-time 11:16 tror jeg? Som heller ikke tar hensyn til offset.

Veldig rart, det funka med offset når jeg testa på Stavanger bussterminal

Får heller ikke opp riktige avganger med offset

[emilielr]

Fant også en annen rar bug, men den har kanskje ikke noe med denne PR-en å gjøre:

Når jeg skriver inn et offset så hender det ganske ofte at tallet endrer seg? Enten umiddelbart (så snart jeg trykker ut av offset-boksen) eller når jeg har trykket lagre og så åpner boksen igjen. Endrer seg feks fra 15 til 12 eller fra 35 til 30. Er dette meningen?

Dette har jeg også lagt merke til før (denne PRen), så noe vi burde lage et kort på

[emilielr]

Ellers funka det bra for meg, men finnes det kanskje en enklere måte å bare disable caching av hentet data? Inne på https://swr.vercel.app/docs/advanced/performance#deep-comparison så det ut som om man kan customize comparison-funksjonen, er det kanskje mulig å bare sette den til å alltid være true (altså at queryen "alltid er endret" så caching ikke skjer)?

Skal sjekke ut denne!

[emilielr]

Tror det er noe krøll med tidssoner når jeg slenger på offset 🤔

Klokka 12:16 skrev jeg inn 30 min offset, men får fortsatt opp avgang kl 12:31:

I requesten ser det sånn ut: den sender med start-time 11:16 tror jeg? Som heller ikke tar hensyn til offset.

Veldig rart, det funka med offset når jeg testa på Stavanger bussterminal

Requesten sin starttime vil alltid være -1 time, fordi i shamash så henter man ut på +1 time. Litt merkelig, men slik det er løst:
.

Sjekker ut mer med offset.

EDIT: sendte bare med offset for stoppested av typen StopPlace, og ikke Quay, så derfor funka det ikke.. :)

[emilielr]

Hele problemet med at vi ikke får hentet inn riktige (tidsmessige) avganger er fordi startTime ikke oppdaterer seg, så det nytter ikke å disable caching eller sette et dataen alltid er ulik (for å så hente data på nytt), fordi startTime som vi sender med requesten ikke blir oppdatert :( Det sikrer vi ved å kalkulere startTime i selve fetcheren som henter dataen. Da er key endret fordi vi sender med en ny startTime. Ved å prøve å sette compare() til alltid å være usann (at man alltid henter inn ny data), så fikk man også et problem med uendelige renders