Psst! Siin on põhjus, miks ReasonReact on parim viis Reacti kirjutamiseks

Kas kasutate kasutajaliideste loomiseks Reaktorit? Noh, ka mina olen. Ja nüüd saate teada, miks peaksite Reasoni rakendusi kirjutama, kasutades ReasonML-i.

Reakt on üsna lahe viis kasutajaliideste kirjutamiseks. Kuid kas me saaksime selle veelgi lahedamaks muuta? Parem?

Paremaks muutmiseks peame kõigepealt tuvastama selle probleemid. Mis on Reacti kui JavaScripti teegi põhiprobleem?

Reakt ei olnud JavaScripti jaoks algselt välja töötatud

Reaktorit lähemalt uurides näete, et mõned selle peamised põhimõtted on JavaScripti suhtes võõrad. Räägime eriti muutmatusest, funktsionaalsetest programmeerimispõhimõtetest ja eriti tüübisüsteemist.

Parandamatus on üks Reaxi põhiprintsiipe. Te ei soovi oma rekvisiite ega olekut muteerida, sest kui seda teete, võivad teil tekkida ettearvamatud tagajärjed. JavaScriptis pole meil muutumatust. Hoiame oma andmestruktuure konventsiooni abil muutumatuna või kasutame selle saavutamiseks raamatukogusid, näiteks muutumatuJS.

React põhineb funktsionaalse programmeerimise põhimõtetel, kuna selle rakendused on funktsioonide koostised. Ehkki JavaScriptil on mõned neist funktsioonidest, näiteks esmaklassilised funktsioonid, pole see funktsionaalne programmeerimiskeel. Kui tahame kirjutada mõnda kena deklaratiivset koodi, peame kasutama väliseid raamatukogusid nagu Lodash / fp või Ramda.

Mis on tüübisüsteemist lahti? Reaktis oli meil PropTypes. Oleme neid JavaScripti tüüpide jäljendamiseks kasutanud, kuna see pole iseenesest staatiliselt kirjutatud keel. Täpsema staatilise tippimise eeliseks peame jälle kasutama väliseid sõltuvusi, nagu näiteks Flow ja TypeScript.

Reageerige ja JavaScripti võrdlus

Nagu näete, pole JavaScripti ühilduv Reacti põhiprintsiipidega.

Kas on veel mõnda programmeerimiskeelt, mis ühilduks Reaketiga kui JavaScriptiga?

Õnneks on meil ReasonML.

Põhjuses on meil muutumatus karbist väljas. Kuna see põhineb funktsionaalsel programmeerimiskeelel OCaml, on meil sellised funktsioonid sisse ehitatud ka keelde. Mõistus pakub meile ka iseseisvat tugevat tüüpi süsteemi.

Reaktsiooni, JavaScripti ja põhjuse võrdlus

Põhjus on kooskõlas Reacti peamiste põhimõtetega.

Põhjus

See pole uus keel. See on alternatiivne JavaScriptilaadne süntaks ja tööriistakett OCamlile - funktsionaalsele programmeerimiskeelele, mis on olnud kasutusel juba enam kui 20 aastat. Põhjuse lõid Facebooki arendajad, kes kasutasid OCamlit juba oma projektides (Flow, Infer).

Põhjus muudab Cam-tüüpi süntaksi abil OCamli inimestele kättesaadavaks tavakeeles, näiteks JavaScriptis või Java-s. See pakub teile paremat dokumentatsiooni (võrreldes OCamliga) ja kasvavat kogukonda selle ümber. Lisaks on selle hõlpsam integreerimine olemasoleva JavaScripti koodialusega.

OCaml on põhjuse tagapõhi. Põhjusel on sama semantika nagu OCamlil - erinev on ainult süntaks. See tähendab, et võite kirjutada OCamli, kasutades põhjuse JavaScripti-sarnast süntaksit. Selle tulemusel saate ära kasutada OCamli vingeid funktsioone, näiteks selle tugevat tüübisüsteemi ja mustri sobitamist.

Vaatame näidet põhjuse süntaksi kohta.

laske fizzbuzz = (i) =>
  lüliti (i mod 3, i mod 5) {
  | (0, 0) => "FizzBuzz"
  | (0, _) => "Fizz"
  | (_, 0) => "Buzz"
  | _ => string_of_int (i)
  };
jaoks (i 1 kuni 100) {
  Js.log (füüsiline buzz (i))
};

Ehkki me kasutame selles näites mustri sobitamist, sarnaneb see ikkagi JavaScriptiga, eks?

Ainus kasutatav brauserikeel on siiski JavaScript, mis tähendab, et peame selle kompileerima.

Lukukirje

Üks Reasoni võimsatest funktsioonidest on BuckleScripti kompilaator, mis võtab teie põhjuse koodi ja kompileerib selle loetavaks ja teostatavaks JavaScriptiks, kasutades suurt surnud koodi eemaldamist. Kui loete loetavust, kui töötate meeskonnas, kus kõik pole mõistusega tuttavad, kuna nad saavad endiselt lugeda koostatud JavaScripti koodi.

Sarnasus JavaScriptiga on nii lähedal, et mõne põhjuse koodi ei pea kompilaator üldse muutma. Nii saate nautida staatiliselt trükitud keele eeliseid ilma koodi muutmata.

laske lisada = (a, b) => a + b;
lisa (6, 9);

See kood on kehtiv nii põhjustes kui ka JavaScriptides.

BuckleScripti tarnitakse nelja raamatukoguga: standardteek Belt (OCaml-i standardkogu pole piisav) ning seosed JavaScripti, Node.js ja DOM API-dega.

Kuna BuckleScript põhineb OCaml-kompilaatoril, saate lõõmavalt kiire kompilatsiooni, mis on palju kiirem kui Paabel ja mitu korda kiirem kui TypeScript.

Koostagem meie FizzBuzz algoritm, mis on kirjutatud põhjusel JavaScripti.

Põhjus, miks kood kompileeritakse JavaScripti kaudu BuckleScripti kaudu

Nagu näete, on sellest tulenev JavaScripti kood üsna loetav. Näib, nagu oleks selle kirjutanud JavaScripti arendaja.

Põhjus ei kompileeri mitte ainult JavaScripti, vaid ka looduslikku ja baidikoodi. Nii võite kirjutada ühe rakenduse, kasutades süntaksi Reason, ja saaksite seda brauseris käivitada nii MacOS-, Android- kui ka iOS-i telefonides. Seal on Jared Forsythi nimeline mäng Gravitron, mis on kirjutatud põhjusel ja seda saab kasutada kõigil platvormidel, mida ma just mainisin.

JavaScripti ühilduvus

BuckleScript pakub meile ka JavaScripti koostalitlusvõimet. Saate mitte ainult kleepida toimiva JavaScripti koodi oma põhjusbaasi, vaid ka teie põhjuse kood saab selle JavaScripti koodiga suhelda. See tähendab, et saate põhjuse koodi hõlpsalt integreerida oma olemasolevasse JavaScripti koodidebaasi. Lisaks saate oma põhjuskoodis kasutada kõiki NPM-i ökosüsteemi JavaScripti pakette. Näiteks saate ühendada Flow, TypeScripti ja Reasoni ühes projektis.

Kuid see pole nii lihtne. JavaScripti teekide või koodi kasutamiseks rakenduses Reason peate selle esmalt pőhjendama põhjuste köite kaudu. Teisisõnu, selleks, et saaksite kasutada Reasoni tugeva tüübisüsteemi eeliseid, peate sisestama tüübita JavaScripti koodi.

Kui teil on vaja oma põhjuskoodis kasutada JavaScripti teeki, kontrollige, kas teeki oli juba põhjus porditud, sirvides andmebaasi Reason Package Index (Redex). See on veebisait, mis koondab Reasoni ja JavaScripti teekidesse kirjutatud erinevad raamatukogud ja tööriistad koos Reasoni köitega. Kui leidsite oma raamatukogu sealt, saate selle lihtsalt sõltuvusse installida ja seda oma rakenduses Põhjus kasutada.

Kui te aga oma raamatukogu ei leidnud, peate ise kirjutama põhjuse köited. Kui alustate alles Reasonist, pidage meeles, et köidete kirjutamine ei ole asi, millega soovite alustada, kuna see on üks põhjusi, mis on Reasoni ökosüsteemis keerukamad.

Õnneks kirjutan just Postituse köidete kirjutamise kohta postitust, nii et püsige kursis!

Kui vajate JavaScripti teegi funktsioone, ei pea te kirjutama kogu teegi põhjuste köiteid. Seda saate teha ainult vajalike funktsioonide või komponentide jaoks.

ReasonReact

See artikkel räägib React in Reason kirjutamisest, mida saate teha tänu ReasonReact teeki.

Võib-olla mõtled sa nüüd: "Ma ei tea siiani, miks ma peaksin reageerima põhjusel."

Oleme juba maininud peamist põhjust, miks seda teha - põhjus on Reactiga ühilduvam kui JavaScriptiga. Miks see rohkem ühildub? Sest Reakt töötati välja põhjuse jaoks või täpsemalt OCamli jaoks.

Tee ReasonReactini

Reaketi esimese prototüübi töötas välja Facebook ja see oli kirjutatud OCamli nõbu standardmeta keeles (StandardML). Seejärel viidi see OCamli. Reakt transkribeeriti ka JavaScripti.

Selle põhjuseks oli asjaolu, et kogu veeb kasutati JavaScripti ega olnud arukas öelda: “Nüüd ehitame kasutajaliidese OCamlisse.” Ja see toimis - JavaScripti reageerimine on laialt levinud.

Nii oleme harjunud reageerima JavaScripti teegina. Reageerige koos teiste raamatukogude ja keeltega - Elm, Redux, recompose, Ramda ja PureScript - JavaScripti funktsionaalne programmeerimine populaarseks. Ja koos Flow ja TypeScripti tõusuga sai populaarseks ka staatiline tippimine. Selle tulemusel muutus staatiliste tüüpidega funktsionaalne programmeerimise paradigma esiotsa maailmas.

2016. aastal arendas Bloomberg välja avatud lähtekoodiga Bucklecripti, kompilaatori, mis muudab OCamli JavaScripti. See võimaldas neil kirjutada OCamli tugeva tüübisüsteemi abil turvalisse koodi kasutajaliidesesse. Nad võtsid optimeeritud ja hämmastavalt kiire OCaml-kompilaatori ja vahetasid selle loomise loomuliku koodi JavaScripti genereerimiseks.

Funktsionaalse programmeerimise populaarsus koos Bucklecripti väljaandmisega lõi Facebooki jaoks ideaalse õhkkonna, et saada tagasi Reacti algsesse ideesse, mis kirjutati algselt ML-keeles.

ReasonReact

Nad võtsid OCamli semantika ja JavaScripti süntaksi ning lõid põhjuse. Nad lõid ka Reasoni ümbrise Reason - raamatukogu ReasonReact - koos täiendavate funktsioonidega, nagu näiteks Reduxi põhimõtete kapseldamine oleklikesse komponentidesse. Seda tehes naasid nad Reakti oma algsete juurte juurde.

Reaktsiooni jõud mõistuses

Kui React tuli JavaScripti, kohandasime JavaScripti Reacti vajadustele, tutvustades erinevaid raamatukogusid ja tööriistu. See tähendas ka meie projektidele rohkem sõltuvusi. Rääkimata sellest, et need raamatukogud on alles väljatöötamisel ja regulaarselt võetakse kasutusele murrangulisi muudatusi. Seega peate oma projektides neid sõltuvusi hoolikalt hoidma.

See lisas JavaScripti väljatöötamisele veel ühe keerukuse.

Teie tüüpilisel Reacti rakendusel on vähemalt järgmised sõltuvused:

  • staatiline masinakirjutamine - Flow / TypeScript
  • muutmatus - muutumatuJS
  • marsruutimine - ReactRouter
  • vormindamine - uhkem
  • värvimine - ESLint
  • abistaja funktsioon - Ramda / Lodash

Vahetagem nüüd JavaScripti reageerimine välja jaoks ReasonReact.

Kas me vajame endiselt kõiki neid sõltuvusi?

  • staatiline tippimine - sisseehitatud
  • muutmatus - sisseehitatud
  • marsruutimine - sisseehitatud
  • vormindamine - sisseehitatud
  • vooderdus - sisseehitatud
  • abistaja funktsioonid - sisseehitatud

Nende sisseehitatud funktsioonide kohta saate lisateavet minu muust postitusest.

Rakenduses ReasonReact ei vaja te neid ega paljusid muid sõltuvusi, kuna paljud olulised funktsioonid, mis muudavad teie arengu lihtsamaks, on juba keelesse lisatud. Seega muutub pakendite hooldamine lihtsamaks ja aja jooksul ei muutu te keerukus.

Seda tänu OCamlile, mis on enam kui 20 aastat vana. See on küps küps keel, mille kõik põhiprintsiibid on paigas ja stabiilsed.

Tõmba otsad kokku

Alguses oli Mõistuse loojatel kaks võimalust. JavaScripti võtmiseks ja kuidagi paremaks muutmiseks. Seda tehes peaksid nad hakkama saama ka selle ajaloolise koormaga.

Nad läksid siiski teist teed. Nad võtsid OCamli kui suurepärase jõudlusega küpset keelt ja muutsid seda nii, et see meenutaks JavaScripti.

Reakt põhineb ka OCamli põhimõtetel. Sellepärast saate arendajaga palju parema kogemuse, kui kasutate seda rakendusega Reason. React in Reason on turvalisem viis Reaxi komponentide ehitamiseks, kuna tugev tüüpi süsteem on teie selja taha saanud ja te ei pea enamuse JavaScripti (pärandi) probleemidega tegelema.

Mis järgmiseks?

Kui olete pärit JavaScripti maailmast, on teil sünteesi sarnasuse tõttu JavaScriptiga lihtsam alustada põhjusest. Kui olete Reaktoris programmeerinud, on see teie jaoks veelgi lihtsam, kuna saate kasutada kõiki oma Reacti teadmisi, kuna ReasonReactil on sama mentaalne mudel kui Reaktil ja väga sarnane töövoog. See tähendab, et te ei pea alustama nullist. Õpid mõistuse, kui arenete.

Parim viis mõistuse kasutamise alustamiseks oma projektides on seda teha järk-järgult. Olen juba maininud, et võite võtta põhjuse koodi ja kasutada seda JavaScriptis ning vastupidi. Sama saate teha ka rakendusega ReasonReact. Võtate oma komponendi ReasonReact ja kasutate seda oma React JavaScripti rakenduses ja vastupidi.

Selle järkjärgulise lähenemisviisi on valinud Facebooki arendajad, kes kasutavad mõistlikkust ulatuslikult Facebook Messengeri rakenduse arendamisel.

Kui soovite luua rakenduse React in Reason abil ja õppida mõistlikkuse põhitõdesid praktiliselt, lugege minu muud artiklit, kus me koos ehitame Tic Tac Toe mängu.

Kui teil on küsimusi, kriitikat, tähelepanekuid või näpunäiteid paremaks muutmiseks, kirjutage allpool kommentaar või võtke minuga ühendust Twitteri või minu ajaveebi kaudu.