AngularJS- ja ReactJS-sovelluskehyksien vertailu
Otto Kuikka
Opinnäytetyö
Tietojenkäsittelyn koulutusohjelma 2019
Tiivistelmä
Tekijä(t) Otto Kuikka Koulutusohjelma
Tietojenkäsittelyn koulutusohjelma Opinnäytetyön otsikko
AngularJS- ja ReactJS-sovelluskehyksien vertailu
Sivu- ja liitesivu- määrä
40
Opinnäytetyö suoritetaan tutkimuksena, jonka tavoitteena on vertailla kahta JavaScript-pohjaista so- velluskehystä. Tutkimukseen sisältyy kahden CRUD-sovelluksen rakentaminen, vertailun kohteena olevilla sovelluskehyksillä. Tutkimuksessa selitetään sovelluksissa käytettyjä teknologioita ja sovel- lusten toiminnallisuuksia.
Tutkimuksen vertailussa keskitytään sovelluskehysten (AngularJS ja ReactJS), rakenteellisiin eroa- vaisuuksiin. Vertailussa tarkastellaan myös sitä, miten erot näkyvät rakennettujen CRUD-sovellusten välillä. Näin saadaan myös käytännöllinen näkökulma AngularJS:n ja ReactJS:n eroista. Vertailu- osuudessa eroja tutkitaan keskittyen erityisesti sovellusten rakenteellisiin ominaisuuksiin, ylläpidettä- vyyteen, koodin luettavuuteen ja pystytykseen.
Aluksi käydään läpi JavaScript-ohjelmointikieltä, jonka jälkeen selitetään sovelluksissa käytettyjä pal- velin- ja tietokantateknologioita. Sen jälkeen käsitellään verkkosovellusten kehitykselle ominaisia teknologiapakkoja (MEAN ja MERN) ja tutkimukselle oleelliset sovelluskehykset: AngularJS ja ReactJS. Seuraavaksi kerrotaan, miten tutkimus on suunniteltu ja toteutettu sekä käydään läpi tutki- muksen aikana syntyneet sovellukset. Lopuksi selitetään tutkimustulokset vertailemalla sovelluske- hyksiä ja pohditaan tutkimuksen tekoa ja siinä nousseita haasteita ja onnistumisia.
Tutkimustulokset osoittavat, että verkkosovelluksia rakennettaessa on hyödyllisempää käyttää ReactJS:iä. Suurimmaksi syyksi tälle tulokselle voidaan nähdä se, että AngularJS on vanhentunut, joten sen jatkokehitysmahdollisuudet ovat todella heikot.
Asiasanat
AngularJS, CRUD, JavaScript, ReactJS, Sovelluskehys, SPA
Sisällys
1 Johdanto ... 1
2 JavaScript ... 2
3 Node.js ... 4
4 MongoDB ... 4
5 MEAN-pakka ja MERN-pakka ... 5
6 SPA-sovellus ... 6
7 Sovelluskehys ... 9
8 AngularJS ... 11
8.1 Ominaisuudet ... 11
8.2 Rakenne... 13
9 ReactJS ... 13
9.1 Ominaisuudet ... 14
9.2 Rakenne... 17
10Tutkimuksen suunnittelu ... 19
11Tutkimuksen toteutus... 21
11.1 AngularJS-sovellus ... 22
12.2 ReactJS -sovellus ... 27
12Tulokset ... 33
13Pohdinta ... 37
Lähteet ... 39
1
1 Johdanto
Tämän tutkimuksen tarkoituksena on selvittää kahden eri sovelluskehyksen, AngularJS:n ja
ReactJS:n, toiminnallisuuksia sekä vertailla niiden toimivuutta web-kehityksessä. Tutkimuksessa halu- taan myös rakentaa hyvä käsitys kahden hyvin samaan tarkoitukseen käytetyn JavaScript-kirjaston eroista. Tutkimuksen tavoitteena on tuottaa kaksi hyvillä ohjelmointikäytännöillä tehtyä CRUD-sovel- lusta. Kyseisten ohjelmistotuotteiden lähdekoodia käsitellään vertailussa. Tutkimuksessa syntyy läh- dekoodin lisäksi myös suunnittelukaavio ja kuvakaappauksia. Tutkimuksen oppimistavoitteena on ym- märtää käsiteltävien sovelluskehysten rakenne ja hyödyt JavaScript-ohjelmoinnissa. Tekijä oppii myös tekemään ensimmäiset CRUD-ohjelmistonsa mainituilla sovelluskehyksillä. Ennen tutkimuksen alkua sen tekijä on opiskellut ja hyödyntänyt AngularJS-sovelluskehystä.
Sovellusten rakennuksessa käytetään sovelluskehyksien lisäksi myös muita teknologioita, jotka ovat tekijälle uusia. Näihin kuuluvat dokumenttipohjainen MongoDB-tietokanta, JavaScriptin ajoympäristö Node.js ja Express.js -niminen web-kehys. Sovelluksissa hyödynnetään myös muutamaa kehitys- työssä auttavaa Node-moduulia, jotka käsitellään tutkimuksen sovelluksia käsittelevässä osiossa. Ai- kaisemmin mainitut teknologiat tarjoavat kehittäjälle kokonaisuuden, joka mahdollistaa sekä selain- että palvelinpään kehityksen. Tämänlaista teknologiakokonaisuuksia kutsutaan nimellä full stack eli täysi pakka. Tutkimuksen sovelluksissa käytetään MEAN- ja MERN-pakkoja.
Sanasto ja lyhenteet
AJAX Tulee sanoista Asynchoronous JavaScript And XML. Se on joukko teknii- koita, joiden avulla verkkosivu voi vaihtaa dataa palvelimen kanssa, jotta koko verkkosivua ei tarvitse ladata uudelleen.
AngularJS Googlen ylläpitämä JavaScript-ohjelmistokehys, joka lisää selainpohjaisiin sovelluksiin tuen MVC-arkkitehtuurille.
CRUD Create, Read, Update, Delete. Termit kuvaavat REST-rajapinnan neljää perustoimintoa.
CSS Cascading Style Sheets on tyyliohjeiden laji. CSS-dokumenteille määritel- lään erityisesti web-sovellusten tyyliohjeita.
HTML Hypertext Markup Language. Verkkokehityksessä käytetty merkintäkieli.
2
JSON Avoimen standardin tiedostomuoto tiedonvälitykseen. Tulee sanoista Ja- vaScript Object Notation.
MongoDB Dokumenttipohjainen NoSQL-tietokanta. Dokumenteissa tieto tallentuu avain-arvo-pareina.
MVC Model-View-Controller on ohjelmistoarkkitehtuurityyli, jonka tarkoituksena on erottaa käyttöliittymä ja ohjelmakoodi omiksi kokonaisuuksikseen.
Node.js Alustariippumaton ajoympäristö JavaScriptin suorittamiseen. Mahdollistaa JavaScriptin suorittamisen suoraan palvelimella.
Ohjelmointirajapinta Alusta, jonka avulla eri ohjelmat voivat vaihtaa tietoa keskenään.
ReactJS Facebookin ylläpitämä JavaScript-ohjelmistokehys, joka toimii hyvänä poh- jana SPA- ja mobiilisovelluksiin.
Sovelluskehys Ohjelmistotuote, joka muodostaa rungon rakennettavalle tietokoneohjel- malle. Kehys tarjoaa valmiita tietokoneohjelman osia työn helpottamiseksi.
SPA Single-page-application eli yhden sivun sovellus. Sovelluksessa verkkosivu ladataan ainoastaan kerran ja sivu muuttuu käyttäjän vaikutuksesta ilman, että uusia html-sivuja kutsutaan palvelimelta.
2 JavaScript
Tässä luvussa esitellään ReactJS- ja AngularJS -sovelluskehysten perustekniikkaa JavaScript-ohjel- mointikieltä. JavaScriptin luotiin kymmenessä päivässä Brendan Eichin toimesta huhtikuussa vuonna 1995. Eich työskenteli tuohon aikaan Netscapella ja JavaScriptin alkuperäinen nimi oli Mocha. Saman vuoden syyskuussa nimi vaihtui Mochasta LiveScriptiksi ja joulukuussa, Sun-tavaramerkkilisenssin saatuaan, lopulta JavaScriptiksi. (W3C 2018.)
Vuosien 1996 ja 1997 vaihteessa JavaScript vietiin ECMA:lle (European Computer Manufacturers As- sociation) standardoitavaksi, jotta muutkin selaimen tarjoajat pääsisivät toteuttamaan standardin mu- kaista kehitystä. Virallista standardia kutsutaan ECMAScriptiksi ja JavaScript on sen kuuluisin toteu- tus.Toinen kuuluisa täytäntöönpano on ActionScript. Standardien luomisprosessi jatkui pitkään, mutta
3
ECMAScript 4:sta laatiessaan Brendan Eich ja Mozilla, Macromedia (nykyään osa Adobea) huomasi- vat, että ActionScript 3 ja Tamarin erosivat liikaa verkossa käytetystä JavaScriptistä. Samaan aikaan avoimen lähdekoodin ja kehittäjien yhteisöt tekivät töitä mullistaakseen JavaScriptiä. Yhteisöjen pon- nistus sain alkunsa, kun vuonna 2005 Jesse Garrett julkaisi raportin, jossa hän keksi termin AJAX ja kuvaili teknologioita, joiden selkärankana toimi JavaScript. Näillä teknologioilla pystyttiin rakentaa verkkosovelluksia, joissa data voitiin ladata taustalla näin välttäen koko sivun latauksia. Dynaamisem- pien sivujen rakennusta siivitti JavaScriptiä hyödyntäneet yhteisöt, jotka loivat kirjastoja kuten: jQuery, Dojo ja Mootools. (W3C 2018.)
JavaScript on ohjelmointikieli, jolla tehdään verkkosivuista interaktiivisempia. Se on HTML:n ja CSS:n ohella yksi verkkosisällön tuottamisen pääteknologioista. Jotta sivulla kävijän ei tarvitsisi ladata jatku- vasti dataa, se ajaa skriptit käyttäjän verkkoselaimella. JavaScript on dynaaminen skriptikieli, joka tu- kee sekä proseduraalista, olio-, että funktionaalista ohjelmointia. (W3C 2018.)
Proseduraalisella ohjelmoinnilla tarkoitetaan tapaa jäsentää ohjelman toimintaa aliohjelmiin eli prose- duureihin. Aliohjelma on itsenäinen osa ohjelmaa, mitä voidaan kutsua niin pääohjelman kuin muiden aliohjelmien toimesta. Suoritettuaan aliohjelman, suoritus jatkuu aliohjelmakutsusta seuraavaan ko- mentoon pääohjelmassa. (W3C 2018.)
Funktionaalinen ohjelmointi on tapa hyödyntää ohjelmointikielen valmiita funktioita ongelmien ratkai- semiseen. Niiden avulla koodista tulee tiivistä ja funktionaalisen ohjelmoinnin tavoin hyvä vain tietyn- tyyppisten ongelmien ratkaisemiseen. JavaScript mahdollistaa siis monenlaisen tavan ohjelmoida ja tämä lienee yksi syy sen yleiseen käyttöön. (W3C 2018.)
Jatkuvan JavaScriptin kehitystyön lisäksi monet muut teknologiat, jotka täydentävät JavaScriptin toi- minnallisuuksia lisäävät sen käyttöä verkkopalveluja tehtäessä. Näihin teknologioihin lukeutuvat muun muassa Node.js, JSON, MongoDB sekä kaikki ne kirjastot ja sovelluskehykset, jotka tekevät Ja- vaScriptistä moniuloitteisemman työkalun. (Rauschmayer, A. 2014)
AngularJS on JavaScriptille rakennettu sovelluskehys, jonka tarkoituksena on tuoda helpotusta se- lainpohjaisten sovellusten tekoon tekemällä koodikannasta organisoidumpaa, ylläpidettävämpää ja testattavampaa. AngularJS tuo paljon hyödyllisiä työkaluja MVC-arkkitehtuuriin perustuvien verkko- sovellusten rakentamiseen. AngularJS:iä käsitellään tarkemmin osassa 8. (Google 2018.)
ReactJS on JavaScript-kirjasto käyttöliittymälle sisältäen työkaluja käyttöliittymäkomponenttien raken- tamiseen. Tutkimuksessa ReactJS on määritelty sovelluskehykseksi. ReactJS:iä käsitellään tarkem- min osassa 9. (Porcello, E. & Banks, A. 2017, 2)
4
3 Node.js
Tässä ja seuraavassa viidessä luvussa käsitellään AngularJS- ja ReactJS-sovelluskehyksillä toteutet- tavien sovellusten käyttämiä teknologioita.
Node.js on palvelinpuolen alusta, joka on rakennettu tehokkaan V8 JavaScript -moottorin päälle.
Sama moottori on käytössä Googlen Chrome-selaimessa. JavaScript -moottoreilla pyritään tehokkaa- seen JavaScriptin suorittamiseen. V8-moottori kokoaa tulkitun JavaScript koodin suoraan konekie- leksi, jolloin se suoritetaan. Node.js on avoimella lähdekoodilla valmistettu koodin ajoympäristö yhdis- tettynä JavaScript-kirjastoon. (Tutorials Point 2018.)
NodeJS:llä tehdyt JavaScript ohjelmistot eivät ole niitä, mihin olemme tottuneet verkkoselaimissa.
NodeJS ei esimerkiksi sisällä oliomalliliittymää tai muita selaimen ominaisuuksia. JavaScriptin suorit- tamisen lisäksi NodeJS:n moduulit tarjoavat muun muassa seuraavanlaisia ominaisuuksia: komentori- vin työkalut, prosessien ohjaustoiminnot aliprosessien valvomiseksi, puskuriolion binääritietojen käsit- telyyn, TCP- tai UDP -liitännät kattavilla tapahtumavetoisilla soittopyynnöillä, DNS-haku, HTTP- ja HTTPS-asiakas/palvelin TCP-kirjaston tietojärjestelmän päälle- ja sisäänrakennettu tuki alkeelliseen yksikkötestaukseen. (W3C 2018.)
Saman ohjelmointikielen käyttö käyttäjän puolella ja palvelimella on ollut pitkäaikainen haave monelle kehittäjälle. Tämä haave on lähtöisin ajoilta, jolloin Java-sovelmien oli tarkoitus hoitaa sovelluksen se- lainpuoli ja Javan palvelinpuoli. JavaScriptin oli tuolloin tarkoitus toimia kevyenä skriptikielenä kysei- sille Java-sovelmille. Java ei kuitenkaan saanut tarpeeksi suosiota tähän tarkoitukseen ja JavaScrip- tistä tuli käytetyin selainpuolen kieli. NodeJS:n avulla voimme vihdoin käyttää samaa ohjelmointikieltä sekä palvelimen että selainpuolen työstämiseen. Tämä mahdollisuus tuo mukanaan monenlaisia hyö- tyjä, jotka selittävät osaltaan NodeJS:n suosion. Ohjelmiston tekijät voivat nyt työskennellä sekä se- lain- että palvelinpuolen kanssa, koodi siirtyy helposti selaimelta palvelimelle ilman ylimääräisiä tulk- kausoperaatioita ja yleiset tietomuodot, kuten JSON, esiintyvät palvelimen ja selaimen välissä. Koska palvelin ja selain käyttävät samaa kieltä, kaikki sen kielen yleisimmät työkalut ovat käytettävissä mo- lemmille puolille. Tämä koskee myös testauksen ja laaturaportoinnin työkaluja.
(W3C 2018.)
4 MongoDB
Tässä tutkimuksessa toteutettavat CRUD-sovellukset käyttävät MongoDB-tietokantaa. Sovelluksissa käytetyt tietokannat voidaan jakaa kahteen tyyppiin: SQL-tietokantoihin eli relaatiotietokantoihin ja NoSQL-tietokantoihin eli ei-relaatiotietokantoihin. MongoDB kuuluu tyypiltänsä jälkimmäiseen.
5 (Foote, K. 2016)
NoSQL-tietokannat voidaan jakaa neljään eri kategoriaan: Avain-arvo-varastoihin, kaaviokuvavaras- toihin, leveisiin sarakevarastoihin ja dokumenttivarastoihin. MongoDB kuuluu dokumenttipohjaisiin tie- tokantoihin. NoSQL-tietokannat on kehitetty laajojen, nopeasti muuttuvien, puoli-rakenteettomien ja rakenteettomien tietomäärien hallinnointiin. NoSQL tehostaa myös työntekoa, jossa hyödynnetään ketteriä menetelmiä, nopeaa kaavioiden kertausta ja usein tapahtuvaa koodin työntämistä. NoSQL tarjoaa helppoa ja joustavaa olio-ohjelmointia sekä mahdollisuutta hajautettuun tietokantarakentee- seen. (Foote, K. 2016)
MongoDB:n ominaisuuksia ovat muun muassa avain-arvo-mekanismi, JSON-dokumentit, skaalautu- vuus ja skeemattomuus. Avain-arvo-parilla tarkoitetaan sitä, että jokainen tietokannan dokumentti si- sältää avaimen (esim. ”nimi”) ja arvo (esim. ”Otto”). NoSQL-tietokannat käyttävät JSON:ia (JavaScript Object Notation) datan kirjoittamiseen, lukemiseen ja siirtämiseen. Skaalautuvuus NoSQL:n tapauk- sessa tarkoittaa tehokkuutta ylläpitää jatkuvia muutoksia tietokantaan esim. sadoilta käyttäjiltä sekun- nissa. Skeemattomuus mahdollistaa sen, että NoSQL-tietokannoissa dokumentteja laatiessaan ei tar- vitse käyttää samoja rakenteita, vaan ne voidaan lisätä tietokantaan sellaisenaan.
(Foote, K. 2016)
5 MEAN-pakka ja MERN-pakka
Ennen kuin käsittelen termejä MEAN-pakka (MEAN stack) ja MERN-pakka (MERN stack) on tärkeää ymmärtää käsite full stack eli täysi pakka. Tällä tarkoitetaan komponenttipakettia, joka sisältää yhte- näisen kokonaisuuden, sekä selainpään että palvelinpään sovelluskehitykseen. Käsite ”Full stack Ja- vaScript” tarkoittaa siis pakkaa, joka sisältää vain JavaScriptiä hyödyntäviä komponentteja niin datan näyttämiseen kuin sen siirtelyyn. MEAN-pakka sisältää komponentit: MongoDB, Express, AngularJS ja Node.js. MERN-pakan ero MEAN:iin on AngularJS:n korvaaminen ReactJS:llä.
(Morgan, A. 2017)
Sovelluskehitystä voi tehdä ilmankin näitä pakkoja, mutta niiden tuomat hyödyt mahdollistavat sovel- lusten nopeamman kehityksen, koska koodaustyö vähenee. Pakkoja käytetään paljon niin pienissä kuin suurissa projekteissa, joten vertailu on lähellä koodarin todellisuutta. Näiden hyötyjen takia, ReactJS- ja AngularJS -sovellukset tehdään tässä tutkimuksessa MEAN- ja MERN -pakkoja hyväksi- käyttäen.
6
6 SPA-sovellus
Ohjelmistokehittäjät ovat pitkään tehneet työtä sen eteen, että verkkosovellukset saataisiin natiivien työpöytäsovellusten näköisiksi ja käytettävyydeltään samantapaisiksi. Hyviä esimerkkejä tästä työstä ovat Adobe Flash, Microsoft Silverlight ja Java-sovelmat (Java Applet). Näistä jokaisella on sama tar- koitus: Tuoda työpöytäsovellusten tehokkuus järjestelmäriippumattomaan verkkoympäristöön. Tämä tavoite voidaan saavuttaa käyttäen pelkästään JavaScriptiä, HTML:a ja CSS:iä. (Scott, E., 2015, 5-6)
SPA (Single-page application) -sovellukset eroavat muista siten, että ne suoritetaan asiakaspään se- laimessa. Tarkoituksena on siirtää toimintalogiikka selaimelle, jotta palvelimeen ei kohdistuisi niin pal- jon kuormaa ja, että sovelluksen suorituskyky paranisi. Käännekohta tälle uudelle tavalle ajatella so- velluskehitystä tuli 2000-luvun alussa. Tuolloin AJAX:n menestys oli aluillaan. Microsoftin Internet Ex- plorer -selaimen käyttämä ActiveX-ohjaus lähetti ja vastaanotti dataa asynkronisesti. Myös muut se- lainkehittäjät alkoivat hyödyntää tätä ohjaimen toiminnallisuutta ja se sai nimekseen XMLHttpRequest (XMR) API. Kehittäjät alkoivat käyttämään tätä API:a JavaScriptin, HTML:n ja CSS:n kanssa saavut- taen merkittäviä tuloksia. Kyseisten tekniikoiden sekoitus nimettiin AJAX:ksi (Asynchronous Ja- vaScript and XML). Seuraten AJAX:n suuntaa SPA -konsepti hyödyntää AJAX:n sivuntason manipu- lointitekniikoita koko sovellukseen. Tämän lisäksi SPA:n yleiset käytännöt ja mallit voivat tehostaa so- velluksen suunnittelua, kehitysaikaa ja koodin ylläpitoa. (Scott, E., 2015, 5-6)
Tarkastellaan ensin perinteistä, SPA-mallista poikkeavaa verkkosovellusmallia. Tässä suunnitel- massa, jokaisesta uuden näkymän pyynnöstä seuraa kyselysarja palvelimen kautta. Kun käyttäjän puolella tarvitaan uutta dataa, pyyntö lähetetään palvelimen puolelle (Kuva 1). Palvelimen esittelyker- roksella pyynnön vastaanottaa ohjainolio, joka on vuorovaikutuksessa mallinnuskerrokseen palvelu- kerroksen kautta. Palvelukerros määrittelee mallinnuskerroksen vaatimat palaset. Kun data on haettu määritetystä lähteestä, tarvittavat muutokset tapahtuvat liiketoimintakerroksessa. Hallinta palautuu tämän jälkeen esittelykerrokselle, jossa asianmukainen näkymä valitaan. Hallintalogiikka määrittää sen, miten juuri haettu data ilmenee käyttäjän valitsemassa näkymässä. Kun tiedoston data ja nä- kymä ovat yhdistyneet, uusi näkymä palautuu selaimelle. Kun selain vastaanottaa uuden HTML-sivun ja käyttöliittymä päivittyy, käyttäjä näkee uuden näkymän. (Scott, E., 2015, 5-6)
7
Seuraavassa kuvassa 2 näkyy, miten sama tapaus toimisi, jos se olisi suunniteltu hyödyntäen SPA- mallia. On huomioitava, mitä esittelykerrokselle ja käyttäjän ja palvelimen väliselle transaktiolle tapah- tuu.
Siirtämällä näkymien luomis- ja hallintaprosessit käyttöliittymään, palvelimelta vapautuu resursseja muuhun suorittamiseen. Tässä mallissa MV*-sovelluskehys vastaa edellä mainituista prosesseista.
Myös käyttäjän ja palvelimen välinen kommunikaatio on muuttunut. Esittelylogiikan siirtyminen käyttä- jälle tarkoittaa sitä, että käyttäjän ja palvelimen välinen transaktio kuljettaa vain JSON-dataa. Tästä
Kuva 1: Perinteinen verkkosovellus
8
datan liikkuvuudesta vastaa käyttäjän puolella AJAX. Yleisesti katsottuna SPA-suunnitelma on hyvin samanlainen perinteiseen malliin verrattuna. Tärkeimmät muutokset ovat: a) ei tarvetta selaimen päi- vitykselle uuden näkymän saamiseksi, b) esittelylogiikan siirtyminen käyttäjän selaimelle ja c) palveli- men väliset transaktiot voivat sisältää vain dataa.
Kuva 2: SPA-mallin verkkosovellus
9
7 Sovelluskehys
Tässä opinnäytetyössä vertaillaan sovelluskehyksiä, mutta sovelluskehyksen määritelmä on hieman häilyvä, joten seuraavaksi avataan tätä termiä.
Sovelluskehys (software framework) on ohjelmistotuote, joka toimii runkona sen päälle rakennetta- valle ohjelmistolle. Sen tarkoituksena on nopeuttaa ohjelmistotuotteiden valmistumista tarjoten valmiita ohjelmiston osia kehittäjälleen. Runko ei itsessään toimi suoritettavana ohjelmana, vaan sen päälle on rakennettava haluttu ohjelmistotuote. (Techopedia, 2018)
Sovelluskehykset eroavat tavallisista kirjastoista siten, että ohjelman suoritusjärjestystä ohjaa vieraili- jan sijaan kehys. Ohjelmoija voi myös lisätä omia toiminnallisuuksiaan, muuttamatta kuitenkaan sovel- luskehyksen lähdekoodia. Kirjaston voi asettaa valmiiseen arkkitehtuuriin lisäten sen sisältämät toi- minnallisuudet. Sovelluskehys antaa kehittäjälleen valmiin arkkitehtuurin ja sovelluksen kehitystä on käytettävä sen asettamien sääntöjen mukaan. (Techopedia, 2018)
MVC(Model-View-Controller)-malli on sovelluskehityksessä yleinen ja siitä on kehitetty monta variaa- tiota. Model eli Malli edustaa tietoa ja se voi olla yksittäinen olio tai oliorakenne. View eli Näkymä on visuaalinen esitys tietomallista, joka tuo esille tiettyjä ominaisuuksia ja peittää toisia. Näkymä on riip- puvainen mallin antamasta tiedosta. Controller eli Ohjain toimii linkkinä käyttäjän ja järjestelmän vä- lillä. Se vastaa käyttäjän ja ohjelman välisestä vuorovaikutuksesta ja hallinnoi näkymiä oikeisiin paik- koihin käyttäjän syötteiden perusteella. Seuraavassa kuvassa 3 näkyy MVC-malli ja sen komponent- tien välinen kommunikaatio toistensa ja käyttäjän välillä.
10
AngularJS käyttää MVVM (Model-View-ViewModel) -mallia. Siinä näkymä toimii samalla tavalla, kuin MVC-mallissa, mutta ohjain on korvattu näkymämallilla. Näkymämalli voidaan nähdä säiliöoliona, josta näkymä hakee tarvitsemansa datan ja toiminnot. Näkymämallina AngularJS:ssä toimii ’$scope’- niminen olio. Kuvassa 4 näkyy AngularJS:n käyttämä MVVM -malli. (Nishanth, A. 2013.)
Kuva 3: MVC-malli (mukaillen Wikipedia s.a.)
Kuva 4: MVVM-malli
11
8 AngularJS
AngularJS on Googlen kehittämä JavaScriptille luotu sovelluskehys, joka laajentaa HTML:n syntaksia siten, että applikaatio pystyy ilmaisemaan sen komponentteja selkeästi ja ytimekkäästi. AngularJS:n datakapsuloinnin ja riippuvuuksien injektoinnin ansiosta koodin kirjoitustyö vähenee merkittävästi.
(Google 2018.)
AngularJS:n käyttäminen tuo ohjelmointiin monenlaisia hyötyjä. Ensinnäkin AngularJS on rakennettu siten, että koodin organisointi edistää ylläpitoa, yhteistyötä, luettavuutta ja laajennuksia. Testattavuu- den helppous on myös osa AngularJS:n vahvaa kokonaisuutta ja kaksisuuntainen datan sitominen vähentää koodin määrää tehden koodaamisesta tehokkaampaa. Myös integraatiota muiden Ja- vaScript-teknologioiden välille on helpotettu. AngularJS:llä voit hyödyntää POJO:a (Plain Old Ja- vaScript Objects) vastaanottamalla tai lähettämällä JavaScriptiä ilman paketoimisen tai sen avaami- sen tarvetta. Myös JSON-mallien vastaanottaminen palvelimelta onnistuu nopeasti AngularJS:n alku- latauskoodin suorituksen jälkeen. (Ruebbelke, L. 2015, 4-6)
8.1 Ominaisuudet
Moduulit
AngularJS:n moduulit ovat säiliöitä, jotka helpottavat AngularJS-sovelluksen koodin organisoimisessa.
Niitä voidaan verrata tavallisiin paketteihin Java-sovelluksissa. Moduulit voivat myös sisältää alimo- duuleita, joka edesauttaa ohjelmiston funktionaalisuutta. Moduulin rakenteeseen kuuluu alustuksen jälkeen parametrit; nimi ja taulukko. Taulukko-parametriin voidaan lisätä alimoduuleja, jos niille on tar- vetta. Paras käytäntö on ominaisuuksien jakaminen alimoduuleihin ja niiden injektointi sovelluksen päämoduuliin. (Ruebbelke, L. 2015, 6)
Kuvassa 5 näkyy myApp -nimisen moduulin alustus myModule nimiseen muuttujaan.
Kuva 5: Moduulin alustus
12
Kuvassa 6 myApp -moduuliin on injektoitu ngResource -moduuli.
Määritys
Määrityslohkon (config block) avulla AngularJS-sovellusta voidaan määritellä ennen kuin se ajetaan.
Tämä edesautaa mm. reitityksen pystyttämistä ja palvelujen määritystä. (Ruebbelke, L. 2015, 6)
Reitit
Reiteillä (routes) pystytään navigoimaan sovelluksen eri tilojen välillä. Ne mahdollistavat myös eri reit- tien määritysvaihtoehdot, kuten mitä mallia ja kontrolleria käyttää. (Ruebbelke, L. 2015, 6)
Näkymät
Näkymä (view) ilmenee kun AngularJS on koottu ja käännetty oliomalliliittymään (DOM). AngularJS on virallisesti Model-View-Whatever (MVW) -sovelluskehys. Sanalla ”Whatever” tarkoitetaan mitä ta- hansa rakennetta, joka mahdollistaa tehokkaimman tavan työskennellä. (Ruebbelke, L. 2015, 6-11)
$scope
$scope toimii eräänlaisena liimana näkymän (HTML) ja kontrollerin (JavaScript) välillä.
(Ruebbelke, L. 2015, 6)
Kontrollerit
Kontrolleri (controller) vastaa siitä, mitä metodeja ja ominaisuuksia näkymään voidaan sitoa ja mihin näkymä voi vaikuttaa. Hyvä kontrolleri on toiminnallisuudeltaan kevyt ja se on vuorovaikutuksessa ai- noastaan sen näkymän kanssa, jota se hallitsee. (Ruebbelke, L. 2015, 6)
Direktiivit
Sovelluskehittäjän perspektiivistä direktiivit (directive) ovat vain uudenlaisia HTML-tunnisteita. Ne ovatkin AngularJS:n tärkeimpiä työkaluja ja joka erottaa sen muista käyttäjäpuolen sovelluskehyk- sistä. Direktiivit ovat näkymään lisättäviä ja uudelleen käytettäviä elementtejä, joihin voi kapsuloida toiminnallisuutta. Direktiivien takia ei ole enää tarvetta luoda malliluokkia ja paljolta koodin kirjoituk- selta säästyy. Yleisesti käytettyjä direktiivejä ovat mm. ngModel, ngView ja ngRepeat.
(Williamson, K. 2015, 1-3)
Kuva 6: Alimoduulin lisäys moduuliin
13 Palvelut
Palvelut tarjoavat yleistä käytettävyyttä AngularJS-sovellukselle. Palvelu tarjoaa mm. mahdollisuuden jakaa saman datan monelle eri kontrollerille. Kehittäjä voi myös tehdä oma palvelun haluamillaan omi- naisuuksilla. (Ruebbelke, L. 2015, 58-59)
8.2 Rakenne
AngularJS on JavaScript-sovelluskehys, joka sitoo HTML-näkymään Javascript-olioita luoden raken- teellisen ja ylläpidettävän verkkosovelluksen. Se mahdollistaa HTML:n käyttämisen mallipohjana lisä- ten selkeyttä sen syntaksiin. AngularJS:n datan sitominen ja riippuvuusinjektio vähentävät kirjoitetta- van koodin määrää. Koko koodin suoritustyö tapahtuu selaimessa tehden siitä mielekkään kumppanin kaikille palvelinteknologioille. AngularJS rakennettiin siinä uskossa, että deklaratiivinen ohjelmointi on parempi kuin imperatiivinen, kun rakennetaan käyttöliittymää ja kytketään ohjelmistokomponentteja yhteen. Imperatiivinen koodi on erinomaista taas liiketoimintalogiikan ilmaisussa.
(Ruebbelke, L. 2015, 18-19)
9 ReactJS
ReactJS on Facebookin kehittämä sovelluskehys, joka julkaistiin vuonna 2013 ja sen tarkoituksena oli korjata yleisiä ongelmia, joita ilmeni paljon tietoa ohjaavissa verkkosivuissa. Perinteiset verkkosivut koostuivat yksilöllisistä HTML-sivuista ja käyttäjän navigoidessa selain pyysi ja latasi uuden HTML- dokumentin. Kun AJAX keksittiin, alkoi SPA (Single-Page Application) -sovellusten nousu. SPA-sovel- luksessa, käyttäjä lataa sivulla navigoidessaan vain yhtä HTML-dokumenttia, koska JavaScriptillä piti huolen siitä, että vain valittu koodi ajettiin. Tämä tarkoitti sitä, että JavaScript tuhosi ja loi uuden HTML-dokumentin, kun käyttäjä oli vuorovaikutuksessa sivuun. Huonoa tässä oli se, että käyttäjä la- tasi aina uuden sivun verkkosivulla navigoidessaan, vaikka kyseessä olisi ollut vain pieni muutos si- vun näkymässä. (Porcello, E. & Banks, A. 2017, 61-62)
Uusissa ReactJS:iä hyödyntävissä SPA-sovelluksissa käyttäjä ei siirry uudelle sivulle tai lataa sivua uudelleen. Sen sijaan sovelluksen eri näkymät latautuvat ja poistuvat samalla sivulla. ReactJS siis kapsuloi komponentteja siten, että ne hallinnoivat omaa tilaansa.
(Porcello, E. & Banks, A. 2017, 61-62)
ReactJS ei ole varsinaisesti MVC -sovelluskehys vaan enemmänkin kirjasto, jolla rakentaa koottavia käyttöliittymiä. ReactJS voidaan siis nähdä View -osuutena MVC-sovelluskehyksessä. ReactJS:n yk- sisuuntainen tietovirta käsitellään kuvan avulla luvussa 12.
14
9.1 Ominaisuudet
JSX
JSX (JavaScript XML) on esikäsittelyn vaihe, joka lisää XML-syntaksia JavaScriptiin. ReactJS ei tar- vitse sitä toimiakseen, mutta se tekee ReactJS:stä elegantimman näköistä. JSX on syntaksin laajen- nus eli se ei ole pätevää JavaScriptiä, koska selaimet eivät pysty lukemaan sitä. Jos JavaScript-tie- dosto sisältää JSX-koodia, niin kyseinen tiedosto on käännettävä. Eli kun tiedosto kohtaa selaimen, JSX-kääntäjä kääntää kaiken JSX-koodin tavalliseksi JavaScriptiksi.
(Porcello, E. & Banks, A. 2017, 81-85)
JSX on staattisesti tyypitetty olio-ohjelmointikieli, joka on suunniteltu ajettavaksi moderneilla verk- koselaimilla. Se suorittaa optimointia, kun sitä kootaan suoraan JavaScriptiksi. Tuotettu koodi suoriu- tuu nopeammin, kuin verrattavissa oleva koodi, joka on kirjoitettu suoraan JavaScriptillä. Jopa opti- moidut JavaScript-kirjastot ovat nopeampia JSX-siirron jälkeen. (DeNa Co., Ltd. 2013.)
JSX on myös turvallisempaa kuin JavaScript, koska se on staattisesti tyypitetty ja pääasiassa tyyppi- turvallinen. Sovelluksen laatutaso kasvaa JSX:ää käytettäessä, koska monet ohjelmointivirheet saa- daan selville jo kokoamisvaiheessa. (DeNa Co., Ltd. 2013.)
Lisäksi JSX tarjoaa vankan luokkajärjestelmän vapauttaen kehittäjät primitiivisistä prototyyppipohjai- sista periytyvyyksistä. Ilmaisut ja lauseet ovat pääasiassa saman tasoisia kuin JavaScriptissä, joten JSX:n omaksuminen on JavaScript-kehittäjälle helpompaa (DeNa Co., Ltd. 2013.). Seuraavassa ku- vassa 7 näytetään ReactJS:n render -function käyttötapaus JSX:n kanssa ja ilman.
15 Elementit
JSX:n perusyksikköä kutsutaan elementiksi. Se näyttää samalta kuin HTML-elementti, mutta se sijait- see JavaScript-tiedostossa. Nämä JSX-elementtejä kohdellaan kuin JavaScriptin ilmaisuja. Tämä tar- koittaa, että JSX-elementti voidaan tallentaa muuttujaan, siirtää funktioon, asettaa olioon tai tauluk- koon. HTML-elementtien tavoin JSX-elementeille voi antaa ominaisuuksia. (Facebook 2019.)
Render
Render on ReactDOM JavaScript-kirjastossa sijaitseva metodi, joka vastaanottaa JSX-ilmaisun, luo siitä oliomalliliittymäpuun ja lisää puun oliomalliliittymään. Tällä tavoin JSX-ilmaisu tulee näkyviin näy- tölle. (Facebook 2019.)
Virtuaalinen oliomalliliittymä
ReactJS käyttää virtuaalista oliomalliliittymää (virtual DOM), joka on kevyt dokumentin edustus. Virtu- aalinen oliomalliliittymä rakentuu ReactJS:n komponenteista. Kun JSX-elementti käännetään, jokai- nen yksittäinen virtuaaliolioliittymän olio päivitetään. Virtuaaliolioliittymän päivitettyään, ReactJS ver- taa sitä tilaan, missä se oli ennen päivitystä ja vahvistaa, mitkä oliot muuttuivat. Tämän jälkeen aino- astaan muuttuneet virtuaalioliomalliliittymän oliot, muutetaan oikeassa oliomalliliittymässä. Vasta nämä muutokset näkyvät näytöllä käyttäjälle. (Facebook 2019.)
ReactJS käyttää tämän ominaisuuden saavuttamiseksi diff-algoritmiä. Jos verrattavilla juurielemen- teillä on eri tyypit ReactJS korvaa vanhan puun kokonaan uudella. Kuvassa 8 näkyy kun div -juurinen elementtipuu korvaantuu kokonaan, koska se eroaa span-juurityypistä.
Kuva 7: render -funktion luonti JSX:llä ja ilman
16
On myös tilanteita, missä juurielementeillä on sama tyyppi. Niissä tapauksissa vain arvo muuttuu uu- teen. Kuvassa 9 elementtipuut ovat molemmat juurityypiltänsä divejä, joten vain className -muuttu- jan arvo vaihtuu. (Facebook 2019.)
Komponentti
Kun ReactJS-sovelluksessa luodaan luokkakomponenttia, tarvitaan React.createClass-metodia. Jo- kaisessa komponentissa on props-olio, jonka avulla tietoa voidaan näyttää komponentista toiseen.
Prop-olioiden avulla voidaan myös tehdä muita ohjelmallisia päätöksiä. (Facebook 2019.)
Komponentin tila (state) on samanlainen kuin props-olio, mutta se on yksityinen ja komponentin täysin kontrolloima. (Facebook 2019.)
Kuva 9: className -attribuutin arvo ”before” korvaantuu arvoksi
”after”
Kuva 8: div -juurityypin ja span -juurityypin elementtipuun esittely
17
9.2 Rakenne
ReactJS:n komponenttien tehtävä on kuvailla se, mikä tulee renderöidä. Renderöinti on komponentin rakentamista tietyn logiikan mukaisesti. Tähän käytetään tietysti render()-metodia, mutta usein sen käyttäminen ei yksinään riitä kehittäjän tarpeisiin. Mitä jos halutaankin tehdä jotain ennen tai jälkeen komponentin renderöinnin? Siinä tapauksessa tarvitaan lisää hallintaa niiden tilojen välillä, joita kom- ponentti käy läpi. (Facebook 2019.)
Prosessi, johon kaikki komponentin käymät vaiheet kuuluvat, on nimeltään komponentin elinkaari ja jokainen ReactJS-komponentti käy sen läpi. ReactJS:ssä on monta metodia, jotka osoittavat, milloin mikäkin vaihe on käynnissä. (Facebook 2019.)
Näitä metodeja kutsutaan komponentin elinkaarimetodeiksi ja ne kutsutaan ennustettavassa järjestyk- sessä. ReactJS-komponentin elinkaarimetodit voidaan jakaa neljään vaiheeseen: alustus, asennus, päivitys ja irroitus. (Facebook 2019.)
Alustus
Alustus (initialization) on vaihe, missä määritellään oletus- ja alkuarvot this.props:lle ja this.state:lle.
Niiden määrittelyssä käytetään getDefaultProps() ja getInitialState()-funktioita. On kaksi tapaa alustaa komponentti: API-kutsun tekeminen ja datan kuljettaminen window-olion avulla.
(Mora 22.5.2016.)
Asennus
Asennus (mounting) tapahtuu kun, komponentti lisätään oliomalliliittymään. Tässä vaiheessa voidaan käyttää metodeita componentWillMount() ja componentDidMount(). Metodia componentWillMount() kutsutaan ensin ja sitä kutsutaan kerran. Tämä tapahtuu välittömästi alustavan renderöinnin jälkeen juuri ennen kuin ReactJS asettaa komponentin oliomalliliittymään. On hyvä tietää, että this.setState:n kutsuminen tässä metodissa ei laukaise uudelleen renderöintiä.
Seuraavaksi kutsutaan metodia componentDidMount() vain kerran heti sen jälkeen, kun ReactJS asettaa komponentin oliomalliliittymään. Nyt päivitetty oliomalliliittymä on valmiina käytettäväksi.
Tämä vaihe on siitä syystä paras sijainti muiden JavaScript-kirjastojen alustamiseen, jotka tarvitsevat yhteyttä oliomalliliittymään ja datankeräysoperaatioihinsa. (Mora 22.5.2016.)
Päivitys
On olemassa metodeita, jotka mahdollistavat koodin suorituksen, kun komponentin tilaa tai ominai- suuksia päivitetään ja ne kutsutaan seuraavassa järjestyksessä:
1. componentWillReceiveProps
18 2. shouldComponentUpdate
3. componentWillUpdate 4. render
5. componentDidUpdate
Tässä vaiheessa ReactJS-komponentti on jo asetettu oliomalliliittymään, joten näitä metodeja ei kut- suta ensimmäiseen renderöintiin. Ensimmäinen metodi, componentWillReceiveProps(), kutsutaan, kun komponentti vastaanottaa uusia ominaisuuksia. Voimme käyttää tätä metodia vaikuttaaksemme ominaisuuden muutokseen ennen kuin se renderöidään. Kutsumalla this.setState() -metodia funktion sisällä uudelleen renderöinti ei laukea. (Mora 22.5.2016.)
Metodi shouldComponentUpdate() antaa mahdollisuuden päättää, laukaiseeko seuraavan komponen- tin tila uudelleen renderöinnin vai ei. Kyseinen metodi palauttaa boolean arvon, jonka vakio on tosi. Ja jos asetamme sen epätodeksi niin seuraavia metodeja ei kutsutakaan: componentWillUpdate() , ren- der() , componentDidUpdate. Kehityksessä tulisi käyttää shouldComponentUpdate()-metodia, jos suo- rituksessa on pullonkaula. Metodi on erityisen hyödyllinen silloin, kun käytössä on tusinoittain tai sa- doittain komponentteja, jolloin renderöinti on erityisen paljon suoritusta vaativaa. (Mora 22.5.2016.)
Irrotus
ReactJS tarjoaa tähän vaiheeseen vain yhden metodin: componentWillUnmount(). Sitä kutsutaan heti sen jälkeen, kun komponentti on irrotettu oliomalliliittymästä. Sitä voidaan käyttää ajastinten mitätöimi- seen tai niiden oliomalliliittymän elementtien siivoamiseen, jotka luotiin componentDidMount() tai com- ponentDidUpdate-metodien toimesta. ReactJS mahdollistaa metodien kutsumisen koko komponentin elinkaaren ajan. (Mora 22.5.2016.)
19
10 Tutkimuksen suunnittelu
Tutkimuksessa vertaillaan kahta hyvin samanlaisiin tarkoitusperiin käytettyä JavaScript-sovelluske- hystä ja sen on suunniteltu sisältävän kaksi CRUD-sovellusta, jotka toimivat vertailun kohteina. En- simmäisessä on käytetty AngularJS:iä ja toisessa ReactJS:iä. Molemmissa sovelluksissa käytetään yhteistä MongoDB-tietokantaa. Kyseessä on siis kahden teknologian laadullinen vertailu käytännönlä- heisessä viitekehyksessä. Vertailussa keskitytään sovellusten rakenteellisiin ominaisuuksiin, ylläpidet- tävyyteen, koodin luettavuuteen ja sovelluksen pystytykseen.
Tutkimuksen tavoitteena on saada hyvä käsitys vertailtavista sovelluskehyksistä, jotta voisi muodos- taa näkemyksen siitä kumman opettelu olisi hyödyllisempää. Tutkimuksen aiheeseen johdatteli kysy- mys: Mitä JavaScript-sovelluskehystä kannattaisi opetella? Siispä tutkimus aloitettiin opiskelemalla JavaScript-sovelluskehyksiä ja tutkimuksen aloitusajankohtana eniten suosiota ja näkyvyyttä olivat saavuttaneet AngularJS ja ReactJS, joten nämä valittiin. Tutkimus haluttiin toteuttaa käytännönlähei- senä oppimiskokemusta korostaen, joten siksi teknologioiden vertailu tapahtuu kahden sovelluksen avulla. Myös muita teknologioita oli opeteltava, koska sovellukset käyttävät MEAN- ja MERN-pakkoja.
Sovellusten ominaisuuden rajattiin CRUD-ominaisuuksiin, koska se nähtiin tarpeeksi yksinkertaisena ja hyödyllisenä rajauksena vertailun suhteen. Alla oleva käyttötapauskaavio (Kuva 10) kuvaa sitä, mitä käyttäjä voi tehdä sovelluksella.
20
Kuva 10 Sovellusten noudattama käyttötapauskaavio
21
11 Tutkimuksen toteutus
Tutkimukseen sisältyy kahden CRUD-sovelluksen luominen. Sovelluksissa käytetään vertailta- vien kirjastojen lisäksi myös muita JavaScript-teknologioita. Ne ovat Node.js, Express.js ja Mon- goDB. Tutkimuksen alustus aloitetaan pystyttämällä MongoDB-kokoelma seuraavasti: Luo kan- siopolku, jonne MongoDB asennetaan. Suorita komento:
mongod.exe –dbpath ”c:\data\db\”
Nyt tietokanta on pystyssä. Seuraavaksi ajetaan MongoDB-ohjelma komennolla mongo.exe
bin-kansiossa täten päästen käsiksi tietokantaan. Nyt on mahdollista rakentaa tietokanta omien vaatimustensa mukaisesti.
Yhteys tietokantaan:
-Avaa kaksi komentoriviä
-Siirry kahdella ensimmäisellä kansioon, minne MongoDB on asennettu (esim. mongodb\bin\), joissa suoritetaan seuraavassa järjestyksessä kyseiset komennot:
Komentorivi 1: mongod.exe Komentorivi 2: mongo.exe
Ympäristön asennus:
Ensiksi asennetaan Node.js (nodejs.org). Node.js:n asennuksen jälkeen asennetaan Express.js verkkosovelluksen reitityksen helpottamiseksi:
-Luodaan erilliset kansiot projekteille.
-Luodaan server.js-tiedosto, jonne kirjoitetaan reititykset Express.js:iä hyödyntäen. (Kuva 11) -Suoritetaan komento ”npm init” sovelluksen pääkansiossa, rakentaen package.json-dokumentin ja node_modules-kansion, moduulien ylläpitoa varten.
-Luodaan public-kansio, jonne luodaan alikansiot css- ja javascript-tiedostoille.
-Luodaan index.html.
-npm install <moduulin nimi> -komennolla tulee ladata express, mongojs ja body-parser.
-Luodaan controllers-alikansio, js-kansion sisälle.
-Luodaan maincontroller.js, jonka koodin tulee sisältää sovelluksen kaikki CRUD -toiminnallisuu- det.
-Navigoi AngularJS-sovelluksen pääkansioon, missä server.js sijaitsee.
-Avaa uusi komentorivi ja suorita komento ”node server.js”.
22 Käytetyt moduulit:
Express on moduuli, joka toimii minimalistisena verkkosovelluskehyksenä Node.js:lle. Se sisältää muun muassa http-avustajat, jotka tekevät server.js-koodin reitityksestä luettavampaa.
Mongojs-moduulin avulla luodaan tietokantayhteys, jonka kautta kaikki muutokset tietokantaan toteutuvat. Moduuli toimii tässä sovelluksessa samalla tavalla kuin mongo-sovellusohjelmointira- japinta paitsi, että käytössä on callback-metodi.
Body-parser-moduuli kääntää tietokannasta haetut tiedot mielekkään näköisiksi taulukoiksi, en- nen kuin tieto siirtyy kontrollerin käsiteltäväksi.
11.1 AngularJS-sovellus
Aluksi luetellaan sovelluksen eri ominaisuudet, jotta saa käsityksen siitä, mistä kyseinen tutkimus koostuu.
Server.js sisältää tietoliikenteen kaikki kriittiset toiminnot. Siellä käytetään myös kaikkia aikaisemmin esiteltyjä moduuleita. Tiedoston alussa on alustettu kaikki sovelluksen käyttämät moduulit omiin muut- tujiinsa (Kuva 12, rivit 1-5). Tämän jälkeen moduuleja hyödyntämällä otetaan yhteys tietokantaan ja kutsutaan sen sisältämää tietorakennetta. Tämä tieto muutetaan luettavampaan muotoon bodyParser -moduulin avulla. Tiedoston funktiot tekevät komentoja tietokantaan MongoDB -komentojen [find(), insert(), remove(), findOne() and findAndModify() avulla (Kuva 12, rivit 10-47)] avulla ja näitä operaati- oita avustaa mongojs -moduuli. Funktioiden ensimmäinen parametri req (request) määrää sen mitä
Kuva 11 AngularJS-projektin hakemistorakenne
23
pyydetään ja toinen parametri res (response) sen mitä vastataan. Vastaukset on laitettu tulostamaan konsoliin kokoelman sisältämät tiedot.
Aikaisemmin alustetulla $https -rakentajatoiminnolla (Kuva 12) tehdään tietokantahaku MongoDB ko- koelmaan nimeltään myproducts. Jos funktio suoriutuu, tulostetaan viesti verkkoselaimen konsoliin onnistumisesta sekä kokoelman tieto muutoksen jälkeen. Epäonnistumiselle on varattu oma funktio viesteineen.
Kuva 12: server.js -tiedosto, jossa alustetaan ohjelman moduulit ja tehdään tietokantahaut
24
Kuvassa 13 kontrolleri aloitetaan alustamalla sovelluksen käyttämä moduuli myApp. Tämän jälkeen moduulilla luodaan kontrolleri, jolle annetaan nimeksi MainController. Jotta kontrolleri voi reagoida ha- luttuihin tapahtumiin tai suorittaa laskentoja, on siihen asetettava rakentajatoiminnot ($scope ja
$https). Näitä olioita käyttämällä tieto liikkuu käyttöliittymän ja palvelinpuolen välillä.
Seuraavaksi MainControlleriin rakennetaan funktiot, jotka tekevät halutut tietokantakomennot: Create, Read, Update ja Delete (Kuva 14). CRUD -toiminnot on asetettu $scope -olion sisään ja refresh -funk- tio päivittää tiedot, jos käytetty komento suoriutuu onnistuneesti. CRUD -toiminnot menevät yksi yh- teen funktioiden kanssa poislukien Update -toiminto, joka on jaettu editItemiin ja updateItemiin. Metodi editItem kerää valitun dokumentin tiedot, jotka näytetään käyttäjälle ja mahdollistaa niiden muokkauk- sen. Käyttäjä voi tällöin muokata valitsemaansa dokumenttia ja muokkauksen jälkeen kutsua updateI- tem-metodia, joka tallentaa muutokset tietokantaan.
Kuva 13: myApp -moduulin alustus valituilla rakentajatoiminnoilla
25
Näkymästä vastaa index.html, joka on yhteydessä MainControlleriin, toimien käyttäjän rajapintana tie- tokantaan. Tämä onnistuu käyttämällä AngularJS:n direktiiviä ng-controller (Kuva 15, rivi 21). Kun controlleri on alustettu tiedostoon, voidaan käyttää ng-modelia kuljettamaan tietomallia kontrollerista Kuva 14: MainController -tiedoston CRUD -toiminnallisuudet
26
näkymään. Ng-click (Kuva 15, rivit 41-42 ja 49-50) sitoo MainControllerin funktiot nappeihin ja ng-re- peat auttaa saamaan nopeasti kaikki halutut tiedot toistosilmukassa.
AngularJS-sovelluksen näkymässä näytetään tietokannasta haettujen dokumenttien avain-arvo-parit.
Syöttökenttien rivillä on myös Clear-nappi, joka tyhjentää kaikki kentät valitusta dokumentista. Seu- raavassa kuvassa (Kuva 16) näkyy sovelluksen käyttöliittymä.
Kuva 15 Näkymästä vastaava index.html
27 12.2 ReactJS -sovellus
ReactJS-sovelluksessa hyödynnetään samaa MongoDB-tietokantaa, joten server.js -tiedosto on hyvin samanlainen ja samaa asiaa ajava, kuin AngularJS-sovelluksessa. ReactJS-sovellus käyttää myös samoja node -moduuleita, jotka on käsitelty jo aikaisemmin.
ReactJS-sovelluksen rakennus aloitetaan index.js -tiedostosta, jossa sovellus luodaan (Kuva 17).
App-nimistä komponenttia kutsutaan index.html -tiedostossa, jossa virtuaalisen oliomalliliittymän ra- kentama koodi viimein näytetään.
Kuva 16: AngularJS-sovelluksen näkymä sisältäen CRUD-toiminnallisuudet
28
Tiedosto, jossa eri ReactJS-komponentit kutsutaan, on nimeltään App.js. Sen koodissa kutsutaan muita, eri tiedostoissa koottuja, komponentteja. Ne alustetaan halutulla tavalla ja niihin voi vaikuttaa App.js:n sisäisillä muuttujilla.
ReactJS:a on ohjelmoitu ES6-syntaksilla ja se mahdollistaa muun muassa luokkien rakentamisen Ja- vaSciptillä, class-nimikkeen muodossa sekä siistimmän koodin ulkoasun. Koodissa käytetään myös JSX-syntaksia luettavuuden helpottamiseksi. ReactJS:n keskiössä on Component-luokka, jonka peri- mällä luokista tulee ReactJS-komponentteja. Omien luokkien luomista ei katsota hyvällä, koska koo- din uudelleenkäyttö tapahtuu pääasiassa rakenteellisesti eikä periytyvyyden avulla.
App.js -tiedoston alussa kutsutaan, import-nimikkeellä, ne tiedostot mitä halutaan käyttää, jonka jäl- keen alustetaan luokka. Ensimmäisenä tulee alustaa rakentaja (constructor), jonka tehtäviin kuuluu paikallisen tilan (local state) alustus, asettamalla this.state -muuttujaan olio, sekä sitomalla tapahtu- makäsittelijämetodeita (esim. onClick) komponentin ilmentymään. Seuraavaksi alustetaan com- ponentWillMount -metodi (Kuva 18, rivi 39-43), jota kutsutaan, kun komponentin ilmentymää luodaan ja ollaan asettamassa oliomalliliittymään.
Seuraavaksi luodaan funktiot, jotka ylläpitävät ajankohtaista tietoa tuotteista, jotta poistot ja muok- kaukset oikeasti tallentuvat näkymään (Kuva 18, rivit 49-82). Lopuksi renderöidään tiedostossa alus- tetut ja kutsutut ReactJS-komponentit ja muu HTML:n näköinen koodi (Kuva 19 rivit 93-114)
Kuva 17: index.js renderöi App-komponentin, jota kutsutaan index.html-tiedostossa root-nimellä
29
Kuva 18: App.js:n ReactJS-komponentissa luodaan rakentaja, tila ja sovelluksen näkymään vaikuttavat funktiot
30
Sovelluksen CRUD-toiminnallisuudet on jaettu luomisen ja muiden toimintojen kesken. Uuden tuot- teen tapahtuu AddProduct.js -tiedostossa ja ProductItem.js:ssä mahdollistetaan poisto ja muokkaus.
ProductItem.js:n rakentajaan sidotaan luokan metodit, koodin säästämiseksi. Metodeita kutsutaan render() -osiossa riippuen siitä, onko tila is.Edit tosi vai epätosi, joten oikeat napit tulevat näkyviin muokkaustilan mukaan.
Kuva 19: App.js:n renderöintiosuus rakentaa käyttäjälle lopullisen näkymän
31
Kuva 20: ProductItem.js:n poisto- ja muokkaustoiminnot
32
Uuden tuotteen luominen tapahtuu AddProduct.js -tiedostolla. Luokan onSubmit -metodi kerää käyttä- jän syöttämät tiedot ja kuljettaa ne App.js:iin, jossa niistä rakennetaan uusi tuote listalle. Metodin lo- pussa käyttäjältä saadut tiedot tyhjennetään, jotta ne eivät enää näy käyttäjälle (Kuva 21).
Kuva 21: AddProduct.js:n uuden tuotteen luominen
33
12 Tulokset
Seuraavaksi tutkimuksen tulokset käydään läpi vertailemalla edellä käsiteltyjä sovelluskehyksiä ja niillä rakennettuja sovelluksia. Vertailu tapahtuu kvalitatiivisesti eli laadullisesti ja siinä keskitytään tär- keäksi havaittuihin indikaattoreihin kuten rakenteellisiin ominaisuuksiin, ylläpidettävyyteen, koodin lu- ettavuuteen ja sovelluksen pystytykseen.
Rakenteelliset ominaisuudet
Sovelluskehyksinä AngularJS:n ja ReactJS:n rakenne eroaa suuresti toisistaan. Ensinnäkin Angu- larJS sisältää sekä näkymä- että malliosuuden sovellusarkkitehtuurista kun taas ReactJS tekee ra- kenteellisia muutoksia vain näkymä-osuuteen. Tästä voi siis tehdä sen tulkinnan, että ReactJS ei oi- keastaan edes ole sovelluskehys lainkaan, koska sen ainoa rakenteellinen vaikutus on sovelluksen näkymään. Siinä mielessä voitaisiin sanoa, että ReactJS on lähempänä JavaScript-kirjastoa kuten jQuery, kuin varsinaista sovelluskehystä. Toisaalta ReactJS:n rakenne ja sen taustalla oleva kom- ponentteihin keskittynyt filosofia siirtää sitä enemmän sovelluskehitysten maailmaan, vaikkakin sen rakenne on keskittynyt vain näkymään.
Semanttisesta erosta riippumatta tutkimus aloitettiin siinä ajatuksessa, että kyseessä oli kaksi kilpaile- vaa sovelluskehystä, koska molemmat olivat nousseet valtavirran suosioon samoihin aikoihin ja ne tarjosivat omalta osaltaan työkaluja kehittäjille web-sovelluskehityksessä. Sovelluskehyksenä Angu- larJS tarjoaa suuremmat rakenteelliset vaikutukset sovellukseen, mutta samalla se lukitsee kehittäjän käyttämään juuri kyseistä kehystä mallin ja näkymän suhteen. ReactJS:n toimiessa vain sovelluksen näkymäosassa, sen vaihtaminen ei ole yhtä haastavaa kuin AngularJS:n kokoisen sovelluskehyksen.
Lisäksi ReactJS:iä käyttäessä jää vapaus valita malli- ja ohjain-osat ohjelmaansa, jos aikoo kehittää MVC-mallin mukaisesti. Seuraavassa kuvassa (Kuva 22) näytetään miten rakenteet eroavat rakennet- tujen sovellusten välillä.
34
Sovellusten rakenne on tietokannan ja siihen yhteydenoton suhteen hyvin samanlainen. Molemmat sovellukset hyödyntävät MongoDB-tietokantaa ja server.js hoitaa tietokantakutsut. Suurin ero sovel- lusten välillä syntyy siinä, kun tietokannasta vastaanotettua tietoa aletaan hyödyntämään. AngularJS käsittelee tietoa maincontroller.js-tiedostossa, hyödyntäen http-metodeita sitoen ne $scope-olioon.
ReactJS:ssä dataa kutsutaan App.js-tiedoston App-komponentissa, jonka sisällä alustetaan muut so- velluksen käyttämät komponentit. App-komponentit alustamat komponentit hyödyntävät dataa oman logiikkansa mukaisesti mahdollistaen CRUD-toiminnallisuudet sovellukselle.
Sovelluksen näkymäosuudessa sovelluskehysten ero korostuu eniten. AngularJS:n hyödyntämä kak- sisuuntainen datan sitominen ohjaimen ja näkymän välille tapahtuu direktiivien kuten ng-controllerin avulla. Direktiivit alustetaan HTML-tiedoston elementteihin mahdollistaen datan siirtymisen käyttäjälle.
ReactJS toteuttaa datan siirtoa näkymään eri tavalla. ReactJS:ssa App-komponentti kutsutaan in- dex.js-tiedostossa ja se sidotaan nimettyyn div-elementtiin, joka sijaitsee index.html-tiedostossa. Näin
Kuva 22: Sovelluskehyksien välinen ero datan kuljetuksessa
35
moneen kertaan render-metodilla rakennettu virtuaalinen oliomalliliittymäpuu näkyy vihdoin käyttä- jälle.
Kuva 23: Sovelluskehysten komponenttien tehtävä datan kuljetuksessa
36
Kuvassa 23 näkyy miten, ReactJS -kirjaston avulla luodaan ReactJS-elementtejä ja niiden tiloja hallin- noidaan. Tämä siis eroaa AngularJS:n tavasta kiinnittää oliomalliliittymään kontrollereita ja kuljettaa dataa $scope -oliolla html-elementteihin. Html-elementeiltä näyttävät JSX-komponentit ensiksi aluste- taan, jonka jälkeen niitä tuodaan näkyviin yksitellen, mikäli joku osa virtuaalioliomalliliittymässä on muuttunut. Virtuaalioliolmalliliittymän käyttö mahdollistaa nopeamman tiedonsiirron verrattuna tavalli- seen oliomalliliittymään, jota käytetään AngularJS:n tapauksessa. Apps.js-tiedostossa sijaitseva App- komponentti lähettää sen alikomponentteihin niiden tarvitsemaa dataa, jotka vuorostaan lähettävät sitä takaisin oman sisäisen logiikkansa mukaisesti.
Ylläpidettävyys
Aikana, jolloin tutkimus aloitettiin AngularJS oli käymässä läpi suurta murrosta. Tutkimuksen aikana AngularJS oli kehittynyt paljon käyden läpi versiot Angular 2 ja 4, joiden aikana Angular-arkkitehtuuri ohjelmoitiin uudelleen käyttämällä TypeScriptiä. TypeScript on tarkka syntaktinen lisäosa, joka lisää valinnaisen staattisen tyypityksen JavaScriptille. Tämän perusteella tutkimuksessa käytetyn Angu- larJS:n (Angular 1) ylläpito on huomattavasti heikommassa asemassa, koska sitä ei enää ylläpidetä.
Tämä on suuri heikkous, koska teknologian yksi valintakriteeri on se, että sitä ylläpidetään. Ei ole pal- jon hyötyä käyttää teknologiaa, jota kukaan muu ei käytä ja joka ei kehity.
ReactJS:n kehitys on sen sijaan pysynyt rakenteellisesti hyvin samana, joten tutkimuksessa valmistu- neen ReactJS-sovelluksen päivitys ei vaatisi kovinkaan paljon työtä. Myös se, että ReactJS:iä ediste- tään aktiivisesti Facebookin toimesta, ylläpitää sen suosiota JavaScript-kehittäjien keskuudessa.
Koodin luettavuus
AngularJS:n koodi on JavaScriptiä, joten siihen tottuneelle AngularJS:n ymmärtäminen ei vaadi suuria ponnistuksia. On hyvä huomioida, että kontrollereita tehdessä kannattaa rakentaa ne omiin tiedos- toihinsa, jotta tiedostojen koodirivimäärät eivät kasva liian suuriksi. AngularJS:n koodin näkyvyys pää- asiallisella html-sivulla on helposti ymmärrettävissä. Direktiivit sidotaan html-elementteihin, jotta kon- rollereiden tiedot saadan kuljetettua näkymään ja se on ainoa muutos, mikä erottaa tavallisen ja An- gularJS:n hyödyntämän html-pääsivun.
ReactJS:n koodauksessa tulee omaksua erilainen lähestymistapa koodin tuottamiseen, kuin Angu- larJS:ssä. Siinä keskitytään yksittäisten komponenttien tilojen ja muutosten hallitsemiseen, joten koo- dauksessa tulee edetä yksi JSX-komponentti kerrallaan. Toisin kuin AngularJS:n hyödyntämät kont- rollerit, ReactJS:ssä komponentteihin itseensä koodataan ne säännöt, joiden mukaan niiden tulisi nä- kyä, kadota näkyvistä ja muuttaa muotoaan. Komponentteja luodessa on hyvä huomioida se, että koodi näyttää huomattavasti erilaiselta, jos käytössä on JSX. ReactJS:n käyttö ei vaadi toimiakseen JSX-lisäystä, mutta sen avulla koodia on huomattavasti helpompi lukea. Tämä johtuu siitä, että JSX- elementit näyttävät html-elementeiltä. JSX:n kanssa on järkevää käyttää myös JavaScript-kääntäjää nimeltä Babel. Sitä ylläpidetään aktiivisesti ja se mahdollistaa JSX:n kääntämisen vaivattomasti eikä tällöin tarvitse itse koodata kääntäjää.
Sovelluksen pystytys
37
Sovellusten pystytyksessä havaittiin myös suuria eroja. Molemmat sovelluskehykset vaativat toimiak- seen rakenteellisen logiikkansa sisältävät tiedostonsa. Tämän lisäksi on hyvä ladata molempien so- vellusten vaatimat Node-moduulit, jotta palvelimen kanssa työskentely olisi mahdollisimman vaiva- tonta. On huomioitava, että ReactJS vaati tämän lisäksi muita moduuleita kuten Babel, joka mahdol- listaa JSX:n toimivuuden ja nodemon, joka ajaa palvelimen automaattisesti uudelleen, jos siihen on tehty muutoksia.
AngularJS:n pystytys ei vaatinut suurempaa ymmärrystä Node-moduuleista, koska niiden käyttö ei ole välttämätöntä tai yleinen käytäntö. ReactJS:n tapauksessa Node-moduulien asennus on muodostunut käytännöksi ja välttäen laajempaa tutkimista päätin toimia yleisten tavan mukaisesti ReactJS-kehityk- sen suhteen ja ladata tärkeäksi havaitut moduulit.
13 Pohdinta
Tutkimus aloitettiin, jotta tekijä oppisi kahden samaan aikaan suosioon nousseen JavaScript-kirjaston perusteet ja ymmärtäisi mistä niiden suosio johtuu. Merkittävä osa tutkimusta on tietysti hahmottaa niiden eroavaisuudet. Tutkimuksessa käytetään myös muita yleistyneitä teknologioita. Tietokantana hyödynnetään MongoDB:tä, koska sitä käyttämällä JavaScriptiä voidaan hyödyntää sekä selain- että palvelinpuolella. Tietokannan valintaan vaikutti myös se, että MongoDB oli tunnetuimpia NoSQL-tieto- kantoja ja tekijällä ei ollut aikaisempaa kokemusta niiden käytöstä.
Tutkimuksen aikana tekijälle selvisi, se kuinka paljon tietoteknisen välineet muuttuvat pienenkin ajan- jakson aikana. Uusia työkaluja kehitetään jatkuvasti ja uusia nousee vähän väliä yleiseen tietoisuu- teen, josta ne sitten leviävät yleiseen käyttöön tai ne unohdetaan. Tutkimuksen aloitettua molemmat pääteknologiat ovat muuttuneet hyvin paljon tähän päivään saakka, mutta ne ovat kestäneet eri tren- dien muutokset ja kritiikin. Valintani tehdä vertailu ReactJS:stä ja AngularJS:stä oli siis jälkikäteen kat- sottuna hyvin onnistunut, koska ne ovat nousseet yleisimmiksi teknologioiksi Javascript -kehityksen saralla.
ReactJS on tämän hetken suosituin JavaScript-kirjasto. AngularJS:llä tehtyjä koodikantoja kehitetään vielä paljon ja se varmasti jatkuu, mutta on selvää, että ReactJS on voittanut JavaScript-kehittäjien suosion.
Mitä työkaluja verkkosovelluskehittäjän tulisi käyttää? On tosiasia, että sovelluskehittäjille on ylitarjon- taa teknologioiden suhteen ja tämä runsaus saattaa aiheuttaa valinnanvaikeutta varsinkin vasta-alka- jille. Tutkimukseni pyrkii avartamaan ymmärrystä siitä, mistä teknologioista olisi hyötyä verkkosovel- lusten kehityksessä.
38
Tutkimuksen jatkokehitystä ajatellen, vertailuun voisi ottaa uusimmat versiot sekä AngularJS:stä että ReactJS:stä. Toinen vaihtoehto olisi vertailla ReactJS:iä ja jotain uutta suuren suosion saavuttanutta sovelluskehystä ja tehdä vastaavanlainen vertailu sekä tehdä sovellukset kummallakin teknologialla.
Myös sovelluksia voisi jatkokehittää. Sovellukset voisi suunnitella siten, että niissä otettaisiin kaikki irti AngularJS:n ja ReactJS:n ominaisuuksista. Kuitenkin niin, että sovellukset olisivat vielä vertailtavissa.
Opinnäytetyön prosessi oli haastava, mutta aiheen ansiosta opettava ja motivoiva. Haastavin osuus oli selvästi sovellusten rakentaminen ja dokumentointi. Uusien teknologioiden opiskelu ja käyttöönotto veivät odotettua enemmän aikaa ja energiaa, joita on vain rajallisesti. Opettajan antamat palautteet olivat erittäin hyödyllisiä ja tapaamisista oli paljon apua erityisesti niiden motivoivan vaikutuksen takia.
Opinnäytetyön tekeminen on opettanut teknologioiden lisäksi siitä, mihin asioihin tulisi itsessään kiin- nittää huomiota. Opinnäytetyötä tehdessä on havahtunut erilaisiin heikkouksiin ja vahvuuksiin itses- sään. Myös oman henkisen jaksamisensa havainnointi on parantunut.
39
Lähteet
DeNa Co., Ltd. 2013. JSX. Luettavissa: https://jsx.github.io/doc/tutorial.html. Luettu 19.5.2019.
Facebook 2019. Introducing JSX. Luettavissa: https://reactjs.org/docs/introducing-jsx.html. Luettu:
15.5.2019.
Facebook 2019. Reconciliation. Luettavissa: https://reactjs.org/docs/reconciliation.html. Luettu:
15.5.2019.
Foote, K. 2016. A Review of Different Database Types: Relational versus Non-Relational. Luettavissa:
http://www.dataversity.net/review-pros-cons-different-databases-relational-versus-non-relational/. Lu- ettu: 15.5.2019.
Google. 2018. AngularJS. Luettavissa: https://angularjs.org/. Luettu: 15.5.2019.
Mora, O. 2016. React component’s lifecycle. Luettavissa: https://medium.com/react-ecosystem/react- components-lifecycle-ce09239010df. Luettu: 15.5.2019.
Morgan, A. 2017. Introducing the MEAN and MERN stacks. Luettavissa: https://www.mon- godb.com/blog/post/the-modern-application-stack-part-1-introducing-the-mean-stack. Luettu:
15.5.2019.
Nishanth, A. 2013. Exploring JavaScript MV* Frameworks Part 1 – Hello Backbonejs
Luettavissa: https://www.infragistics.com/community/blogs/nanil/archive/2013/04/01/exploring-javas- cript-mv-frameworks-part-1-hello-backbonejs.aspx. Luettu: 15.5.2019.
Porcello, E. & Banks A. 2017. Learning React, O’Reilly Media, Inc.
Rauschmayer, A. 2014. Speaking JavaScript. O’Reilly. Luettavissa: http://spea- kingjs.com/es5/ch02.html. Luettu: 15.5.2019.
Ruebbelke, L. 2015. AngularJS in Action, Manning Publications.
Scott, E. 2015. SPA Design and Architecture: Understanding single-page web applications. Manning Publications.
40
Techopedia 2018. Software Framework. Luettavissa: https://www.techopedia.com/defini- tion/14384/software-framework. Luettu: 15.5.2019.
Tutorials Point 2019. Node.js Introduction. Luettavissa: https://www.tuto- rialspoint.com/nodejs/nodejs_introduction.htm. Luettu: 15.5.2019.
Wikipedia s.a. Model-view-controller. https://en.wikipe-
dia.org/wiki/Model%E2%80%93view%E2%80%93controller. Nähty: 21.5.2019.
Williamson, K. 2015. Learning AngularJS (Single-page applications). O’Reilly Media. Luettu:
15.5.2019.
W3C 2018. A Short History of JavaScript. Luettavissa: https://www.w3.org/commu- nity/webed/wiki/A_Short_History_of_JavaScript. Luettu: 23.12.2018.
