3 learnings bij het ontwikkelen van een planningsapp

Gepubliceerd: 21 oktober 2019

Pieter Braam

Developer

Bij Create hebben wij veel ervaring met het maken van progressive web apps, waar de gebruiker planningen kan maken voor zijn klanten of werknemers. In dit artikel vertel ik je tegen welke problemen ik ben aangelopen en hoe ik dit heb opgelost.

1. Het native date object gebruiken om datestrings te converteren

Na het in productie gaan van onze app kregen wij vrij snel bugreports binnen van gebruikers, die aangaven dat hun dienst een uur te laat begon. Na enig onderzoek bleek dat de de oorzaak lag bij het verkeerd afhandelen van datum conversies. Bijvoorbeeld een simpele conversie van “2019-10-20T12:00:00” heeft op chrome en safari het volgende resultaat:

JavaScript

1Sun Oct 20 2019 12:00:00 GMT+0200 (Central European Summer Time) // chrome
2Sun Oct 20 2019 14:00:00 GMT+0200 (CEST) // safari

Daarom is het belangrijk om altijd de tijdzone te vermelden in je datumstring: “2019-10-20T12:00:00+02:00”. Eventueel kun je hiermee correcties toepassen wanneer de tijdzone van de gebruiker afwijkt. Maar wil je als developer eigenlijk wel bezig zijn met tijdzones? Tom Scott heeft dit heel mooi verwoord in dit filmpje:

Ondanks de toevoeging van tijdzones bleven de tijden bij sommige gebruikers afwijken. Een mogelijke oorzaak zou een verkeerd ingestelde tijdzone kunnen zijn, alle browsers converteren namelijk alle datumstrings naar hun eigen tijdzone. Ongeacht de reden, het converteren van datumstrings met het datum object is gewoonweg niet 100% betrouwbaar. Maar hoe moet je dan wel met tijdzones en datums omgaan? Voor het aanmaken van een datum kun je het beste de volgende syntax gebruiken:

JavaScript

1new Date(2019, 0, 28, 12, 30, 1)

Hiermee wordt de tijd letterlijk overgenomen aan de hand van de lokale tijd van de browser, zonder tijdzone conversies. Nog handiger is om een externe library als date-fns of momentjs te gebruiken. Deze libraries bieden een gebruiksvriendelijkere manier om met datums te werken en allerlei tools om datumberekeningen te vergemakkelijken.

2. Geen cache buster in de app

Stel, je hebt net een nieuwe update uitgebracht op productie. Echter, de eerste gebruikers zien de nieuwe wijzigingen niet. Door de caching technieken van moderne browsers blijven gebruikers de oude versie van de applicatie zien. Een voor de hand liggende oplossing zou het uitzetten van caching zijn. Maar dit zou desastreuze gevolgen hebben voor de laadtijden van onze app. Hoe kun je ervoor zorgen dat je app snel werkt met caching maar het wél kan forceren om een nieuwe versie op te halen? Waarschijnlijk gebruik je hashing voor js and css files en bevat je index.html cache-control headers. Misschien heb je zelfs een service-worker https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker die caching voor je beheert. Wat wij ervaren hebben is dat dit vaak goed werkt maar dat in sommige gevallen browsers hun eigen regels toepassen ongeacht alle cache validatie die je toepast. Hierdoor kunnen sommige gebruikers in een soort “cache-limbo” geraken. Zij zitten vast aan een oude versie van de app en moeten handmatig hun cache verwijderen. Geen goede gebruikerservaring dus. Een oplossing hiervoor is het gebruik maken van een cache buster in je app https://dev.to/flexdinesh/cache-busting-a-react-app-22lk . Dit zorgt ervoor dat je app altijd ververst wordt bij een nieuwe release. Een cache buster is dus een laatste redmiddel in de frontend om de gebruiker van de laatste versie te kunnen voorzien, zonder interactie vanuit zijn/haar kant.

3. Geen goede data flow structuur

Plan vooraf goed hoe je data kunt ontvangen, manipuleren en uitzenden. Kun je deze data onderverdelen in meerdere modellen? Probeer eerst een helder beeld te schetsen voordat je begint. Het achteraf wijzigen van de datastructuur van je app vergt namelijk veel tijd en werk omdat je app dan waarschijnlijk zodanig is ingericht dat een kleine wijziging grote gevolgen kan hebben. Alle componenten in je app zullen waarschijnlijk data ontvangen of uitzenden. Het is daarom dan ook slim om data hogerop in de hiërarchie van je app beschikbaar te maken. Redux kan je hier uitstekend mee helpen, deze drie fundamentele principes van Redux geven je handvaten voor een heldere data structuur van je applicatie. https://paulkogel.gitbooks.io/redux-docs/content/docs/introduction/ThreePrinciples.html

Conclusie

De beschreven problemen zijn ontstaan tijdens het ontwikkelen van een react planningsapp maar zal raakvlakken hebben met elke soort app.

Opmerkingen

Er zijn momenteel nog geen opmerkingen geplaatst onder deze blog.
Wil jij als eerste een bericht achter laten?

Laat een bericht achter
Aantal tekens:0 / 500

Beveiligd met reCAPTCHA.PrivacyVoorwaarden