Kun erittäin mielenkiintoisen ja innovatiivisen projektin pääkehittäjä ehdotti siirtymistä AngularJS: stä Elmiin, ensimmäinen ajatukseni oli: Miksi?

Meillä oli jo hienosti kirjoitettu AngularJS-sovellus, joka oli kiinteässä tilassa, hyvin testattu ja todistettu tuotannossa. Ja Angular 4, joka on kelvollinen päivitys AngularJS: ltä, olisi voinut olla luonnollinen valinta uudelleenkirjoittamiseen - samoin React tai Vue. Hirma näytti olevan joku outo toimialakohtainen kieli, josta ihmiset ovat tuskin kuulleet.

No, se oli ennen kuin tiesin mitään Elmistä. Nyt kun minulla on jonkin verran kokemusta siitä, varsinkin kun olen siirtynyt siihen AngularJS: stä, luulen voivani antaa vastauksen 'miksi'.

Tässä artikkelissa käymme läpi Elmin hyvät ja huonot puolet ja kuinka jotkut sen eksoottisista käsitteistä sopivat täydellisesti käyttöliittymän web-kehittäjä . Saat enemmän opetusohjelman kaltaisen Hoh-kieliartikkelin katsomalla tämä blogiviesti .

Hirma: Puhtaasti toiminnallinen ohjelmointikieli

Jos olet tottunut ohjelmoimaan Java- tai JavaScriptiä ja tuntuu siltä, ​​että se on luonnollinen tapa kirjoittaa koodia, tynnyrin oppiminen voi olla kuin kaatuminen kanin reikään.

Ensimmäinen asia, jonka huomaat, on outo syntakse: ei aaltosulkeita, paljon nuolia ja kolmioita.

Voit oppia elämään ilman kiharaisia ​​aaltosulkeita, mutta miten määrität ja pesit koodilohkot? Tai missä on for silmukka tai jokin muu silmukka, tältä osin? Vaikka selkeä laajuus voidaan määritellä let lohko, ei ole lohkoja klassisessa mielessä eikä silmukoita ollenkaan.

Elm on puhtaasti toimiva, voimakkaasti kirjoitettu, reaktiivinen ja tapahtumavetoinen web-asiakkaan kieli.

Saatat alkaa miettiä, onko ohjelmointi edes mahdollista tällä tavalla.

Todellisuudessa nämä ominaisuudet antavat sinulle hämmästyttävän paradigman ohjelmointiin ja hyvien ohjelmistojen kehittämiseen.

Puhtaasti toimiva

Saatat ajatella, että käyttämällä Java: n tai ECMAScript 6: n uudempaa versiota voit tehdä toiminnallisen ohjelmoinnin. Mutta se on vain sen pinta.

Näillä ohjelmointikielillä sinulla on edelleen pääsy kielirakenteiden arsenaaliin ja houkutus turvautua sen ei-toiminnallisiin osiin. Ero todellakin on silloin, kun et voi tehdä muuta kuin toiminnallista ohjelmointia. Siinä vaiheessa alat lopulta tuntea kuinka luonnollinen toiminnallinen ohjelmointi voi olla.

Elmissä melkein kaikki on funktio. Tietueen nimi on funktio, unionityypin arvo on funktio - jokainen funktio koostuu argumentteihinsa osittain sovelletuista funktioista. Jopa operaattorit, kuten plus (+) ja miinus (-), ovat toimintoja.

Kaikkien muiden puuttuminen on ensiarvoisen tärkeää julistaa ohjelmointikieli puhtaasti toiminnalliseksi tällaisten rakenteiden olemassaolon sijaan. Vasta sitten voit aloittaa ajattelun puhtaasti toiminnallisella tavalla.

Elm on mallinnettu funktionaalisen ohjelmoinnin kypsistä käsitteistä, ja se muistuttaa muita toiminnallisia kieliä, kuten Haskell ja OCaml.

Voimakkaasti kirjoitettu

Jos ohjelmoit Java- tai TypeScript-muodossa, tiedät mitä tämä tarkoittaa. Jokaisella muuttujalla on oltava täsmälleen yksi tyyppi.

Joitakin eroja on tietysti olemassa. Kuten TypeScriptissä, tyypin ilmoittaminen on valinnainen. Jos sitä ei ole läsnä, se päätellään. Mutta ei ole mitään 'tyyppiä'.

Java tukee yleisiä tyyppejä, mutta paremmin. Yleiset Java-tiedostot lisättiin myöhemmin, joten tyypit eivät ole yleisiä, ellei toisin mainita. Ja niiden käyttämiseen tarvitaan uglysyntax.

Elmissä tyypit ovat yleisiä, ellei toisin mainita. Katsotaanpa esimerkkiä. Oletetaan, että tarvitsemme menetelmän, joka ottaa luettelon tietystä tyypistä ja palauttaa luvun. Java-tilassa se olisi:

public static int numFromList(List list){ return list.size(); }

Ja Elm-kielellä:

numFromList list = List.length list

Vaikka olet valinnainen, suosittelen ehdottomasti, että lisäät tyypin ilmoitukset. Elm-kääntäjä ei koskaan salli toimintoja väärillä tyypeillä. Ihmiselle on paljon helpompaa tehdä tällainen virhe, etenkin kielen oppimisen aikana. Joten yllä oleva ohjelma tyyppimerkinnöillä olisi:

numFromList: List a -> Int numFromList list = List.length list

Aluksi voi tuntua epätavalliselta ilmoittaa tyypit erilliselle riville, mutta jonkin ajan kuluttua se alkaa näyttää luonnolliselta.

Web Client -kieli

Tämä tarkoittaa yksinkertaisesti sitä, että Elm kääntyy JavaScriptiin, joten selaimet voivat suorittaa sen verkkosivulla.

Ottaen huomioon, että se ei ole yleiskäyttöinen kieli, kuten Java tai Node.js: n sisältävä JavaScripti, vaan verkkotunnuskohtainen kieli verkkosovellusten asiakasosan kirjoittamiseen. Vielä enemmän, Elm sisältää sekä liiketoimintalogiikan (mitä JavaScript tekee) että esittelyosan (mitä HTML tekee) kirjoittamisen - kaikki yhdellä toiminnallisella kielellä.

Kaikki nämä tehdään hyvin spesifisellä kehyksen kaltaisella tavalla, jota kutsutaan Elm-arkkitehtuuriksi.

Reaktiivinen

Elm Architecture on reaktiivinen verkkokehys. Mallien muutokset hahmonnetaan välittömästi sivulla ilman nimenomaista DOM-manipulointia.

Tällä tavoin se on samanlainen kuin Angular tai React. Mutta Elm tekee sen myös omalla tavallaan. Avain sen perusteiden ymmärtämiseen on view allekirjoituksessa ja update toiminnot:

view : Model -> Html Msg update : Msg -> Model -> Model

Elm-näkymä ei ole vain mallin HTML-näkymä. Se on HTML, joka voi tuottaa sellaisia ​​viestejä Msg missä Msg on tarkka määrittelemäsi liittotyyppi.

Mikä tahansa tavallinen sivutapahtuma voi tuottaa viestin. Ja kun viesti tuotetaan, Elm kutsuu sisäisesti päivitystoiminnon kyseisellä viestillä, joka sitten päivittää mallin viestin ja nykyisen mallin perusteella, ja päivitetty malli on jälleen sisäisesti näkymässä.

Tapahtumavetoinen

Paljon kuin JavaScript, Elm on tapahtumavetoinen. Mutta toisin kuin esimerkiksi Node.js, jossa asynkronitoiminnoille tarjotaan yksittäisiä takaisinkutsuja, Elm-tapahtumat on ryhmitelty erillisiin sanomaryhmiin, jotka on määritelty yhdeksi viestityypiksi. Ja kuten minkä tahansa liitostyypin kohdalla, erillisten tyyppiarvojen sisältämät tiedot voivat olla mitä tahansa.

Viestejä voi tuottaa kolme tapahtumalähdettä: käyttäjän toimet Html -sivulla tilausnäkymä, komentojen suorittaminen ja ulkoiset tapahtumat. Siksi kaikki kolme tyyppiä, Html, Cmd ja Sub sisältää msg heidän väitteensä. Ja yleinen msg tyypin on oltava sama kaikissa kolmessa määritelmässä - sama, joka toimitetaan päivitystoiminnolle (edellisessä esimerkissä se oli Msg -tyyppi, isolla M-kirjaimella), jossa kaikki viestien käsittely on keskitetty.

Realistisen esimerkin lähdekoodi

Tästä löydät täydellisen esimerkin Elm-verkkosovelluksesta GitHub-arkisto . Vaikka se on yksinkertainen, se näyttää suurimman osan jokapäiväisessä asiakasohjelmoinnissa käytetyistä toiminnoista: tietojen noutaminen REST-päätepisteestä, JSON-tietojen dekoodaus ja koodaus, näkymien, viestien ja muiden rakenteiden käyttö, kommunikointi JavaScriptin kanssa ja kaikki, mitä tarvitaan kokoamiseen ja pakkaamiseen Elm-koodi Webpackilla.

Sovellus näyttää luettelon palvelimelta haetuista käyttäjistä.

Asennuksen / esittelyprosessin helpottamiseksi Webpackin dev-palvelinta käytetään kaiken pakkaamiseen, mukaan lukien Elm, ja käyttäjän luettelon tarjoamiseen.

Osa toiminnoista on Elmissä ja osa JavaScriptissä. Tämä tehdään tarkoituksella yhdestä tärkeästä syystä: Yhteentoimivuuden osoittamiseksi. Haluat luultavasti kokeilla Käynnistä käynnistystä tai vaihtaa siihen asteittain olemassa olevaa JavaScript-koodia tai lisätä uusia toimintoja Elmin kielelle. Yhteentoimivuuden myötä sovelluksesi toimii edelleen sekä Elm- että JavaScript-koodin kanssa. Tämä on luultavasti parempi tapa kuin aloittaa koko sovellus alusta alkaen Elmissä.

Esimerkkikoodin Halk-osa alustetaan ensin JavaScript-määritystiedoilla, minkä jälkeen käyttäjäluettelo haetaan ja näytetään Halk-kielellä. Oletetaan, että Java-käyttöjärjestelmässä on jo joitain käyttäjän toimintoja, joten käyttäjän toiminnon kutsuminen Elmiin lähettää vain puhelun takaisin siihen.

Koodissa käytetään myös joitain seuraavassa osassa selitettyjä käsitteitä ja tekniikoita.

Elm-käsitteiden soveltaminen

Käykäämme läpi joitakin eksoottisia käsitteitä Elm-ohjelmointikielestä todellisissa tilanteissa.

Unionityyppi

Tämä on jalkakielen puhdasta kultaa. Muistatko kaikki ne tilanteet, joissa rakenteellisesti erilaista dataa oli käytettävä samalla algoritmilla? Näiden tilanteiden mallinnaminen on aina vaikeaa.

Tässä on esimerkki: Kuvittele, että luot sivutusta luettelollesi. Jokaisen sivun lopussa on oltava linkit edelliselle, seuraavalle ja kaikille sivuille niiden numeroiden mukaan. Kuinka jäsennät sen pitämään sen linkin tiedot, jota käyttäjä napsautti?

Voimme käyttää useita soittopyyntöjä edellisiin, seuraaviin ja sivunumeroklikkauksiin, tai voimme käyttää yhtä tai kahta loogista kenttää osoittamaan, mitä napsautettiin, tai antaa erityistä merkitystä tietyille kokonaisluvuille, kuten negatiivisille numeroille, nollalle jne. Mutta mikään nämä ratkaisut voivat mallintaa täsmälleen tällaisen käyttäjän tapahtuman.

Elmissä se on hyvin yksinkertaista. Määritettäisiin liittotyyppi:

type NextPage = Prev | Next | ExactPage Int

Ja käytämme sitä parametrina yhdelle viestistä:

type Msg = ... | ChangePage NextPage

Lopuksi päivitämme toiminnon saamaan case tarkistaa nextPage -tyyppi:

update msg model = case msg of ChangePage nextPage -> case nextPage of Prev -> ... Next -> ... ExactPage newPage -> ...

Se tekee asioista erittäin tyylikkäitä.

Useiden karttatoimintojen luominen <|

Monissa moduuleissa on map -funktio, ja useita variantteja voidaan soveltaa eri argumenttimäärään. Esimerkiksi List on map, map2,…, enintään map5. Mutta entä jos meillä on funktio, joka vie kuusi argumenttia? Ei ole map6 Mutta on tekniikka sen voittamiseksi. Se käyttää <| funktio parametrina ja osatoiminnot, ja joitain argumentteja käytetään välituloksina.

Oletetaan yksinkertaisuuden vuoksi a List vain map ja map2, ja haluamme käyttää funktiota, joka vie kolme argumenttia kolmelle listalle.

Näin toteutus näyttää:

map3 foo list1 list2 list3 = let partialResult = List.map2 foo list1 list2 in List.map2 (<|) partialResult list3

Oletetaan, että haluamme käyttää foo, joka vain kertoo sen numeeriset argumentit, jotka määritellään seuraavasti:

foo a b c = a * b * c

Joten tulos map3 foo [1,2,3,4,5] [1,2,3,4,5] [1,2,3,4,5] on [1,8,27,64,125] : List number.

Selvitetään, mitä täällä tapahtuu.

Ensinnäkin partialResult = List.map2 foo list1 list2, foo käytetään osittain jokaiseen pariin list1 ja list2. Tuloksena on [foo 1 1, foo 2 2, foo 3 3, foo 4 4, foo 5 5], luettelo toiminnoista, jotka ottavat yhden parametrin (koska kaksi ensimmäistä on jo käytössä) ja palauttaa luvun.

Seuraavaksi List.map2 (<|) partialResult list3, se on oikeastaan ​​List.map2 (<|) [foo 1 1, foo 2 2, foo 3 3, foo 4 4, foo 5 5] list3. Kutakin näiden kahden luettelon paria varten kutsumme (<|) toiminto. Esimerkiksi ensimmäiselle parille se on (<|) (foo 1 1) 1, joka on sama kuin foo 1 1 <| 1, joka on sama kuin foo 1 1 1, joka tuottaa 1. Toiseksi se on (<|) (foo 2 2) 2, joka on foo 2 2 2, joka arvioi arvon 8 ja niin edelleen.

Tämä menetelmä voi olla erityisen hyödyllinen mapN toiminnot JSON-objektien dekoodaamiseen monilla kentillä, kuten Json.Decode tarjoaa heille jopa map8

Poista kaikki arvot Maybes-luettelosta

Oletetaan, että meillä on luettelo Maybe arvoja, ja haluamme poimia vain arvot niistä elementeistä, joilla on yksi. Esimerkiksi luettelo on:

list : List (Maybe Int) list = [ Just 1, Nothing, Just 3, Nothing, Nothing, Just 6, Just 7 ]

Ja haluamme saada [1,3,6,7] : List Int. Ratkaisu on tämä yhden rivin lauseke:

List.filterMap identity list

Katsotaanpa miksi tämä toimii.

List.filterMap odottaa ensimmäisen argumentin olevan funktio (a -> Maybe b), jota käytetään toimitetun luettelon elementteihin (toinen argumentti), ja tuloksena oleva luettelo suodatetaan siten, että kaikki Nothing arvot ja sitten todelliset arvot puretaan Maybe s: stä.

Meidän tapauksessamme toimitimme identity, joten tuloksena oleva luettelo on jälleen [ Just 1, Nothing, Just 3, Nothing, Nothing, Just 6, Just 7 ]. Suodattamisen jälkeen saamme [ Just 1, Just 3, Just 6, Just 7 ], ja arvon purkamisen jälkeen se on [1,3,6,7], kuten halusimme.

Mukautettu JSON-dekoodaus

Kun tarpeemme JSON-dekoodauksessa (tai deserialisoinnissa) alkavat ylittää mitä Json.Decode moduulilla, meillä saattaa olla ongelmia uusien eksoottisten dekooderien luomisessa. Tämä johtuu siitä, että näitä dekoodereita kutsutaan dekoodausprosessin keskeltä, esim. Http menetelmiä, eikä ole aina selvää, mitkä ovat niiden panokset ja tuotokset, varsinkin jos toimitetussa JSON: ssa on paljon kenttiä.

Tässä on kaksi esimerkkiä siitä, miten tällaisia ​​tapauksia käsitellään.

Ensimmäisessä on kaksi kenttää saapuvassa JSON: ssa, a ja b, jotka merkitsevät suorakulmaisen alueen sivuja. Mutta Elm-objektissa haluamme tallentaa vain sen alueen.

import Json.Decode exposing (..) areaDecoder = map2 (*) (field 'a' int) (field 'b' int) result = decodeString areaDecoder '''{ 'a':7,'b':4 }''' -- Ok 28 : Result.Result String Int

Kentät dekoodataan yksitellen field int -merkillä dekooderin, ja sitten molemmat arvot syötetään annettuun funktioon kohdassa map2 Koska kertolasku (*) on myös funktio ja se vaatii kaksi parametria, voimme käyttää sitä vain. Tuloksena areaDecoder on dekooderi, joka palauttaa toiminnon tuloksen, kun sitä käytetään, tässä tapauksessa a*b

Toisessa esimerkissä saamme sotkuisen tilakentän, joka voi olla tyhjä, tai mikä tahansa merkkijono, myös tyhjä, mutta tiedämme, että operaatio onnistui vain, jos se on “OK”. Tällöin haluamme tallentaa sen nimellä True ja kaikissa muissa tapauksissa False. Dekooderimme näyttää tältä:

okDecoder = nullable string |> andThen (ms -> case ms of Nothing -> succeed False Just s -> if s == 'OK' then succeed True else succeed False )

Sovelletaan sitä joihinkin JSON: iin:

decodeString (field 'status' okDecoder) '''{ 'a':7, 'status':'OK' }''' -- Ok True decodeString (field 'status' okDecoder) '''{ 'a':7, 'status':'NOK' }''' -- Ok False decodeString (field 'status' okDecoder) '''{ 'a':7, 'status':null }''' -- Ok False

Täällä avain on toiminnossa, joka toimitetaan andThen: lle, joka ottaa edellisen tyhjennettävän merkkijonodekooderin (joka on Maybe String) tuloksen, muuntaa sen mitä tarvitsemme ja palauttaa tuloksen dekooderina avulla succeed.

Avain takeaway

Kuten näistä esimerkeistä voidaan nähdä, toiminnallinen ohjelmointi ei välttämättä ole kovin intuitiivista Java- ja JavaScript-kehittäjille. Tottuminen vie jonkin aikaa, paljon kokeiluja ja virheitä. Voit ymmärtää sitä käyttämällä elm-repl käyttää ja tarkistaa lausekkeiden palautustyypit.

Tämän artikkelin aiemmin linkittämä esimerkkiprojekti sisältää useita muita esimerkkejä mukautetuista dekoodereista ja koodereista, jotka voivat myös auttaa sinua ymmärtämään niitä.

Mutta silti, miksi valita jalava?

Koska Elm-kieli on niin erilainen kuin muut asiakaskehykset, se ei todellakaan ole 'vielä yksi JavaScript-kirjasto'. Sellaisena sillä on paljon piirteitä, joita voidaan pitää positiivisina tai negatiivisina verrattuna niihin.

Aloitetaan ensin positiivisella puolella.

Asiakasohjelmointi ilman HTML: ää ja JavaScriptiä

Lopuksi sinulla on kieli, jolla voit tehdä kaiken. Ei enää erillisyyttä ja hankalia yhdistelmiä niiden sekoittamisesta. Ei HTML-koodia JavaScriptissä eikä mukautettuja mallikieliä joillakin poistetuilla logiikkasäännöillä.

Hirmin kanssa sinulla on vain yksi syntaksi ja yksi kieli, täydellisessä loistossaan.

Yhtenäisyys

Koska melkein kaikki käsitteet perustuvat funktioihin ja muutamaan rakenteeseen, syntaksit ovat hyvin ytimekkäitä. Sinun ei tarvitse huolehtia, jos jokin menetelmä on määritelty esiintymän tai luokan tasolla tai jos se on vain funktio. Ne ovat kaikki moduulitasolla määriteltyjä toimintoja. Luetteloiden toistamiseen ei ole sata erilaista tapaa.

Useimmilla kielillä on aina tämä väite siitä, kirjoitetaanko koodi kielen tavalla. Paljon idioomeja on opittava.

Elmissä, jos se kootaan, se on todennäköisesti 'Elm' -tapa. Jos ei, niin se ei todellakaan ole.

Ilmeikkyys

Vaikka Elm-syntaksi on ytimekäs, se on hyvin ilmeikäs.

Tämä saavutetaan lähinnä liittotyyppien, muodollisten tyyppideklarointien ja toiminnallisen tyylin avulla. Kaikki nämä innoittavat käyttämään pienempiä toimintoja. Lopussa saat koodin, joka on melko paljon itse dokumentoitava.

Ei Null

Kun käytät Java- tai JavaScriptiä pitkään aikaan, null tulee jotain sinulle täysin luonnollista - väistämätön osa ohjelmointia. Ja vaikka näemme jatkuvasti NullPointerException ja erilaisia ​​TypeError s, emme silti usko, että todellinen ongelma on null: n olemassaolo. Se on vain niin luonnollinen .

Se käy nopeasti selville jonkin ajan kuluttua Elmin kanssa. Ei ole null ei vain vapauta meitä näkemästä ajonaikaisia ​​nollaviittausvirheitä uudestaan ​​ja uudestaan, se auttaa myös kirjoittamaan parempaa koodia määrittelemällä ja käsittelemällä selkeästi kaikki tilanteet, joissa todellista arvoa ei välttämättä ole, mikä vähentää myös teknistä velkaa lykkäämättä null käsittely, kunnes jotain rikkoutuu.

Luottamus siihen, että se toimii

Syntaktisesti oikeiden JavaScript-ohjelmien luominen voidaan tehdä hyvin nopeasti. Mutta toimiiko se todella? Katsotaanpa, kun sivu on ladattu uudelleen ja testattu perusteellisesti.

Hirven kanssa se on päinvastoin. Staattisella tyyppitarkistuksella ja pakotetulla null tarkistaa, se vaatii jonkin aikaa kääntämiseen, varsinkin kun aloittelija kirjoittaa ohjelman. Mutta kun se on koottu, on hyvät mahdollisuudet toimia oikein.

Nopeasti

Tämä voi olla tärkeä tekijä asiakaskehystä valittaessa. Laajan verkkosovelluksen reagointikyky on usein ratkaisevan tärkeää käyttökokemuksen ja siten koko tuotteen menestymisen kannalta. Ja kuten testit osoittavat , Elm on erittäin nopea.

Ammattilaiset Elm vs. perinteiset kehykset

Suurin osa perinteisistä verkkokehyksistä tarjoaa tehokkaita työkaluja verkkosovellusten luomiseen. Mutta tällä voimalla on hinta: liian monimutkainen arkkitehtuuri, jossa on paljon erilaisia ​​käsitteitä ja sääntöjä siitä, miten ja milloin niitä käytetään. Kaiken hallitseminen vie paljon aikaa. On olemassa ohjaimia, komponentteja ja direktiivejä. Sitten on kokoamis- ja määritysvaiheet sekä ajon vaihe. Ja sitten on palveluita, tehtaita ja kaikkia mukautettuja mallikieliä, joita käytetään annetuissa direktiiveissä - kaikki ne tilanteet, joissa meidän on soitettava $scope.$apply() suoraan, jotta sivu päivittyy ja paljon muuta.

Hirmin kääntäminen JavaScriptiin on varmasti myös hyvin monimutkainen, mutta kehittäjä on suojattu tarvitsematta tuntea sen kaikkia muttereita ja pultteja. Kirjoita vain Elm ja anna kääntäjän tehdä työnsä.

Ja miksi ei valita hirmiä?

Riittää kun ylistetään tääriä. Katsotaan nyt joitain sen ei-niin hienoa puolta.

Dokumentointi

Tämä on todella tärkeä asia. Elm-kielestä puuttuu yksityiskohtainen käsikirja.

Viralliset oppaat vain selaavat kieltä ja jättävät paljon vastaamattomia kysymyksiä.

Virallinen API-viite on vielä pahempi. Monista toiminnoista puuttuu minkäänlaista selitystä tai esimerkkejä. Ja sitten on niitä, joilla on lause: ”Jos tämä on hämmentävää, käy läpi Halkarkkitehtuurin opetusohjelma. Se todella auttaa! ' Ei suurin rivi, jonka haluat nähdä virallisissa API-asiakirjoissa.

Toivottavasti tämä muuttuu pian.

En usko, että Elm voidaan hyväksyä laajalti niin heikosta dokumentaatiosta, varsinkin Java- tai JavaScript-käyttäjiltä, ​​joissa tällaiset käsitteet ja toiminnot eivät ole lainkaan intuitiivisia. Niiden ymmärtämiseksi tarvitaan paljon parempaa dokumentointia ja paljon esimerkkejä.

Muoto ja välilyönti

Kihara-aaltosulkeista tai sulkeista pääseminen ja välilyönnin käyttäminen sisennykseen saattaa näyttää hyvältä. Esimerkiksi Python-koodi näyttää erittäin siistiltä. Se ei kuitenkaan riittänyt elm-format: n luojille.

Kun kaikki kaksoisviivatilat ja lausekkeet ja tehtävät on jaettu useisiin viivoihin, Elm-koodi näyttää enemmän pystysuoralta kuin vaakatasolta. Mikä olisi yksi linja vanhassa hyvässä C: ssä, voi helposti ulottua useammalle kuin yhdelle näytölle Elm-kielellä.

Tämä saattaa kuulostaa hyvältä, jos sinulle maksetaan kirjoitetuilla koodiriveillä. Mutta jos haluat kohdistaa jotain 150 riviä aiemmin aloitettuun lausekkeeseen, onnea oikean sisennyksen löytämiseen.

Tietueiden käsittely

Niiden kanssa on vaikea työskennellä. Syntaksi tietueen kentän muokkaamiseksi on ruma. Ei ole helppoa tapaa muokata sisäkkäisiä kenttiä tai viitata mielivaltaisesti kenttiin nimen mukaan. Ja jos käytät lisätoimintoja yleisellä tavalla, oikeassa kirjoittamisessa on paljon ongelmia.

JavaScriptissä tietue tai esine on keskeinen rakenne, joka voidaan rakentaa, käyttää ja muokata monin tavoin. Jopa JSON on vain sarjatuotanto tietueesta. Kehittäjät ovat tottuneet työskentelemään tietueiden kanssa verkko-ohjelmoinnissa, joten vaikeudet niiden käsittelyssä Elmissä voivat tulla havaittaviksi, jos niitä käytetään ensisijaisena tietorakenteena.

Lisää kirjoittamista

Hirmu vaatii enemmän koodin kirjoittamista kuin JavaScript.

Merkkijono- ja numerooperaatioille ei ole implisiittistä tyyppimuunnosta, joten paljon int-float-muunnoksia ja erityisesti toString Tarvitaan puhelut, jotka sitten edellyttävät sulkeita tai funktiosovellussymboleita, jotta ne sopivat oikeaan argumenttimäärään. Myös Html.text funktio edellyttää merkkijonoa argumenttina. Tarvitaan paljon tapauslausekkeita, kaikille niille Maybe s, Results, tyypeille jne.

Tärkein syy tähän on tiukka tyyppijärjestelmä, ja se voi olla kohtuullinen hinta.

JSON-dekooderit ja -kooderit

Yksi alue, jossa enemmän kirjoittamista todella erottuu, on JSON-käsittely. Mikä on yksinkertaisesti JSON.parse() soita JavaScriptissä voi ulottua satoihin viivoihin Elm-kielellä.

Tietysti tarvitaan jonkinlainen kartoitus JSON- ja Elm-rakenteiden välillä. Mutta tarve kirjoittaa sekä dekoodereita että koodereita samalle JSON-palalle on vakava ongelma. Jos REST-sovellusliittymät siirtävät objekteja satojen kenttien kanssa, tämä on paljon työtä.

Paketoida

Olemme nähneet Elmistä, on aika vastata tunnettuihin kysymyksiin, luultavasti yhtä vanhoihin kuin itse ohjelmointikielet: Onko se parempi kuin kilpailu? Pitäisikö meidän käyttää sitä projektissamme?

Vastaus ensimmäiseen kysymykseen voi olla subjektiivinen, koska kaikki työkalut eivät ole vasara eikä kaikki ole naula. Hirvi voi loistaa ja olla parempi valinta muihin web-asiakasjärjestelmiin verrattuna monissa tapauksissa, kun taas toisissa se jää alle. Mutta se tarjoaa todella ainutlaatuisen arvon, joka voi tehdä web-käyttöliittymän kehityksestä paljon turvallisemman ja helpomman kuin vaihtoehdot voivat.

Toiseen kysymykseen, jotta vältetään vastaaminen myös ikivanhalla 'se riippuu' -vastikkeesta, yksinkertainen vastaus on: Kyllä. Kaikista mainituista haitoista huolimatta pelkkä luottamus, jonka Elm antaa sinulle, että ohjelmasi on oikea, on riittävä syy käyttää sitä.

Elmissä koodaus on myös hauskaa. Se on täysin uusi näkökulma kaikille, jotka ovat tottuneet 'tavanomaisiin' web-ohjelmointiparadigmoihin.

Todellisessa käytössä sinun ei tarvitse vaihtaa koko sovellustasi Elmiin välittömästi tai aloittaa uutta kokonaan siinä. Voit hyödyntää sen yhteentoimivuutta JavaScriptin kanssa, jotta voit kokeilla sitä. Aloita osa käyttöliittymästä tai joistakin toiminnoista, jotka on kirjoitettu Hamm-kielellä. Löydät nopeasti, sopiiko se tarpeisiisi, ja laajenna sen käyttöä tai jätä se. Ja kuka tietää, saatat myös rakastua toimivaan web-ohjelmointiin.

Liittyvät: ClojureScriptin löytäminen etupään kehitykseen

Perustietojen ymmärtäminen

Mikä on Elmin ohjelmointikieli?

Elm on puhtaasti toimiva, voimakkaasti kirjoitettu, reaktiivinen ja tapahtumavetoinen web-asiakkaan kieli.