API en React Componenten in Eve /DEVBOEK

Door ikbenmelle op zondag 21 februari 2016 13:30 - Reacties (2)
CategorieŽn: Devboek, Eve, Views: 1.830

TL;DR Sinds deel 1 heb ik de eerste versie van de REST API af en zelfs wat Componenten vernieuwd. Joepie, Eve kan nu een echte webapplicatie worden! De login, menu en rapport ontwikkelde ik als eerste.

Trots op Eve. Dat zijn de woorden van mijn vriendin, die Eve trouwens zelf ook al in gebruik heeft. Tijd voor een update dus! Inmiddels staat de API (voor toegang tot de database zonder poespas) als een huis en de eerste stapjes zijn gezet om de platte website tot een heuse webapplicatie te verheffen. Met alle voordelen van dien.

Ten tijde van mijn laatste artikel was Eve nog een platte site, dat betekent dat voor alle acties de pagina ververst werd. Elke actie was in feite een formulier dat direct werd uitgevoerd. Niet echt handig, zeker niet als je even snel een paar to do-items wil updaten. Zo duurt een simpele actie onnodig lang, terwijl het ook zo simpel kan zijn als one-click-and-it's-done.

Tijd om met een schone lei te beginnen en het geheel als een webapplicatie te ontwikkelen... of niet? Al snel realiseerde ik me dat het het gigantisch veel werk zou zijn en dat zowel de oude als de nieuwe site eigenlijk prima 'in elkaars vaarwater' kunnen bestaan. Althans, met de juiste tool: React. Zo kan ik dan elk stukje gebruiken zodra het klaar is. En hip voelen, want AGILE. Een voor een vernieuw ik de compontenten en wordt het uiteindelijk volledig een webapplicatie.
Wat en waarom webapplicatie?
Een normale webpagina wordt gegenereerd op de server en vervolgens naar jouw browser gestuurd. Zulke pagina's worden wel eens 'plat' genoemd. In een webapplicatie wordt de applicatie zelf naar jou gestuurd en deze haalt vervolgens de informatie op van de server. De server hoeft dus geen pagina's te genereren (dat scheelt!), maar alleen de webapplicatie te versturen en een interface te hebben voor het versturen van de informatie. Er gebeurd dus niks meer dan het ophalen, aanmaken, wijzigen en (indien gewenst) verwijderen van data via een API, de interface van de server. Bijkomend voordeel is dat de ontwikkeling simpeler is: de server onderhoudt en verstuurt de data (vanuit de database) en in de webapplicatie wordt het logisch getoond. Een prettige, veiligere scheiding.
Echter had ik die interface nog niet en na-veel-research heb ik gekozen voor een zogenaamde REST(ful)* API die ik zelf in PHP zou gaan programmeren. Kant-en-klaar oplossingen kwamen tekort (of onnodig, ononderhoudbaar complex) of waren in handen van derden. Wat een werk. Met name het verwerken van PUT requests is tricky, PHP biedt hier geen standaard voor. Na vele tientallen uren ontwikkeling heb ik de eerste bruikbare versie af en goed gedocumenteerd. CHECK. Op een punt na is de REST API ook daadwerkelijk RESTFUL: Authenticatie geschiedt middels cookies, in plaats van een token. Ietwat eenvoudiger voor nu, aangezien je cookies ook vanuit de server kunt versturen. ✓REST(FUL) API

Volgende stap was het gaan ontwikkelen van de componenten. Ik besloot met een lang staande wens te beginnen: het combineren van de gemaakte uren met daarin de taken, in een 'platte lijst' weergave die je kunt overkopieren naar de mail of factuur voor klanten. Ook kan ik voor mezelf zien hoelang ik nou eigenlijk over alles doe... hiervoor moesten twee typen data worden gecombineerd: de tijdsregistraties waaronder vervolgens de items (taakjes, milestones, etc.) worden geordend. Dit moest dan weer per dag worden geordend, met een urenaantal per dag. Deze dagen dan weer per maand en dat dan weer per jaar. Zo kun je precies zien wanneer je wat gedaan hebt. ✓Rapport

Een ander pijnpuntje was het menu dat constant in beeld was. Als je ergens mee bezig bent, wil je niet de gehele tijd in het zicht hebben dat er ook nog andere projecten/klanten aandacht vereisen. Het menu heb ik dus oproepbaar gemaakt per klik of hotkey (CMD en/of CTRL). In een latere iteratie zou je dan meteen kunnen zoeken in het menu en ENTER kunnen drukken om het te openen, vergelijkbaar met de quick solution. ✓Menu

Maar toen realiseerde ik me dat er momenteel twee manieren waren om in te loggen - een potentieel risico... Tijd om daar wat aan te doen en de login via de API te laten verlopen: zodra je ingelogd bent, opent nu de app. Dit is een onderdeel dat constant terugkomt en dus meteen goed moet zijn - het is immers vaak je eerste interactie met een applicatie. ✓Login
http://static.tweakers.net/ext/f/KcpXNdndlUK6THVUHoxxZY0j/full.gif
De login van Eve, die eventuele opmerkingen toont en je anders meteen inlogt en waarna de app direct wordt getoond. Het is mijn idee om deze gefocuste werking/design door te voeren in alle componenten Eve. En ja, oeps, het plaatje is net iets breed. Bekijk hier het origineel.

Tijd om verder te gaan: workflow instellen (Webpack of toch Gulp?) voor development van React Componenten en het maken van het tijdsformulier (voorgesteld in deel 1).

Mocht je ergens meer over willen weten of vragen hebben; ik hoor het graag :9

Volgende: Soepermark, is het wat? /DEVBOEK 10-'15 Soepermark, is het wat? /DEVBOEK

Reacties


Door Tweakers user Borizz, maandag 22 februari 2016 19:51

Voor een geavanceerde build kun je Webpack en Gulp combineren (http://webpack.github.io/docs/usage-with-gulp.html). Maar je kunt ook al veel met Webpack (standalone) bereiken...

Door Tweakers user ikbenmelle, woensdag 24 februari 2016 10:07

Borizz schreef op maandag 22 februari 2016 @ 19:51:
Voor een geavanceerde build kun je Webpack en Gulp combineren (http://webpack.github.io/docs/usage-with-gulp.html). Maar je kunt ook al veel met Webpack (standalone) bereiken...
Bedankt voor je link. Momenteel ben ik bezig Gulp "uit te faseren" voor de development (en build) en Webpack inderdaad standalone te gebruiken. Het maakt de ontwikkeling van React Apps onzettend simpel en de build is eenvoudig te optimaliseren! Waarom heb ik dit niet eerder ontdekt? 8)7

Een guide voor het opzetten van een Webpack workflow waar ik veel aan had:
http://www.pro-react.com/materials/appendixA/

Reageren is niet meer mogelijk