CGI:n blogi - kirjoituksia eri asiantuntijoilta

CGI Suomen asiantuntijat

Kirjoituksia asiantuntijoiltamme

React-ekosysteemi ratkaisee niin monta verkkosovellusten kehityksen ongelmaa, että on aika jakaa parhaan JavaScript-kirjaston ilosanomaa.

Suhteeni JavaScriptiin on muuttunut vuosien varrella. Vielä kymmenen vuotta sitten turvauduin JavaScriptiin vain pakon edessä. Jaakobin paini eri selainten yhteensopivuusongelmien kanssa ei houkutellut.

Sitten tuli jQuery. Sen myötä JavaScript olikin ihan relevantti vaihtoehto yksinkertaisiin toteutuksiin. Backbone.js puolestaan avasi silmäni siihen, että koko sovelluksen voi oikeasti toteuttaa JavaScriptillä. Angular tuntui jo valmiilta paketilta.

Sitten päädyin tekemään Reactia. Sen jälkeen ei tee mieli palata entiseen.

Viime talven Bootcampin tunnelmia

Reactin ekosysteemistä löytyy hämmästyttävän yksinkertaiset ratkaisut fronttikehityksen kipukohtiin. Reactin komponenttimalli on hyvä arkkitehtuuri verkkosovelluksille.

Komponenttien toteutuksessa törmää väistämättä kysymykseen, milloin tehdä yleiskäyttöinen komponentti ja milloin juuri tiettyyn tapaukseen räätälöity komponentti.

Käyttöliittymän eri näkymissä toistuu yleensä toimintoja, jotka näyttävät hyvin samanlaisilta ja toimivatkin melkein samalla tavalla. Niissä on kuitenkin pieniä, mutta sitäkin kiusallisempia eroja.

Tällaisessa tilanteessa tulee mieleen helposti vain kaksi vaihtoehtoa: a) tehdä komponentit copy-pastella tai b) rakentaa yksi komponentti, joka yrittää taipua kaikkiin käyttötapauksiin.

Molemmat vaihtoehdot johtavat kaaokseen. Copy-paste -koodin ylläpitäminen on painajaista. Kaikkeen taipuvasta yleiskomponentista taas tulee hirvittävän monimutkainen, parametreilla säädettävä hirviö. Se ei edes ole uudelleenkäytettävä, koska toteutusta pitää muuttaa jokaista käyttötapausta varten erikseen.

Reactin kanssa ratkaisu on hyvin yksinkertainen: pilkotaan komponentit pienempiin osiin. Jos toiminnoissa on jokin täsmälleen samanlainen osa, siitä tehdään yleiskäyttöinen komponentti. Toiminnot toteutetaan erillisinä komponentteina, mutta ne koostuvat samoista rakennuspalikoista.

Tällä tavalla koodia ei tarvitse kopioida ja kaikki komponentit pysyvät samalla yksinkertaisina. Ratkaisu voi kuulostaa itsestään selvältä, mutta se poistaa yhden yleisimmistä fronttikehityksen kompastuskivistä.

Hienojakoiset rakennuspalikkakomponentit ovat myös avain tuottavuuteen. Esimerkiksi lomakkeen tekstikentästä kannattaakin ehdottomasti tehdä oma komponenttinsa.

Näin siksi, että tekstikenttäkomponentissa ei ole kysymys vain HTML-elementistä. Yleensä sille tarvitaan myös label, tapa ilmaista pakollisuus, virheellisen syötteen ilmaisu (esimerkiksi punainen kehys), placeholder virheilmoitukselle jne. Tällaisten matalan tason asioiden tekemiseen käytetään yleensä liikaa aikaa.

Jos huomaat, että aikasi menee CSS- ja HTML-säätöihin, kannattaa miettiä, onko lähestymistapasi oikea. Kun teet yleiskäyttöiset rakennuspalikat hoitamaan matalan tason HTML/CSS-asiat, pääset nopeasti rakentamaan featureita valmiista rakennuspalikoista koostamalla. Tuottavuutesi moninkertaistuu.

Viime talven Bootcampin osallistujia

Toinen komponenttiarkkitehtuurin kompastuskivi on komponenttien välinen kommunikointi. Toimintojen ei tulisi edes tietää toisistaan saati olla toisistaan riippuvaisia. Silti ne joutuvat usein jakamaan tietoa keskenään.

Ongelma on perinteisesti ratkaistu eventeillä. Eventien käyttö johtaa kuitenkin monimutkaisiin, virheille alttiisiin ja vaikeasti seurattaviin tapahtumaketjuihin.

React-ekosysteemiin kuuluva Redux ratkaisee kommunikointiongelman nerokkaan yksinkertaisesti jaetun ja normalisoidun staten avulla.

Kolmas merkittävä tuottavuustekijä on sovelluksen tilan säilyvyys. Useimmissa frameworkeissa komponentit säilyttävät itse oman tilansa. Kun käyttäjä navigoi näkymästä toiseen, komponentti poistuu muistista ja sen tila häviää. Kun käyttäjä palaa takaisin näkymään, luodaan uusi komponentti.

Yleensä käyttäjä haluaisi kuitenkin nähdä näkymän siinä tilassa, johon hän on sen jättänyt. Esimerkiksi monivaiheisessa tilausprosessissa tai steppeihin jaetussa wizardissa käyttäjän syötteet pitää olla jossain tallessa. Tämä on haaste, joka kehittäjän pitää ratkaista tavalla tai toisella.

Reduxia käytettäessä säilyvyysongelmaa ei ole, koska sovelluksen tila on erillään komponenteista. Komponentteja luodaan ja tuhotaan mutta sovelluksen tila säilyy.

React -ekosysteemi on tämän hetken tuottavin tapa tehdä verkkosovelluksia, koska:

  • komponenttien uudelleenkäyttäminen on joustavaa (React),
  • komponenttien välinen kommunikointi on tehokasta ja hallittua (Redux),
  • sovelluksen tila säilyy näkymästä toiseen (Redux).

Näistä syistä satsaamme Reactiin myös CGI:llä. Seuraavassa sisäisessä Bootcampissa, eli teknisille asiantuntijoillemme suunnatussa koulutussessiossamme, sukellamme Reactin ihmeelliseen maailmaan. Ohessa muutama kuva viime vuoden Bootcampista, jossa perehdyimme iOS-sovellusten ohjelmointiin. Pian tarjolla on kaksi päivää sekä yhdessäoloa kylpylässä että sitä itseään – Reactia!

Blogin on kirjoittanut Matti Koljonen.

Kirjoittajasta

CGI:n blogi - kirjoituksia eri asiantuntijoilta

CGI Suomen asiantuntijat

Kirjoituksia asiantuntijoiltamme

CGI on kansainvälisesti suomalainen digitalisaatiokumppani.  Suomessa noin 3 800 asiantuntijaa konsultoivat asiakkaitamme liiketoiminnan ja ICT-ratkaisujen kehittämisessä. Tällä profiililla julkaisemme kirjoituksia CGI:n eri asiantuntijoilta.