Jukkasoft's Blog

Perheemme sai 2 A4-paperia. Molemmille lapsille kyseltiin kahden päivän hoitosuunnitelmia kesäkuulle, jolloin osa alueen päiväkodeista on henkilöstökoulutuksen vuoksi kiinni.

Kun tarkastelin kyselyä hieman tarkemmin, huomasin, että tietoa tarvitaan
2 bittiä per lapsi, mutta huomasin skrivailevani 78 merkkiä ja siihen päälle “analogisesti tehty” (käsin) allekirjoitus. Lomakkeelle meni kaikki mahdollinen perustieto, nimistä ja henkilötunnuksista alkaen.

Redundanttia eli turhaa tietoa meni siis siis 505 bittiä, 2 bitin hyötykuorman lisäksi. Vai oliko sittenkään? Mistä voi olla kyse?

Tapaus on mielestäni äärimmäisen kiehtova, ei siksi että tällainen per se olisi mitenkään erityisen mullistavaa, mutta koska tässä nähdään digitaalisuuden idea ja potentiaali.

Jatketaan huomenna osassa 2! Teen vertailuja ja hypoteettisia kustannuslaskelmia digijärjestelmään, sekä pohdin keiden työtä ja elämää se helpottaa.

Joskus on hauska pysähtyä miettimään teknologian luonnetta.

Oli aivan arkinen aamu. Tein lyijytäytekynällä pientä vedosta, suunnitelmaa paperille. Painoin kynän päästä: halusin lisää lyijyä. Sitä ei tullut. Lyijytäytekynä on suhteellisen luotettava kapistus, mutta siinä on usein nämä omat oikkunsa; nimittäin joskus kynä jumittaa. Jumituksessa käy usein niin, että ilmeisesti syöttöön on mennyt väärän paksuinen lyijy, jolloin se jää kiinni ja alkaa murskautua metalliputkea vasten – “syöden” muutkin lyijyt, mikäli syöttömekanismi niitä yrittää perään työntää.

En ihmettele miksi lyijytäytekyniä lentää roskikseen. Jumituksen poisto nimittäin ei ole ihan triviaali juttu. Ongelmaksi muodostuu kynän ohut läpimitta – se on tietysti tuo 0.5mm tai 0.7mm riippuen kumman paksuista lyijyä kynä nimellisesti ottaa.

Aloin etsiä työkalupakista: kävisikö nasta putsaustyökaluna? Ei, liian paksu. Entä klemmari? Ei käy. Hakaneulan kärki? Liian paksu, ei jaksa työntää loppuun asti. Kuparinen pieni puunaula näytti jo varteenotettavalta! Ei.. Liian paksuja kaikki.

Löysin lopulta pienen palasen ilmeisesti alunperin sähköjohdon johdinta, jonka olin jostain alunperin saanut kuorimapihdeillä. Työntelin varovaisesti (noin ohut metalli myös taipuu helposti, joten tarvitsin käytännössä hohtimet avuksi) jumittavaa lyijyä, ja useamman yrityksen jälkeen koko kynän aukko oli puhdas: valoa vasten näki, että nyt tuli valo läpi.

Aikoinaan loistavassa PC-pelissä (Civilizationissa) rakennettiin omaa heimoa, ja taisteltiin naapuriheimoja vastaan. Peli opetti yhtä paljon yhteiskunnasta kuin myöhemmin opin koulussa. Pelissä oli tavattoman keskeisenä asiana erilaiset keksinnöt, joista oli hyötyä tuotannon ja taisteluvälineiden kehittämisessä. Keksinnöt riippuivat aiemmista löydöksistä. Esimerkiksi pyörän keksiminen mahdollisti käytännössä liudan muita asioita; sotavaunut (engl. ‘chariot) olivat varsin kelpo taistelujoukko, jos vastapuolella oli pelkkiä jalkamiehiä.

Massatuotannossa kulminoituu teknologinen keskinäisriippuvuus: lyijytäytekynä on todennäköisesti tuote, jonka on mahdollistanut vasta useiden eri korkean teknologian yhteiskäyttö. En tiedä, mutta voisin kuvitella, että tuollaisen Ballografin osat tulevat CNC-jyrsimen avulla. CNC-kone on metallurgian ja valmistustekniikan tuote itsessään – lisäksi sitä ohjaa iso kasa elektroniikkaa ja ohjelmistoja. Muoviosat kynään on valmistettu niinikään jonkinlaisessa teollisessa prosessissa. (Mustekynän valmistuksesta video – varmasti aika lähellä lyijytäytekynän prosessia)

Teknologialla on sitten kääntöpuolena, melkein aina, huoltotarve ja kompleksisuus. Enää emme varmasti koskaan mene sille tasolle, missä olimme 5000 vuotta takaperin. Olemme 2017 varsin pitkälle kehittynyt biologinen yhteiskunta – omalla tavallamme. Olemme verkottuneet, digitalisoituneet, ja näköpiirissä on jo keinotekoisia korvaavia elimiä yms. Materiaaliteknologia, tietotekniikka, lääketiede, ja moni muu ala etenee. Silti aina välillä iskee (jopa käytännön) tarve istahtaa alas ja rassata omin käsin tuo lyijytäytekynä auki.

Tammikuussa 2017 uutisoitiin muiden tietoturvauutisten joukossa muutamista (sadoista, tuhansista?) ns. ransom-hyökkäyksistä, jotka kohdistuivat MongoDB -tietokantaa käyttäviin saitteihin ja palveluihin. Kevään 2017 edetessä ilmiö eteni kiihtyvällä tahdilla aika epidemiaksi.

Mikä on ransom -hyökkäys?

Ransom on siinä mielessä ikävä hyökkäys, että siinä data kaapataan, kryptataan lukkojen taakse, jonka jälkeen omistajaa kiristetään maksamaan vapautusmaksu. Alkuperäinen data joko poistetaan tai ylikirjoitetaan salakirjoitettuna, jolloin alkuperäisen järjestelmän omistajalle jää korkeintaan kasa satunnaiselta näyttäviä bittejä – tietoa ei voi sellaisenaan enää käyttää.

Hyökkääjä todennäköisesti jättää mieluusti kryptatussa muodossa olevan datan uhrille, jotta tämä vakuuttuisi enemmän mahdollisuudesta vielä nähdä alkuperäinen data maksun jälkeen.

Kuten mikä tahansa panttivankitilanne, takuita tiedon vapautuksesta maksun jälkeen ei ole. Usein maksu pyydetään elektronisessa muodossa, esimerkiksi Bitcoineina. Vapautus tapahtuu salasanan tai koodin / lukituksenpoisto-ohjelman kautta. (Kts. F-secure FSLabs -video aiheesta: Activation Ransom trojan (Youtube) – vaikka videossa on kyse Windowsin kaappaamisesta, periaate on aivan sama).

Nyt huhtikuussa 2017 paljastui enemmän teknisiä yksityiskohtia näistä MongoDB -kiristyksistä. Lukittujen järjestelmien lukumäärä on ilmeisesti yli 30000 tällä hetkellä.

Mikä mahdollisti hyökkäyksen?

MongoDB on siis tietovarasto. Ongelmaksi muodostui löpsö vakiokonfigurointi, joka on ollut olemassa kaikissa MongoDB:n 2.6.0 vanhemmissa versioissa: asennettaessa tietokanta ei vaadi asettamaan salasanaa pääkäyttäjälle. Toisin sanoen tietokanta on sepposen selällään kenelle tahansa joka huomaa tietyssä IP-osoitteessa pyörivän tietokannan.

Versiota 2.6.0 vanhemmissa tietokannoissa MongoDB suostuu ottamaan yhteyksiä vastaan “mistä tahansa” päin maailmaa, ja sen lisäksi, kuten aiemmin mainittu, se ei vaadi salasanaa. Toisin sanoen: jos pahaa tarkoittava hyökkääjä kokeilee hieman tikulla jäätä, ja huomaa että netissä on amatöörin pystyttämä MongoDB (versiota 2.6.0 aiempi), niin hyökkäys on pala kakkua. MongoDB on siis vakioasetuksilla täysin turvaton.

Miksi v. 2017 hyökkäykset yleistyivät?

Ensimmäisen kerran mahdollinen turva-aukko huomattiin jo 2015. Hackernews toitotti maailmalle, että webissä on satoja MongoDB:tä käyttäviä palveluita, joiden tietokanta on siis turvaton. Hackernews kertoi varsin selväsanaisesti myös viestin: tietokanta on vakioasetuksillaan todella turvaton.

Luulisi tällöin tapahtuvan jotain. Kenties turvatonta tietokantaa pyörittävän firman ylläpitäjä tai ohjelmoija muuttaisi pääkäyttäjän siten, että salasana turvaisi tietokannan tästedes?

Miksi tuhansia tietokantoja jäi silti suojaamatta?

On useita (mahdollisia) syitä.

• tietoturva-aukosta kertova uutinen ei päädy koskaan asianomaisen näköpiiriin
• uutinen on tiedossa, mutta firmassa on troijalainen – henkilö, joka ei toimi firman parhaiden intressien mukaisesti
• ne kehittäjät, jotka ovat projektissa, eivät alunperin ole pystyttäneet tietokantaa, eivätkö tiedä haavoittuvuudesta. Arkkitehti on jo toisessa projektissa, tai lähtenyt firmasta.
• uhkaa on tiedossa, mutta sitä ei pidetä riittävän suurena, jotta siihen “kannattaisi” reagoida
• asia hautautuu jostain inhimillisestä syystä ja sitä ei käsitellä ajoissa

Enpä itsekään ollut tietoisesti tuota vuoden 2015 Hackernewsin uutista rekisteröinyt. Voi olla, että näin sen, satojen muiden tietoturvauutisointien kanssa. Toisaalta, itse en käytä myöskään MongoDB:tä mihinkään.

Laskelmoiva vs. haparoiva tietoturva organisaatiossa

Yritykset toimivat tietoturvan kanssa usein jommallakummalla tavalla: erittäin laskelmoiden, tai haparoivan satunnaisesti. Laskelmoivassa tavassa tehdään uhka-arviot, ja yksittäiset tunnetut ja tuntemattomat uhka-skenariot pisteytetään suurinpiirtein näin: “Kuinka todennäköinen hyökkäys on; paljonko hyökkäyksellä saavutetaan, ja mitkä ovat seurauksen kustannukset firmalle”. Kaikki tietoturvaan liittyvä toimet toteutetaan ottamalla pistelistalta kivuliammat ongelmat ensiksi käsittelyyn.

Haparoivassa tietoturvassa yksinkertaisesti laitetaan laput silmille ja koodataan menemään, sen kummemmin miettimättä koko asiaa. Firma maksaa myöhemmin ongelmista mainetappiona ja mahdollisesti myös oikeusteitse asiakkaiden karhutessa korvauksia. Jos hyvä tuuri käy, purkkaviritys ei koskaan edes joudu hyökkäyksen kohteeksi.

Laskelmoiva firma siis vähentää riskiä joutua tietoturvahyökkäyksen uhriksi.

Miksi näin laajat hyökkäykset ovat mahdollisia?

MongoDB -kaappauksista tuli hieman mieleen vuoden 2014 kohu-uutinen, Heartbleed -haavoittuvuus. Heartbleedissä pienen pieni koodinpätkä (joka oli sinänsä hyödyllinen, mutta ohjelmoitu väärin) teki miljoonista web-servereistä turvattomia: hyökkääjä saattoi lukea serverin keskusmuistia 64 kilotavun paloissa mielivaltaisen paljon. Heartbleedissä oli kyse netin perusputkiston, OpenSSL-kirjaston, bugista. Haavoittuvuutta hyväksikäyttävä hyökkäys ei jättänyt minkäänlaisia jälkiä lokitiedostoihin, koska nimellisesti hyökkäysliikenne näytti harmittomalta, normaalilta web-liikenteeltä: ainoa ero oli, että hyökkäyspaketissa oli yksi numero erilainen kuin normaalissa liikenteessä. Tuon numeron liian orjallisessa noudattamisessa OpenSSL-koodi teki fataalin virheen: se palauttikin hyökkääjälle paljon enemmän paluupaketissa (serverin muistin sisältöä) kuin olisi ollut fiksua.

Yleensä suuren tietoturvamokauksen paljastuttua alkaa analysointi ja sormen heristely. Kuka on alunperin jättänyt tietoturva-aukon järjestelmään? Miksi näin pääsi käymään? Oliko kyseessä vahinko vai tarkoituksellinen teko? Foliohattuteoriat myös usein saavat kannatusta tässä vaiheessa – ehkä osa näistä on oikeassa, todennäköisesti suuri osa ei ole. Aikoinaan 1980- ja 1990-luvulla tietokonevirusten suurin haitta tuli oikeasti ei niinkään tarkoituksella, vaan vahingossa – myös virusten kirjoittajat tekevät bugista koodia.

MongoDB on C++ :lla koodattu. Se ei oikeastaan vielä kerro mitään. Kieli on edelleen voimissaan, ja sitä ymmärtää sadattuhannet koodaajat. MongoDB on myös avointa lähdekoodia. Tämän pitäisi parantaa tietoturvaa, koska kuka tahansa voi käydä katsomassa, miten tietokanta ja sen turvatoimet on toteutettu.

Tekniikassa itsessään ongelma ei varsinaisesti piile. Ongelman ydin on paljon yksinkertaisempi: MongoDB valitsi käyttäjäystävällisen, “kivan” polun, sen sijaan että pakottaisi käyttämään salasanaa tietokannan suojaukseen.

Helppo ja kiva vs. turvallinen (napit vastakkain)

Kun virittelen aina silloin tällöin MySQL-kantaa omalla läppärillä, harmittaa sen vaatima salasana. MySQL:ssä on yksi pääkäyttäjä, jolla on oikeus tehdä mitä tahansa tietokannassa: lukea, muokata, ja poistaa tietoa. MySQL:ssä käyttäjän nimi on ‘root’.

Useimmiten MySQL on alustana, kun kokeilin jotain asiaa WordPress-blogissa – en täällä julkisessa Internetissä (Jukkasoft-blogissa), vaan omalla koneella. Käytän kantaa niin harvoin, että tuo salasana tuntuu sitten olevan “jossain” kun sitä tarvitsisi. Yleensä kirjoitan tuon salasanan vihkoon, jota pidän kaapissa. Tai vastaavaa.. No, kun 3-6 kk kuluu, voi olla että paperi on ajautunut hieman, enkä löydä välittömästi (alle 5 minuutin etsiskelyn) salasanaa.

MongoDB käytti toisenlaista strategiaa: se ei pakottanut pääkäyttäjää asettamaan tietokantaa turvaavaa salasanaa asennusvaiheessa. Eli ohjelmaa oli helpompi käyttää – kenties myös helpdesk sai vähemmän kyselyitä kadonneiden salasanojen palauttamisesta. (MySQL:ssäkin pääkäyttäjäsalasanan voi palauttaa, jos on itse koneen pääkäyttäjä:  ohje MySQL 5.7:lle ja muille versioille) Ilmeisesti ohjelmisto ajautui sitten sellaisenaan, suojaamattomana, myös paikkoihin joihin sen ei olisi pitänyt päästä – tuotantoon.

Asiakas, esimerkiksi web-saitin toteuttava ohjelmisto, keskustelee MongoDB:n  kanssa TCP-kutsuilla. Yhteyskäytäntö on siis valittu sellaiseksi, että teknisesti sen toteutus on hyvin samanlainen riippumatta, onko asiakas samassa tietokoneessa (paikallinen), vai toisella puolella maapalloa. Luonnollisesti silloin kun kytkeytyvä asiakasohjelma on fyysisesti eri paikassa, on tärkeää käyttää tietoturvallista kytkeytymistapaa. Internet on “luonnostaan” turvaton, joten tietoturva pitää luoda ohjelmistoissa aina siten että molemmat päät noudattavat samaa protokollaa tiedon käsittelyssä.

Mistään uuden uutukaisesta asiasta ei ole kyse. Krypton käyttö kirjautumisessa juontuu jo 1990-luvulle, jolloin mm. SSH-ohjelmisto keksittiin terminaaliyhteyksien suojaamiseen: Otaniemen Teekkarikylässä opiskelija-asuntolan omasta tietokoneesta oli kätevää mennä yliopiston koneille tekemään kotitehtäviä, mutta harmitti, jos joku toinen teekkari salakuunteli yhteydessä käytetyt salasanan. SSH-ohjelmisto esti tällaisen salakuuntelun. Jostain syystä nämä tunnetut reseptit ajoittain “unohtuvat” tai jostain käytännön syystä jäävät käyttämättä.

Summa summarum

Liian aikaista. Asiasta selvinnee vielä uusia yksityiskohtia. Itseni tämän luokan aukko yllätti, kahdella tapaa. Ensin kuvittelin että ransom-uutiset koskevat jo tutuksi käynyttä asiaa: Windows-koneiden kaappaamista ja kiristystä. Kyse ei ollutkaan siitä.

Toinen asia, joka yllätti, oli että tuotannossa on käytetty täysin suojaamattomia tietokantoja. Se on kuin ajelisi valtamerialuksella laput silmillä, autopilot poissa päältä, ilman tutkaa. Odottaa vaan törmäystä.

Teen uusien ohjelmointiasioiden opiskelussa usein jonkinlaista “dummy”-projektia. Eli olen tekevinäni esimerkiksi muistilistaa, tai vaikka – sanotaan – hmm… jotain karttasovellusta. Tällainen lähestymistapa helpottaa hahmottamaan jollain tapaa sitä, mitä tekee. Eli puoliksi huijaa itseään: ei kirjoittele vain koodirivejä ilmaan ja käsittele täysin abstrakteja merkkijonoja tai numeroita, tietueita jne.

Mietin paljon softaprojektin eri osa-alueita. Speksaus on edelleen tärkeä osa, mutta se on myös jotenkin ongelmallinen ja rajoittavakin osa. Speksi tarkoittaa ohjelmiston määritellydokumenttia: niin käytetyn sanaston, tavoitteiden, tavoiteltavien hyötyjen, ohjelmiston sovellusalueen piirteiden, sen käyttötapausten, ja monen muun asian kirjaamista ja pohdiskelua.

Speksi muodostuu keskustelualustaksi, kun ohjelmistoa viedään tiimissä eteenpäin. Se on ohjelmiston eräänlainen aineeton koekappale, joka ei vielä toimi oikeasti. Speksi ei ole siis prototyyppi (prototyyppi on toimiva ohjelma, vaikka se olisi kuinka rajoitettu tai alkeellinen – silti, toimiva).

Ihan oikea tarve: kotiin!

Teen paraikaa oikeaan tarpeeseen softaa: haluan kotikäyttöön ostoslistan. Kyllästyin paperilappuihin, koska niitä varten pitää aina jostain vetää se lappu ja kynä. Kynä lisäksi pitää myös muistaa viedä kauppaan, jos paperilappua haluaa aktiivisesti käyttää: tarvii yliviivata ne asiat jotka on jo ostanut. Paperilappu myös usein unohtuu väärään paikkaan, siis yllättävän usein! Ja koska arvostan esteettisyyttä, paperilappu rypistyy; muste lähtee kosteudessa leviämään, ja lyijykynästä taas lyijyjälki tahraa ja pehmenee joskus sellaiseksi että lapusta ei saa selvää.

Hei, yllä on melkein ilmaiseksi vedetty se “unelma” -kohta speksiin; tätä minä haluan! Keskustelin asiakkaan, itseni kanssa, ja mietin, miksi haluan sen digitaalisen ostoslistan.

Jalostetaan silti toiseltakin puolelta: mitkä ovat digitaalisen ostoslistan huonot puolet?

Miettimällä ongelmia voidaan saada jonkinlainen parempi muoto ja toteustapa ostoslistalle. No, huomasin tällaiset asiat:

• mitäs jos kännykkä jää kotiin? Eli huomaa menneensä kauppaan, ja sitten se tieto onkin “ei saatavilla”. Huulipurettaa.
• onko tiedon syöttö oikeasti niin nopeaa ja helppoa kuin ajattelisi? Känny on usein lukittuna (“screen lock”) tjsp, joten alkuunpääsy voi olla hidasta.
• eipä kynäkään ole tosiaan aina saatavilla, jollei järjestä kotona aina jonnekin tiettyyn paikkaan esimerkiksi keittiössä tällaista luxusta
• entäs tietoturva yms?
• onko ostoslista helppo myös unohtaa / hävittää. Tällaista tietoa ei luulisi tarvitsevan mihinkään tulevaisuudessa… Eli poisto helpoksi, ettei ala kertyä “digiroskaa” kännykkään.

Speksi on perinteisesti tarkoittanut aika paljon tietorakenteita ja ohjelmistossa olevan tiedon hierarkiaa ja linkittymistä toisiinsa. Siis englanniksi: Entity-Relationship model. ER-mallit ovat jo aika raskaita ja puisevia dokumentteja, mutta voivat sinänsä auttaa sekä ongelman hahmottamisessa, pilkkomisessa että koodin kehityksessä. ER -malleilla haetaan ehkä eniten standardimuotoista helpotusta ohjelman keskeisimpien rakenteiden (oikeastaan: algoritmien, datan määrän ja ennakoitujen pullonkaulojen) dokumentoinnissa. ER-malli on toisaalta hyvin staattinen, ja kuvaa vain rakennesuhteet: ei esimerkiksi miten asiat “proseduraalisesti” toimivat, eli miten mekanismit suhtautuvat toisiinsa ajonaikaisessa koodissa.

Tässä kohtaa on aika hyvä pysähtyä hetkeksi. Heitän seuraavat kysymykset mietittäväksi:

• paljonko käyttäisit aikaa ostoslista-ohjelman tietorakenteiden mallintamiseen?
• mitä ensimmäiseksi tulee mieleen ostoslistassa käytettävistä rakenteista? Ovatko ne yksinkertaisia, monimutkaisia, selkeitä, epäselviä?
• ajattelisitko jotain tiettyä laajennusmahdollisuutta, jos ostoslistan saisi tehtyä viikossa jo toimivaksi ohjelmaksi?

Tänään avataan pienellä esimerkillä ReactJS:ää eteenpäin. Tehdään komponentti, joka on Reactin peruspalikka. Kirjoitussarja seuraa lähes livenä omaa React -kehitykseni kulkua. Tämä on toinen osa. Ympäristö on asennettu osassa 1.

Se ‘opinionated’ eli ideologinen puoli

React sisältää, kuten Angular ja monet muut frameworkit, kohtuullisen paljon valmiita käytäntöjä. Siksi pelkästään päällipuolinen sorsakoodin katsastelu saattaa jättää monia kysymyksiä avoimeksi. Kannattaa aina välillä lukaista jokin kokonaisuus, vaikka React:n virallisilta dokumentaatiosivuilta. Alkuvaiheissa hyvä on esimerkiksi React Component (kaikki omat komponentit perivät tästä).

Kun opiskelen itse Reactia käytännössä “nollasta” eteenpäin, seuraavat asiat tökkivät alkuun:

• herkkä (ja perus vanilla-Javascriptiin verrattuna uusi) syntaksi; jos syntaksi on väärin, pieni virhe aiheuttaa yleensä tyhjän sivun selaimessa, ei kovin paljoa vihjeitä mistä etsiä bugia… mutta:
• Sublime Text 3 editori ja sopivat lisäosat auttoivat alkuun, koska monesti hapuillessa oikeaa syntaksia sai askel askeleelta vihjeitä miten päästä oikeaan lopputulokseen
• ihan ensialkuun tekstieditorin asetusten löytäminen sopivaksi, jotta ESLint -syntaksitarkistaja antaa React-ohjelman kääntyä puhtaasti

ESLint on osa esimerkkimme build-sykliä. Koska JSX menee Babel-kääntäjälle, on ilmeisesti normaalia tärkeämpää että syntaksi on juuri kohdallaan, eikä melkein sinne päin. JavaScript:hän jättää jonkun verran vapauksia valita syntaksiin liittyviä asioita, mutta JSX ja React ovat sen sijaan varsin tiukkoja. Huomasin alussa nyplääväni editorissa hyvin lyhyttä ohjelmaa ainakin vartin; hain melkeinpä kokeilemalla oikeaa muotoa.

Alkuun asia voi hidastaa kokeilua ja koodaamista, mutta kun tyyliin on päässyt sisälle, homma ei enää nouse ongelmaksi.

Jos editorissa tuntuu olevan syntaksiväritys (syntax highlighting) päin mäntyä, kokeile antaa Babel/JavaScript olla tulkkina sen sijaan että yrität lähdekoodille normaalia JavaScript-asetusta. Erona on siis se, että Babel:in avulla voidaan laajentaa erilaisia kielimurteita, jotka antavat värittimelle oikean rakenteen ja siten värit kohdalleen. Suoraan “Javascriptinä” tulkittuna tuo JSX olisikin virheellistä.

React: komponentit

Koodaaminen perustuu pariin keskeiseen asiaan: komponenttien määrittelyyn ja parametrien välittämiseen komponenteille. Kaikki komponentit perivät perusluokasta React.Component

Paljonko React nojaa ES6 -muotoon JavaScriptistä?

ES6 :sta ei ole pakko tietää kaikkea, riittää alkuun kun katsot miten ‘class’ toimii: se on luokkamäärittely, joka lopulta kääntyy “yksinkertaisemmaksi” JavaScriptiksi. Babel on tuo kääntäjä, joka hoitelee magian ES6 -tyyppisen lähdekoodin ja lopullisen käännöstuotteen välillä.

Class -määrittely (ES6)

Kannattaa katsoa Class -määrittely (ES6)

Perusidea on siis yksinkertaisempi ja lyhyempi syntaksi. Lopulta käännetty JavaScript on aivan samaa koodia, mutta nyt lähdekoodi pysyy puhtaamman näköisenä.

• yksinkertaista määritellä luokka
• luokan sisällä olevat funktiot kirjoitetaan “helpommin”, ei tarvitse määritellä turhaa formalismia:
  funkkari (parametrit) { tänne koodi }
• Perusmuoto ‘class’ avulla tehdystä luokasta:
  Class OmaKomponentti extends React.Component
• luokka sulkee sisälleen yksityiskohdat, jolloin globaali nimiavaruus pysyy mahdollisimman siistinä.

Tilatonta rakkautta, toistaiseksi

Myöhemmin sarjassa palataan koko sovelluksen tilan hallintaan; Reactissa komponentit eivät voi suoraan muokata tilaa (muuttujia, objekteja), koska on haluttu pitää tiedon liikkuminen yksisuuntaisena. Eli komponentille päin voidaan välittää tietoa kutsujalta, mutta ei takaisin. Ns. two-way binding, joka on mm. AngularJS:ssä keskeinen ominaisuus, on myös sellainen, joka usein saattaa karata käsistä: sekä suorituskyky koodissa laskee, että bugien jahtaaminen monimutkaistuu. React haluaa, että komponentit tekevät selkeästi rajatun asian eli pitävät huolen ruudulla näkyvien (UI) asioiden muuttamisesta; that’s it – ei muuta.

Kädet saveen: komponentti

Lähdetään penkomaan, miten asennettu esimerkki oikein toimii. Jos et ole vielä asentanut runkoa koneellesi, käy vilkaisemassa aiempi osa blogauksesta: React alkuun, kaverina Yeoman

index.js käynnistää sovelluksen elinkaaren. Siellä on oikeastaan vain kutsu näyttää yksi itse määritelty komponentti:

Keskeisin osa lähdekoodista löytyy 2 tiedostosta:

src/index.js

src/components/Main.js

Alempi, “Main.js” määrittelee komponentin – eli päätason komponentin. App kutsuu muita komponentteja, eli se sisältää perus layoutin, komponenttitasolla.

Rivi riviltä tärkeimmät osat komponentista (Main.js)

Komponentin perusasiat ovat:

1. ympäristön asetus sopivaksi
2. luokan määrittely
3. render() funktio on komponentin tärkein pihvi
4. export – eli kerrotaan mikä osa komponentista avataan kutsujalle (koodin käyttäjälle)

Komponetti piilottaa siis kutsujaltaan turhat yksityiskohdat. Tässä on eräs Reactin kulmakivi: monessa muussa frameworkissa ohjelmoija voi pian olla scope-sotkun kanssa tekemisissä. Reactissa on tavallaan nihilistinen, yksinkertainen malli, jossa yritetään noudattaa klassisen olio-ohjelmoinnin kapsulointia – ideaa siitä, että jokainen olio (komponentti) pitäköön yksityiskohtansa omana tietonaan. Kutsuja on vain kiinnostunut rajapinnasta komponenttiin: mitä se ottaa vastaan, ja mitä se lupaa tehdä.

Tärkeät muistisäännöt

Katsotaan mitä koodista löytyy

• komponentitkin joutuvat itsenäisesti käyttämään require() :eja
• komponentin koodissa alussa myös tärkeä import
• render() on se funktio, mitä komponentilta odotetaan aina löytyvän
• pidä render() mahdollisimman lyhyenä ja siistinä, monimutkaisempaa käsittelykoodia voi laittaa komponentti-luokkaan render() :n rinnalle
• render() :ssä muista palauttaa aina ensin yksi div -elementti
  jonka sisälle on kääritty muu haluamasi sisältö

Toisin sanoen Reactissa komponentti on niin itsenäinen palikka, että se ei automaattisesti saa ympäristöstä muiden osien käyttämiä require ja import -määrityksiä. Jokainen komponentti huolehtii itse sopivien määritysten tekemisestä. Jos tarvitset komponentissa jotain resurssia, muista kirjoittaa tarvittavat sisällytykset.