ReactJS

[aittis]

Terve,

Avataanpas ketju Reactista. Viime viikkoina tutustunut siihen ja tuntuu aika fiksulta. Ensivaikutelmat olivat suoraansanottuna perseestä. Sitten tajusin proppien ja statejen älyttömän hyödyn ja tuntuu että seuraavat proggikset menee tällä työkalulla

 

[Elon Musk]

Tämän opettelua olen aloittamassa. Toivottavasti pysyisi jonkin aikaa kuvioissa, ettei tarvi heti vuoden päästä opetella jotain uutta ja sitten taas jotain uutta ja "parempaa". Kehitys on ihan ok ja uuden oppiminen, mutta nettikehityksessä tuntuu mopo keulivan aivan uskomattomalla tavalla.

 

[Zvona]

Omat ensivaikutelmat Reactista vajaan kahden vuoden takaa olivat Angularin runkkaamisen jälkeen, että tässä on tehty moni asia oikein. Vaikka React ei ole framework, niin sopivilla lisähöysteillä se jättää monet frameworkit ja kirjastot reilusti taakseen.

Nykyään nakuttelen oikeastaan ainoastaan React Nativea, joten olen viimeisen ~1,5v aikana tipahtanut webdev-maailmasta melkein täysin, mitä nyt sivusilmällä on tullut seurattua.

En oikeastaan keksi yhtäkään syytä, miksi en itse käyttäisi Reactia / React Nativea aina, kun olen tekemässä web-/mobiilisovellusta. Myös usko tulevaan on vahva, sillä sekä core-tiimi että ympärillä oleva ekosysteemi on todella motivoituneita asiantuntijoita.

 

[aittis]

React-Native on seuraava askel itselläni, miten Zvona uskotko sen olevan ihan haastaja natiivikehitykselle?

 

[Zvona]

React-Native on seuraava askel itselläni, miten Zvona uskotko sen olevan ihan haastaja natiivikehitykselle?

Tästä käydään jatkuvaa keskustelua. "Haastaja" on hieman väärä termi. Itse puhuisin mieluummin rinnakkaiselosta.

Sanoisin niin, että React Nativella ei pysty haastamaan ns. natiivikehitystä yhdessä asiassa: grafiikkaintensiiviset pelit. Eli en ensi töikseni lähtisi yrittää tekemään uutta Clash of Clansia React Nativella, vaikka se ei edes ole kovinkaan intensiviinen, mutta grafiikoiltaan ja pelilogiikaltaan kuitenkin hieman erityyppinen kuin se maailma, jossa RN on parhaimmillaan.

Sen sijaan käyttöliittymäpohjaiset ratkaisut, joista tarvitaan sekä iOS että Android -sovellukset (ehkä myös UWP) on järkevä toteuttaa React Nativella. Lisäksi, jos on niin, että löytyy taustaa enemmän web-kehityksestä, niin React Native uppoaa monelle vaivattomammin. En meinaa, että esim. Swift (tai Java, tai Objective-C) olisi kielenä mitenkään ylitsepääsemätöntä, mutta itsekin web/mobiili/HTML5 -taustalla olen saanut paljon paremman otteen React Nativesta kuin muista vaihtoehdoista.

En usko, että RN (tai sen johdannaiset kuten ExponentJS) ovat katomassa pitkään aikaan, sillä niille on tilausta. Jos mietit, että jokaista Clash of Clansia kohden on puolen tusinaa menestynyttä täysin UI-pohjaista sovellusta (Instagram, Whatsapp, you name it...) ja samalla useilla yrityksillä ja start-upeilla on tarve prototyypata tai luoda MVP, niin en näe syytä, miksi tässä yhteydessä ei käytettäisi RN:ää.

Itse olen ollut mukana kahden start-upin RN-sovelluksen kehityksessä ja molemmat ovat livenä sekä iOS että Android. Nyt on menossa kolmas, ensisijaisesti iOS-sovellus, jossa samalla mentoroin uuden kaverin. Lisäksi minulla on edelleen hengissä oleva peliprojekti, joka on kuitenkin prototyyppivaiheessa ja se oikeastaan kaipaisi toista kehittäjää rinnalle.

TL;DR
- React Native pystyy pääosin samaan - hyödyntäen natiivikomponentteja ja APIja - kuin natiivikehityskin
- todella helppo oppia, etenkin web-kehityksestä kannuksensa hankkineille
- ei korvaa olemassa olevaa mobiilikehitysratkaisuja (HTML5 hybridejä lukuun ottamatta)
- soveltuu parhaiten UI-pohjaisiin ratkaisuihin, ei niinkään monimutkaisten, grafiikkaintensiivisten pelien tekemiseen
- ekosysteemi hyvässä tilassa ja niin iOS kuin Android-kehityskin luonnistuu (tosin vielä on lapsentauteja)

 

[aittis]

Tästä käydään jatkuvaa keskustelua. "Haastaja" on hieman väärä termi. Itse puhuisin mieluummin rinnakkaiselosta.

Sanoisin niin, että React Nativella ei pysty haastamaan ns. natiivikehitystä yhdessä asiassa: grafiikkaintensiiviset pelit. Eli en ensi töikseni lähtisi yrittää tekemään uutta Clash of Clansia React Nativella, vaikka se ei edes ole kovinkaan intensiviinen, mutta grafiikoiltaan ja pelilogiikaltaan kuitenkin hieman erityyppinen kuin se maailma, jossa RN on parhaimmillaan.

Sen sijaan käyttöliittymäpohjaiset ratkaisut, joista tarvitaan sekä iOS että Android -sovellukset (ehkä myös UWP) on järkevä toteuttaa React Nativella. Lisäksi, jos on niin, että löytyy taustaa enemmän web-kehityksestä, niin React Native uppoaa monelle vaivattomammin. En meinaa, että esim. Swift (tai Java, tai Objective-C) olisi kielenä mitenkään ylitsepääsemätöntä, mutta itsekin web/mobiili/HTML5 -taustalla olen saanut paljon paremman otteen React Nativesta kuin muista vaihtoehdoista.

En usko, että RN (tai sen johdannaiset kuten ExponentJS) ovat katomassa pitkään aikaan, sillä niille on tilausta. Jos mietit, että jokaista Clash of Clansia kohden on puolen tusinaa menestynyttä täysin UI-pohjaista sovellusta (Instagram, Whatsapp, you name it...) ja samalla useilla yrityksillä ja start-upeilla on tarve prototyypata tai luoda MVP, niin en näe syytä, miksi tässä yhteydessä ei käytettäisi RN:ää.

Itse olen ollut mukana kahden start-upin RN-sovelluksen kehityksessä ja molemmat ovat livenä sekä iOS että Android. Nyt on menossa kolmas, ensisijaisesti iOS-sovellus, jossa samalla mentoroin uuden kaverin. Lisäksi minulla on edelleen hengissä oleva peliprojekti, joka on kuitenkin prototyyppivaiheessa ja se oikeastaan kaipaisi toista kehittäjää rinnalle.

TL;DR
- React Native pystyy pääosin samaan - hyödyntäen natiivikomponentteja ja APIja - kuin natiivikehityskin
- todella helppo oppia, etenkin web-kehityksestä kannuksensa hankkineille
- ei korvaa olemassa olevaa mobiilikehitysratkaisuja (HTML5 hybridejä lukuun ottamatta)
- soveltuu parhaiten UI-pohjaisiin ratkaisuihin, ei niinkään monimutkaisten, grafiikkaintensiivisten pelien tekemiseen
- ekosysteemi hyvässä tilassa ja niin iOS kuin Android-kehityskin luonnistuu (tosin vielä on lapsentauteja)

Tattis!
En tosiaan tarkoittanut mitään pelikehitystä RN:llä

 

[Zvona]

Nostellaan hieman tätä hienoa ketjua.

Tällainen tuli vastaan: react-bits/README.md at master · vasanthk/react-bits · GitHub

Tuossa on aika monta ihan hyvää käytäntöä seurattavaksi sekä listatuna myös muutama sudenkuoppa. Kannattaa katsoa ainakin kursorisesti läpi.

Muutoinhan, näin puoli vuotta myöhemmin esim. React Native on tullut valovuoden eteenpäin. En nyt lähde yksilöimään, mitä kaikkea on muuttunut, mutta esim. yhteisö on kasvanut todella vahvaksi. Itse teen tällä hetkellä kuudetta RN-sovellusta, joten voisi jo sanoa, että olen koukuttunut kyseiseen teknologiaan .

 

[eiltanen]

Tätä vois joskus katsoa, mutta kun ei oikein ole mitään tarpeeksi isoa käyttökohdetta. Ja kun itse käytän lähinnä Vue.js, React vaikuttaa tarpeettoman monimutkaiselta omaan tarpeeseen nähden.

 

[2112]

React vaikuttaa kyllä kiinnostavalta. Tosin kun ensimmäistä kertaa tutustuin asiaan näin Python/Django-taustalla ilman erityisempää JS-osaamista, pelkkä aiheesta lukeminen veti kyllä olon täysin veteläksi: ES6, npm, Webpack, Babel... huh. Kun oli tarkoitus perehtyä yhteen asiaan, kävikin ilmi, että sitä ennen pitäisi suosiolla opetella toinen juttu, ja sitä ennen vielä toinen ja sitä ennen...

Nyt, kun koko kuviosta on muodostunut edes jonkinlainen käsitys, olisi tarkoitus aloittaa ensimmäinen vähän isompi projekti (Django (+DRF) ja React) ja katsoa, mitä saa aikaiseksi. Toivottavasti muutakin kuin aivovaurion.

 

[jhalmu]

Videoita katsellut ja lueskellut tuosta. Jännä kun ottaa aina pistää jonnekin kun hötömölöä sekoitetaan muun koodin sekaan No kahtoo saako millään mitään aikaan koskaan. No, täytyypä käydä vilaisemassa mitä uutta Angular nelosessa.

 

[mopnex]

Videoita katsellut ja lueskellut tuosta. Jännä kun ottaa aina pistää jonnekin kun hötömölöä sekoitetaan muun koodin sekaan No kahtoo saako millään mitään aikaan koskaan. No, täytyypä käydä vilaisemassa mitä uutta Angular nelosessa.

Se "hötömölö" siellä seassa on itseasiassa JSX:ää. Tuota voi toki kirjoitella käyttämättä JSX. Angularin (huom. ei Angular*JS*) uusin versio on tosiaan numeroa 4, mutta pääasiassa tuo versionumero bump tuli siirtymisestä semver-malliseen versionumerointiin ja tarkoituksesta synkronoida angular-router kirjaston version numero itse angularin kanssa. Kyseessä ei ole siis mitenkään erityisen mullistava päivitys.

 

[jhalmu]

No juu jätin angularin nyt toistaiseksi, kun vähän liian järeä mun harjoitteluille. Eli luetaan sivussa reactia ja koetetaan saada nodetusta aikaan vähitellen.

 

[mopnex]

Kolmisen vuotta on Reactilla tullut tehtyä hommia. TypeScript/Flow molemmat ovat hyviä Reactin kylkeen.

 

[AION]

Joo, kyllä tätä itsekin tulee naputeltua.

Antaa varsinkin ES6 maailmassa näin paatuneelle Java EE koodarille jotenkin käteen sopivan tavan tehdä noita käyttöliittymä kikkareita kun ei asiakkaiden mielestä kuulemma REST api ole kauhean käytännöllinen ja aina ei jaksa / ehdi / ole mahdollista saada jotain apinaa tai orjaa tekemään UI:ta

Se mikä tässä on niin aika saatanan ADHD noiden versioiden päivitysten kanssa ja aina pitää jotain deprecoida ja siirrellä jne. Mutta se nyt on koko JS ympyrässä aika lailla sama juttu.

Enzyme on muuten ihan jees (huom ihan jees == vähiten syöpää aiheuttava) unit testi kirjasto mitä olen tän kanssa käyttänyt.

 

[Zvona]

Hyvä, että keskustelu ponnahti taas esille.

Omia mietteitä edellisiin kommentteihin:
- Vaihdoin Flow(type):sta TypeScript:iin enkä ole katunut hetkeäkään. Jostain kuullut huhujakin, että jopa FB on taipumassa TS:n alle tai ainakin harkitsemassa jonkin sortin yhdenmukaisuutta tai integraatiota. Tästä esimerkkinä propTypes:ien pudottaminen coresta.

- Versiopäivityksiä ei kannata tehdä ellei ole aivan pakko. Ja sanoisin, että nyt 16 tultua ulos on vähän niin kuin puolipakko, ellei ole tuotannossa minttiä, joka toimii ongelmitta.

- Enzymea on tullut kokeiltua ja todettua se hyväksi. En tosin ole mikään test-driven ihminen ja etenkin unit-testien tekeminen nostaa kyllä karvat pystyyn, vaikka niitä joskus nakuttelenkin. Ja jos kirjoitatte React Nativea, niin Detox (E2E) on ehdottomasti tarkastamisen arvoinen.

React ja React Native -ekosysteemi on erittäin vahva ja en edelleenkään usko, että esim. allekirjoittaneelta loppuu hommat seuraavaan kolmeen vuoteen. Ja jos loppuu, niin mikäs sitä estää omaksumasta sitä uutta "bleeding edgea".

Lisäksi ollut vahvasti esillä oman yritystoiminnan laajentaminen ja tarkoitus käydä nyt muutamankin eri yksinyrittäjän kanssa juttusilla, josko henkilökemiat täsmää ja uskaltaa lyödä hynttyyt yhteen. Yhden hengen yritykseen kun on vähän riskaabelia rekrytoida uusia junnuja ja/tai senioreita.

Olin muuten pari viikkoa sitten järkätyssä React Native EU:ssa ja siellä oli ihan hyvä meininki. Esitysten taso vaihteli ja oli aika polarisoitunutta, eli hyvät olivat todella hyviä ja huonot todella huonoja. Sen jälkeen vedettiin React Native Helsinki Meetup, joka toimi lähinnä yhteisöä herättelevänä tapahtumana muutaman esityksen voimin.

Tästä johdettuna uskallan "tulla etuajassa" ja promota meidän omaa React / React Native konferenssia Helsingissä, joka järjestetään ensi huhtikuussa: React Finland.

Järjestelyt ovat hyvässä vauhdissa, vaikka itse tapahtumaan on vielä reilut puoli vuotta.

Ja loppuun vielä kevennyskin: React Rauma 2017

 

[mopnex]

Flow ja TypeScriptin osalta olisi hyvä jos tuo päättyisi nyt yhteen selkään efforttiin. Noiden lisäksi tietysti mielenkiintoista nähdä kuinka vahvasti esimerkiksi Elm, Reason ja BuckleScript saavat porukkaa taakseen. Sekä se, että millä tavalla WASM alkaa näkymään, ei varmasti ole nyt eikä hetken päästä vielä mikään go-to työkalu. Tietyntyyppisiin tehtäviin tuota voisi käyttää jo kirjastotasolla ja abstrahoida sen.

Kirjastojen tyypitykset on kuitenkin se kynnyskivi, vielä pari vuotta sitten tilanne oli TS osalta myös hieman sotkuista tämän osalta, nykyään monet kirjastojen ylläpitäjät kirjoittavat kirjastonsa jo TS joten ongelma on hissukseen hälventynyt. Tietysti suosituimmat kirjastot ovat saaneet jo tyypityksensä. Kuitenkin siinä harvinaisessa tapauksessa kun pitää luottaa ulkopuoliseen kirjastoon mikä ei ole tyypitetty, ja tyypityksiä ei ole saatavilla, niin meneehän siinä oma hetkensä kirjoittaessa järkevät tyypitykset.

"- Versiopäivityksiä ei kannata tehdä ellei ole aivan pakko. Ja sanoisin, että nyt 16 tultua ulos on vähän niin kuin puolipakko, ellei ole tuotannossa minttiä, joka toimii ongelmitta."

Tästä olen harvinaisen paljon eri mieltä. Ehdottomasti kannattaa, jos softa on rakennettu järkevästi tuo on kivuton päivitys missä saa ilmaiseksi pienemmän payloadin (gzipattuna ja ilman) React (+dom) osalta. Tietysti jos devimoodissa oma softa vilisee warningeja, niin kannattaa hoitaa ne ensin alta pois. Jos softa ei ole siis tasoa "ship-it-forget-it".

 

[AION]

Tästä johdettuna uskallan "tulla etuajassa" ja promota meidän omaa React / React Native konferenssia Helsingissä, joka järjestetään ensi huhtikuussa: React Finland.

Järjestelyt ovat hyvässä vauhdissa, vaikka itse tapahtumaan on vielä reilut puoli vuotta.

Näyttää ihan mielenkiintoiselta.
Kuinka paljon porukkaa odotatte paikalle?
En löytänyt myöskään tuolta sivulta mitään hintatietoja?

 

[Zvona]

Näyttää ihan mielenkiintoiselta.
Kuinka paljon porukkaa odotatte paikalle?
En löytänyt myöskään tuolta sivulta mitään hintatietoja?

- Odotamme 300 osanottajaa, minimissään 200. Ja kaikki tuon 300 päälle on luonnollisesti pelkkää plussaa,
- Kohderyhmänä on intermediate / expert -tason osaajat, eli perusteita ei käydä läpi (paitsi workshop-osioissa jonkin verran),
- Kuten totesin, niin "tulin etuajassa" infon kanssa (koska io-tekkiläiset ovat etuoikeutettuja ) ja hintatiedot sekä rekisteröityminen tulevat vasta hieman myöhemmin. En kuitenkaan usko, että meidän tapauksessa lipun hinta tulee olemaan ongelma osallistumiselle vaan enemmänkin se, kuinka paljon firmat arvottavat osaamisen kehittämistä vs paljonko laskutettavaa työtä menetetään,
- Myös "cherry picking" on mahdollista, eli koko konffaa ei tarvitse lusia vaan voi ostaa lipun pelkästään workshopiin tai pelkästään React-päivään / RN-päivään. Toki tarjoamme ilon ottaa maksimit irti subventoidulla kokonaispaketin hinnalla (etenkin jos ulkomailta saakka raahautuu).

 

[AION]

- Odotamme 300 osanottajaa, minimissään 200. Ja kaikki tuon 300 päälle on luonnollisesti pelkkää plussaa,
- Kohderyhmänä on intermediate / expert -tason osaajat, eli perusteita ei käydä läpi (paitsi workshop-osioissa jonkin verran),
- Kuten totesin, niin "tulin etuajassa" infon kanssa (koska io-tekkiläiset ovat etuoikeutettuja ) ja hintatiedot sekä rekisteröityminen tulevat vasta hieman myöhemmin. En kuitenkaan usko, että meidän tapauksessa lipun hinta tulee olemaan ongelma osallistumiselle vaan enemmänkin se, kuinka paljon firmat arvottavat osaamisen kehittämistä vs paljonko laskutettavaa työtä menetetään.

Kiitoksia tiedosta

Joo eihän tuo lipunhinta tod.näk. ole kuin pieni osa vrt se, että ukot ei tee laskutettavaa. Meillä olisi ainakin kiinnostusta lähteä katsomaan tilaisuutta, vielä ei olla päätetty tullaanko kaikkina päivinä ja kuinka vahvalla miehityksellä mutta kiinnostusta kyllä löytyy.

 

[mopnex]

Ymmärtämättömyydestä aiheutunutta internet-mouhoa tuo koko sekoilu lisensseistä. Wordpressin porukka ei selkeesti ole alunperinkään ymmärtänyt mistä on kyse kts. On React and WordPress . Internet-myrsky taas kun ei osata ymmärtää.

Tietysti MIT "kiva", mutta ei todellisuudessa muuta mitään. Nyt et vain tiedä miten patenttien kanssa käy.

 

[Zvona]

Lauantaina tuli kokeiltua hankkimaani HTC Viveä ja ReactVR:ää. Oli kivaa, sillä peruspilarit ovat todella lähellä React Nativea. Yleisolo oli kuitenkin, että on vielä vähän epäkypsä tekele.

Ja se mikä pisti silmään oli, että View on aina yksi kokolevyinen ja -korkuinen alue, johon lätkitään kuvat ja tekstit. Toisin kuin React Nativessa, jossa dimensiot ja sijainti määritellään Viewille, niin ReactVR:ssä ne määritellään esim. Viewin sisällä olevalle Text -elementille. Tämä menettely on vastaavasti kiellettyä RN:ssä, joten siksi olin ensin huuli pyöreänä.

Ensimmäinen harjoitustason idea on tehdä "Sing Star", jossa saa laulaa ja fiilistellä virtuaalilavalla yhdessä yleisön kanssa. Äänenkorkeuden tunnistamisen lisäksi ajattelin kokeilla myös puheentunnistamista. Eli oikein lausutuista sanoista saa bonusta kun taas väärin lallattetuna tulee yleisöltä kiukkuisempi reaktio.

 

[Zvona]

Paukutellaanpa taas tähän ketjuun:

1. React Finlandin lipunmyynti viivästyi. PRH:n toimitettu yhdistyshakemus oli kuukauden jonossa ja vihdoinkin kun saatiin se läpi ja päästiin avaamaan pankkitili, niin selvisi että tarvitaan vielä Y-tunnuskin, jotta Stripe voi hyväksyä siirrot. Ehkä se tästä joulukuun alkuun mennessä saadaan avattua.

Muutoin kaikki näyttää erinomaiselta niin puhujien kuin muidenkin järjestelyiden suhteen.

2. Itse olen aloittanut blogaamisen pitkästä aikaa Mediumin alla (Samuli Hakoniemi – Medium). Tässä vaiheessa vasta kaksi artikkelia (RN ja React VR -aiheiset), mutta tarkoitus kirjoittaa enemmältikin, esim. MobX / MST nyt mielessä.

Aiheitakin saa heittää, jos mieleen tulee jotain "kompastuskiviä", joista haluaisi lisätietoa. Kirjoitan mieluummin tarpeeseen kuin tyhjiä artikkeleita, jotka eivät ketään kiinnosta.

3. Muutin React VR -sovelluksen suuntaa. Tarkoitus tehdä nyt Alkon materiaalia hyväksikäyttäen olut-/viini-softa, jonka avulla voi (panoraamakuva)hyllyjä katsella, valita sieltä mieleinen kategoria (esim. "Alet") ja sitten saada lista myynnissä olevista tuotteista.

Lisäksi ajattelin, jos esim. RateMyBeer / Vivino tms. palvelut tarjoavat avoimia rajapintoja, niin yhdistää tuotteisiin ratingit ja muistiinpanot. Tähän saa tulla mukaan, sillä kyseessä 100% harrasteluprojekti, jota puuhaan vapaa-ajalla opetellen VR-maailman saloja.

4. Expon Snack on online-IDE, jossa Appetize.io:n avulla voi ajaa RN-softaa. Päätin alkaa sinnekin kirjoittelemaan yksinkertaisiin kysymyksiin esimerkkejä (zvona on Expo), mutta vielä on tallentamisessakin haasteita. Aikaisempi iteraatio tuosta eli RN Playground:issa oli joku tusinan verran esimerkkejä (lähinnä Stack Overflow -vastauksien tueksi), mutta se vedettiin sileäksi.

5. Koska olen yksityisyrittäjä / freelancer, niin sitä myöten tulee keikkatarjouksia. Tällä hetkellä RN:ää koskien tulee 1-2 tarjousta viikkoa kohden, joten kysyntä on aivan infernaalinen.

Tämä siis vinkkinä, jos joku saman alan taituri tasapainottelee palkkatyön ja yrittäjäksi rupeamisen välillä, että (ainakin nyt ja lähitulevaisuudessa) rauta on kuumaa ja siitä kannattaa ottaa maksimihyödyt. Ja RN:n hyvä tuntemus ei tietenkään poissulje - jos se vaikka sattuisi kuolemaan / väistymään uudempien tekkien myötä - että eikö hommia riittäisi sen saralla tai sitten muun osaamisen kautta myös jatkossa.

Että tällainen "avautuminen". Etenkin kohtiin #2 ja #3 otan mielelläni vastaan pelin avaamista ja palautetta muiltakin tekkiläisiltä.

 

[Zvona]

Kirjoitellaanpa taas tänne ajankohtaisuuksia:

1. React Finlandin Early Bird -liput myytiin jo loppuun (eli ainakin sata osanottajaa tapahtumassa \o/). Regular-hintakaan ei päätä huimaa, joten rohkeasti vain työnantajan hihasta nykäisemään, jos aihe kiinnostaa

2. Olen kirjoittanut MobX:stä (ja mobx-state-treesta) artikkelia, mutta en ole saanut sitä vielä viimeisteltyä. Sen sijaan viimeistelin äsken lyhyen artikkelin React Nativen View/TextStylen käytössä yhdessä TS:n kanssa. Kannatta lukaista, jos on intohimoinen TypeScript-devaaja, käsittääkseni joiltain osin sovellettavissa myös Reactin kanssa React Native and TypeScript meets Styles

3. VR:llä en ole tehnyt mitään vaan itse asiassa HTC Vive on laatikossa, koska vaihdoin huonetta enkä ole ruuvannut beaconeita paikoilleen. Tällä viikolla tosin on tarkoitus laittaa VR-maailma pystyyn koska Contagion VR: Outbreak on Steam on ladattavissa demona (VR + zombiet, aah )

4. Expon suunnalla hiljaisempaa. En ole oikein jaksanut panostaa muiden auttamiseen, koska se tuo ajankäyttöön nähden aika vähän "hyvää". Tosin, SO:ssa on menossa 10.000 pisteen raja juuri rikki \o/

5. Tähän liittyen: olen maalaillut ideaa kolmen viikon React Native -kurssin järjestämisestä halukkaille huhtikuussa. Tavoitteena siis kouluttaa ja työllistää vastavalmistuneita / vielä opiskelevia / työelämän ulkopuolelle jääneitä it-osaajia. Muutaman firman kanssa jo keskustellut, ja heillä ainakin ollut kova into päästä työllistämään "junnumpaa", mutta jo koulutettua porukkaa etenkin React / RN -puolella, jossa kysyntä on kova. Projektitiedusteluja tulee itsellenikin se 3-4 kpl viikossa.

 

[Stephen Elop]

Antakaahan vähän apua VS2017 kanssa painiin. Ajattelin aloitella tuolla React + typescript yhteishässäkällä ja Studiossa oli valmis velho Node.js ja typescript projektille, niin siitä lähdin etiäpäin.

Ongelmana vaan on kun sitten haluan, että typescriptillä käännetty js-tiedosto menisikin build-kansioon, eikä samaan paikkaan, missä ts-tiedosto oli, niin debuggeri ei enää löydä mokomaa. Tulee vain virheilmoitus että Attribute "program" does not exists, vaikka luotu server.js on halutussa paikassa. Debuggeri ei ota ollenkaan huomioon tuota outDir-hakemiston arvoa.

tsconfig.json tiedostoon olen koittanut outFile ominaisuutta, mutta ei mitään vaikutusta. Tää olisi hyvä saada studiossa toimimaan, koska projekti olisi aliprojekti suuremmalle Visual studio projektille.

Muokkausta. Tästä taitaa olla kyse outDir and rootDir does not work for tests or debugging of TypeScript · Issue #1243 · Microsoft/nodejstools · GitHub
vs2015 ongelmasta pääsee eroon disabloimalla tsconfig.json käytön ja pistää asetukset itse projektiin.

 

[Zvona]

Nostellaas vanhaa:

Saatiin React Finland myytyä melko helposti loppuun ja jonossakin on joku ~50 henkilöä lisälippujen toivossa. Valitettavasti tila ei vedä enempää, niin ei voida venyttää kiintiötä.

Mutta syy, miksi nostan itse ketjua on: [Sticky] Who uses MobX? · Issue #681 · mobxjs/mobx

Eli valtaosa Battlefield 1:n käyttöliittymästä on tehty käyttäen TypeScript + React sekä MobX:ää... aikamoinen yllätys, että ovat lähteneet tuolle linjalle. Tietenkin seassa on itse grafiikoiden rendaukselle oma custom-engine, mutta on tuo silti ihan huomioonotettava kunnianosoitus etenkin MobX:ää kohtaan (joka taasen tuntuu olevan monelle kirosana).


[offtopic]
Itselle tuli aika positiivinen uutinen, kun sain kutsun tulla puhumaan React Native EU:hun ensi syksyllä. Jännittää aika paljon, sillä yleisö on keskitaso - hardcore -devaajia ja heille pitäisi pystyä tarjoilemaan "jotain uutta ja kivaa".
[/offtopic]

 

[mopnex]

Viimeisessä kahdessa projektissa on ollut redux käytössä, ja noissa myös redux-saga. Jos nyt miettisin ratkaisuja, niin varmasti pohtisin pidempään olisiko mobx suunta parempi lähestymistapa - riippuu projektista. Samoin redux-saga ratkoo tiettyjä tarpeita mitä ei ole redux-thunkin kanssa mahdollista edes ratkoa mielekkäästi. Kääntöpuolena redux-sagan hyödyntäminen hyvin vaatii kyllä aikaa. Jos streamit ovat tuttuja, niin esimerkiksi redux-observable voi myös olla sellainen mihin kannattaa tutustua.

Mikä on missäkin projektissa paras valinta riippuu täysin tarpeista, eikä nuo tarpeet ole aina samat. Kuitenkin, redux-saga on ollut erinomainen apu monessakin asiassa mitä nykyisessä projektissa on pitänyt tehdä.

 

[Zvona]

Erittäin hassua - ketju on ollut kuolleena 4kk. Ja juuri kun ajattelin kirjoittaa siihen, niin @oselotti ehti ensin

Itse työskentelen 4pv/vko projektissa, jossa on Flowtype. Ja 1pv/vko + oma harrasteprojekti, joissa TypeScript. Kyseessä siis React Native. Pidän molemmista, joskin TS on edelleen lähempänä sydäntä. Kirjoitin juuri tunti sitten pitkästä aikaa Mediumiin tosi lyhyen artikkelin RN:n tyylimäärittelyiden oikeaoppisesta käsittelystä: Stylesheets in React Native with TypeScript Revisited . Lisäksi pari artikkelia roikkuu, mm. React 360 -aiheinen aloittelijan tutoriaali. Sain sen melkein valmiiksi, mutta se on edelleen julkaisematta.

Hooksit ovat nyt kuuminta hottia, mutta itse en ole jaksanut innostua asiasta kuin kursorisesti. Tulevat kun tulevat ja sitten voidaan taas kirjoittaa puhtaampaa koodia - kaikkien taputtaessa yhteen karvaisia käsiään.

Oma fiilis TS vs Flow on vähän sama on Reduxin ja MobX (+ mobx-state-tree) välillä - molemmat menee, tosin Redux on IMO aikamoista tervanjuontia ja sitä käytetään monesti väärissä tilanteissa. Tuli mm. törmättyä yhteen projektiin, jota olisi pitänyt lähteä työstämään. Ko. projektista näki heti ensimetreillä, että nyt on menty kirjastovalinnat edellä puuhun (kuten Redux tilanteissa, jossa sitä ei tarvita). Eipä onneksi tarvinnut koskea siihen.

React Nativen osalta on käynnissä keskustelu siitä, että jatkossa olisi vain "Native" ja React putoaisi vaihtoehdoksi. Eli RN:ää voisi kirjoittaa niin Vuella kuin Angularillakin. Tuskin on backward compatible sitten aikanaan kun päivittyy, mutta IMO ihan järkevä kehityssuunta.

Muuten, jos design-puoli kiinnostaa (tai tuttava-designeria koodauspuoli), niin kannattaa uhrata tovi FramerX:n parissa. Se on aidosti mielenkiintoinen design / prototype -työkalu (ehkä etunenässä mobiilisovellusten suunnitteluun).

Muuta ajankohtaista omalta osin on se, että kävin syyskuussa RNEU:ssa puhumassa. Esitys meni läskiksi monesta syystä ja jouduin typistämään 30min aiheen 15 minuuttiin sekä pitämään esityksen läppärin blankolta ruudulta (hyvin meni live-koodaus kun ei nähnyt mitä tekee). Sain toki esityksen jälkeen paljon positiivista (sääli)palautetta, mutta itseäni jäi korpeamaan valmisteluun yms. käytetyn ajan "hukkaaminen" pääosin siksi, että tekniikka petti. No, oppimiskokemus sekin.

Järkättiin lokakuussa GraphQL Finland, jonka itse jouduin skippaamaan työkiireiden vuoksi. Kuuma aihe maailmassa, Suomessa ei niinkään välitetä ainakaan toistaiseksi.

Olemme aloittaneet React Finland 2019 puuhaamisen ja tarkoitus järkätä se huhtikuun lopussa hieman viime vuotta isompana ja parempana. Aika moni asia on jo lyöty lukkoon, eli tilanne on edellisvuotta parempi. Siellä on mm. Nik Grafin vetämä workshop ReasonML:stä, josta varmasti saa irti kaiken mahdollisen.

Ja loppukaneettina: oma usko on edelleen vahva, että Reactin / RN:n kulta-aikaa eletään helposti vielä 2019 ja 2020.

 

[Stephen Elop]

Oma reactJS opiskelu oli nyt vuoden tauolla. Nyt erinäisistä syistä johtuen täytyisi lapsikomponentin button klikkauksella muuttaa isäntä komponentin tilaa. Lambda eli nuolifunktiota ei voi käyttämässäni versiossa käyttää ja typescripti on käytössä ja tslint asetukset erittäin paranoidit.

Isäntäkomponentin funktio, jonka pitäisi muuttaa tilaa

public changestete(event: any )
{
alert("Second " + event);

alertti vain näyttää tyhjää, joten this.state.value = arvo ei myöskää voi toimia.

Isäntä komponentin render funktiossa luodaan lapset seuraavasti

const valuestate = this.state.value;
const childstatechange = this.changestete;
<Square positionX={0} positionY={valuestate} onChange={childstatechange}/>

Ja lapsikomponentissa oleelliset kohdat ovat

public props: {
positionX: number;
positionY: number;
onChange: any;
}
constructor(positionX: number = 0, positionY: number = 0, onChange: any){
super(positionX, positionY);
this.handleChange = this.handleChange.bind(this);
}

public render(){
<button
className="squarebutton" onClick={this.handleChange}
>

private handleChange(e: any) {
// alert("First is" + e );
this.props.onChange(e.target.value);
}

Edit. Lisätuktimista

private handleChange(e: any) {
alert("First is" + e.target ); tulostaa

HTMLButtonelement.

e.target.value on tyhjä. Tähän pitäisi nyt saada jotain, jota sitten käyttää isäntäkomponentissa, jotta tilaa voi muuttaa isäntäkomponentissa.

edit. Kooditägit

 

[Paapaa]

@Stephen Elop, laitatko aluksi koodin koodi-tägeihin ja sisennä se luettavaksi, kiitos

 

[Zvona]

ainakin:

<Square positionX={0} positionY={valuestate} onChange={childstatechange.bind(this)}/>

lisäksi:

private handleChange(evt: any): void {
  this.props.onChange(evt);
}

Mutta kuten todettua, niin koodi hieman kauniimmaksi ja sen jälkeen vaikkapa CodeSandbox: Online Code Editor Tailored for Web Application Development muiden räpellättäväksi

 

[Stephen Elop]

ainakin:
[KOODI]<Square positionX={0} positionY={valuestate} onChange={childstatechange.bind(this)}/>[/KOODI]

Failed to compile
Binds are forbidden in JSX attributes due to their rendering performance impact

Edit. Seuraavalla kääntyi, mutta lopputulos silti sama. Isäntäkomponentti ei saa mitään arvoa parametrinä.

const childstatechange = this.changestete.bind(this);
<Square positionX={0} positionY={valuestate} onChange={childstatechange}/>

Edit. Lisäys.
OK. Toi bind isäntäkomponentissa mahdollistaa isäntäkomponenti funktiossa this viitteen käyttämisen. Saan varmaan nyt toimimaan kun päivitän vielä tilaa oikein. Onko tuo temppu silti mahdollista jotenkin muuten kuin tuota bindia käyttämällä?

 

[Zigh]

Onko tuo temppu silti mahdollista jotenkin muuten kuin tuota bindia käyttämällä?

Arrow funktiolla:

<Square positionX={0} positionY={valuestate} onChange={(e: any) => { this.props.onChange(e); }}/>

Edit: äh, nyt vasta luin että nuolifunktiot ei käytettävissä. No jätetään kuitenkin tämä tähän...

Muuta keinoa this:n säilyttämiseen ei ole kuin bind tai arrow func.

 

[Paapaa]

@Stephen Elop, jos treenaat Reactia, ei pitäisi olla mitään syytä jättää käyttämättä nuolifunktioita.

 

[Stephen Elop]

@Stephen Elop, jos treenaat Reactia, ei pitäisi olla mitään syytä jättää käyttämättä nuolifunktioita.

No sinällään ei, mutta kun aloitin tämän sillä createreactapp komennolla, tuli siihen semmonen versio, joka ei hyväksy nuolifunkkaria React -komponenttien render -metdodissa. Eli ihan just ton syvemmän opettelun takia tässä vähän isketään päätä seinään. Nuolifunktioita voin sitten käyttää muissa luokissa, jotka ei ole React -komponentteja.

 

[Paapaa]

No sinällään ei, mutta kun aloitin tämän sillä createreactapp komennolla, tuli siihen semmonen versio, joka ei hyväksy nuolifunkkaria React -komponenttien render -metdodissa. Eli ihan just ton syvemmän opettelun takia tässä vähän isketään päätä seinään. Nuolifunktioita voin sitten käyttää muissa luokissa, jotka ei ole React -komponentteja.

Hmm, mikäs versio, kyllä kai niiden pitäisi toimia create-react-app:lla ihan hyvin joka paikassa. Tai mikä virhe tulee? Ja laita lyhyt koodiesimerkki.

 

[Zvona]

Mä en ole kyllä kuullut, että CRA / CRNA kieltäisi fat arrow functionit. Eli

class Foo extends React.Component<*> {
  ...
  private someFunction = () => {
    ...
  }
}

on siis kielletty? Tästä tulee erillinen herja?

 

[Stephen Elop]

Hmm, mikäs versio, kyllä kai niiden pitäisi toimia create-react-app:lla ihan hyvin joka paikassa. Tai mikä virhe tulee? Ja laita lyhyt koodiesimerkki.

Lambdas are forbidden in JSX attributes due to their rendering performance impact

Lisäsin tollasen nyt tuon isäntä komponentin render -metodin alkuun.

<button onClick={ ()=>{alert("Does not compile");}} >Buttoni</button>

package.json versiot

{
"name": "reactfront",
"version": "0.1.0",
"private": true,
"dependencies": {
"react": "^16.4.1",
"react-dom": "^16.4.1",
"react-scripts-ts": "2.16.0"
},
"devDependencies": {
"@types/jest": "^23.1.2",
"@types/node": "^10.3.6",
"@types/react": "^16.4.2",
"@types/react-dom": "^16.0.6",
"moment": "^2.22.2",
"react-dates": "^17.0.0",
"typescript": "^2.9.2"
}

 

[Paapaa]

Lambdas are forbidden in JSX attributes due to their rendering performance impact

Aa, lintteri herjaa potentiaalisesta suorituskykyongelmasta kun uusia funktioita luodaan render-metodissa. Sinänsä ei liity nuolifunktioiden toimivuuteen: ne toimivat kyllä sinulla. Normaalisti sinne onClickiin tungetaan esim. propsina välitetty klikkihandleri (viittaus funktioon) tai komponentissa (luokassa) määritelty handleri, jolloin herjaa labdastakaan ei tule. Eli laita sinne komponenttiin renderin ulkpuolelle:

handleClick = () => alert('Moikka');

Ja buttoniin:

onClick={this.handleClick}

Jos haluat kunnon tehokurssin Reactiin, niin katso kun Full Stack Open 2019 avautuu: MOOC.fi

Ja näppärä alusta testailla:

CodeSandbox: Online Code Editor Tailored for Web Application Development

 

[Stephen Elop]

Tuo this referenssin katoaminen on ecmascript juttuja Function binding

Taidan muuttaa lintterin asetuksia hieman. Onhan toi lambda funktioiden esto vähän typerä. Tulee koodista vähän siistimpää niiden kanssa ja en oikein usko hirveään suorituskykyongelmaan niiden käytön kanssa.

 

[mopnex]

Yllä tulikin jo hyvät vinkit arrow-functionin käyttöön @Paapaa :n viestissä. Suorituskyky on hyvä pitää mielessä, mutta ennenaikainen optimointi ei hyödytä ketään. Mittauksia pitää olla tueksi jos lähtee optimoimaan: lähtötilanne ja tilanne optimointien jälkeen (mielellään toki siinä välissäkin). Hyvä että löysit aiheesta asiaa, suosittelen resurssina jos on JS:n liittyvää niin lisämään hakuun "mdn" (MDN Web Docs, ennen Mozilla Developer Network :shrug. Tuota materiaalia ylläpitää nykyään Mozillan lisäksi mm. Google ja Microsoft *.

Function.prototype.bind()
getify/You-Dont-Know-JS

Tärkeintä on ymmärtää aina se syy, miksi jokin asia on huono / hyvä. Sitten voi tehdä omia päätelmiä tilanteen mukaan.

* Mozilla brings Microsoft, Google, the W3C, Samsung together to create cross-browser documentation on MDN – The Mozilla Blog

 

[Stephen Elop]

Function.prototype.bind()

Kiitos. Tuolla onkin tuo tärkein asia javascriptiin liittyen. Tuon kun sisäistää, niin sitten saa aikaan kaiken mitä javascriptillä voi saada aikaan.

Edit: Lainaus meni väärin. Eli tuota tarkoitin getify/You-Dont-Know-JS

Todella hyvä kyllä.

 

[Janz]

Tuo this referenssin katoaminen on ecmascript juttuja Function binding

Taidan muuttaa lintterin asetuksia hieman. Onhan toi lambda funktioiden esto vähän typerä. Tulee koodista vähän siistimpää niiden kanssa ja en oikein usko hirveään suorituskykyongelmaan niiden käytön kanssa.

Itsellä tulee kyllä ihan surutta käytettyä lamboja propseissa aina, ei niillä todellakaan niin kummosta suorituskykyhittiä ole.

 

[greenlight]

edit: ...

 

[nnaku]

Itsellä tulee kyllä ihan surutta käytettyä lamboja propseissa aina, ei niillä todellakaan niin kummosta suorituskykyhittiä ole.

Jännä että suorituskyvystäkin voidaan tehdä mielipiteitä.

qkpn5kmkrq - CodeSandbox
(console auki)

Tossa on esimerkki siitä kuinka inline funktio tai bindaus renderissä rikkoo reactin sisäänrakennetun optimoinnin. PureComponent on näistä helpoin esimerkki.

Users 1 renderöit 9 kertaa User komponentin mountissa ja poistaessa kaikki User:it yksitellen, et renderöi yhtään User komponenttia koska se olisi vain idioottimaista. Eihän mikään ei ole muuttunut!

Users 2 renderöit 9 kertaa User komponentin mountissa ja poistaessa kaikki User:it yksitellen, renderöit User komponenteja 36 kertaa. Ai miksi vitussa? Parentti lähettää anonyymin funtion ja User Renderöi koska sai "uuden funktion".

Ja sitten kun tehdään jotain vähän isompaa kokonaisuutta niin homma alkaa perkelöityä aika äkkiä. Kuvittele vaikka että, noilla usereilla on muutama componentti jolla on muutama componentti jolla on....

 

[Janz]

Jännä että suorituskyvystäkin voidaan tehdä mielipiteitä.
...

Se, miten suuri ero onkin oikeasti selaimessa, onkin ihan eri tarina. Jos se millisekunti nelinkertaistuu niin ei siinä käyttäjä huomaa yhtään mitään.

 

[nnaku]

Se, miten suuri ero onkin oikeasti selaimessa, onkin ihan eri tarina. Jos se millisekunti nelinkertaistuu niin ei siinä käyttäjä huomaa yhtään mitään.

Millä laitteella? Ettei vaan joku työpöytä prossu ja uusin chrome? Mites noi low-tier "älypuhelimet", vai onko se sitten käyttän vika kun, itse et viitsi kirjoittaa hyvää koodia vaikka työkalut siihen on annettu?

 

[Janz]

Millä laitteella? Ettei vaan joku työpöytä prossu ja uusin chrome? Mites noi low-tier "älypuhelimet", vai onko se sitten käyttän vika kun, itse et viitsi kirjoittaa hyvää koodia vaikka työkalut siihen on annettu?

Totta kai, kenenkäs muunkaan

 

[greenlight]

Ja sitten kun tehdään jotain vähän isompaa kokonaisuutta niin homma alkaa perkelöityä aika äkkiä. Kuvittele vaikka että, noilla usereilla on muutama componentti jolla on muutama componentti jolla on....

Homma eskaloituu siinä vaiheessa täyteen infernoon, kun näillä alikomponenteilla on myös sama "ominaisuus" eli lambda jossain propertyssä, niin ymmärtääkseni se silloin rendaa n*m kertaa vaikka oikea tarve olisi nolla.

Se, miten suuri ero onkin oikeasti selaimessa, onkin ihan eri tarina. Jos se millisekunti nelinkertaistuu niin ei siinä käyttäjä huomaa yhtään mitään.

Tässä ei ole kyse mistään millisekunneista vaan kyse on ihan oikeasti sellaisesta ydinkysymyksestä, joka voi yksinään tehdä muuten hyvästä ohjelmasta kasan höyryävää paskaa, jota kaikki käyttäjät tulevat vihaamaan.

 

[Stephen Elop]

Nyt täytyisi omaan react -peliprojektiin tehdä lyhyin polku -haku 2d kartalle. Eli algoritmeja ja tietorakenteita pitäisi lisätä. Onko reactille jotain spesifistä pakettia, vai kannattaako käyttää tätä javascript-algorithms-and-data-structures vai mahdollisesti jotain muuta pakettia?

 

[nnaku]

Nyt täytyisi omaan react -peliprojektiin tehdä lyhyin polku -haku 2d kartalle. Eli algoritmeja ja tietorakenteita pitäisi lisätä. Onko reactille jotain spesifistä pakettia, vai kannattaako käyttää tätä javascript-algorithms-and-data-structures vai mahdollisesti jotain muuta pakettia?

Olisko tästä apua?
ahuth/evolved-salesman