Psst! Dette er grunnen til at ReasonReact er den beste måten å skrive React på

Bruker du React for å lage brukergrensesnitt? Det er jeg også. Og nå lærer du hvorfor du skal skrive React-applikasjonene dine ved å bruke ReasonML.

React er en ganske kul måte å skrive brukergrensesnitt på. Men kan vi gjøre det enda kjøligere? Bedre?

For å gjøre det bedre, må vi først identifisere problemene. Så, hva er hovedproblemet med React som et JavaScript-bibliotek?

React ble ikke opprinnelig utviklet for JavaScript

Hvis du ser nærmere på React, vil du se at noen av hovedprinsippene er fremmed for JavaScript. La oss snakke om uforanderlighet, funksjonelle programmeringsprinsipper og typesystem spesielt.

Uforanderlighet er et av grunnprinsippene i React. Du vil ikke mutere rekvisittene eller staten din, fordi hvis du gjør det, kan du oppleve uforutsigbare konsekvenser. I JavaScript har vi ikke uforanderlighet utenfor boksen. Vi holder datastrukturen uforanderlig etter en konvensjon, eller vi bruker biblioteker som immutableJS for å oppnå det.

React er basert på prinsippene for funksjonell programmering siden applikasjonene er komposisjoner av funksjoner. Selv om JavaScript har noen av disse funksjonene, for eksempel førsteklasses funksjoner, er det ikke et funksjonelt programmeringsspråk. Når vi ønsker å skrive noen fine deklarative koder, må vi bruke eksterne biblioteker som Lodash / fp eller Ramda.

Så hva er det med typesystemet? I React hadde vi PropTypes. Vi har brukt dem til å etterligne typene i JavaScript, siden det ikke er et statisk typisk språk i seg selv. For å dra nytte av avansert statisk typing, må vi igjen bruke eksterne avhengigheter, for eksempel Flow og TypeScript.

Reager og JavaScript-sammenligning

Som du kan se, er JavaScript ikke kompatibelt med Reacts grunnprinsipper.

Er det et annet programmeringsspråk som vil være mer kompatibelt med React enn JavaScript?

Heldigvis har vi ReasonML.

I Reason får vi uforanderlighet ut av boksen. Siden det er basert på OCaml, det funksjonelle programmeringsspråket, har vi slike funksjoner innebygd i selve språket. Fornuft gir oss også et sterkt type system på egen hånd.

Reager, JavaScript og årsakssammenligning

Årsaken er kompatibel med Reacts grunnprinsipper.

Årsaken

Det er ikke et nytt språk. Det er et alternativt JavaScript-lignende syntaks og verktøykjetting for OCaml, et funksjonelt programmeringsspråk som har eksistert i mer enn 20 år. Årsaken ble opprettet av Facebook-utviklere som allerede brukte OCaml i prosjektene sine (Flow, Infer).

Årsaken, med sin C-lignende syntaks, gjør OCaml tilgjengelig for folk som kommer fra vanlige språk som JavaScript eller Java. Det gir deg bedre dokumentasjon (sammenlignet med OCaml) og et voksende samfunn rundt det. I tillegg gjør det det enklere å integrere med den eksisterende JavaScript-kodebasen.

OCaml fungerer som støttespråk av grunn. Fornuft har samme semantikk som OCaml - bare syntaks er forskjellig. Dette betyr at du kan skrive OCaml ved å bruke Reason sin JavaScript-lignende syntaks. Som et resultat kan du dra nytte av OCamls fantastiske funksjoner, for eksempel dets sterke systemsystem og mønstermatching.

La oss se på et eksempel på grunnen til syntaks.

la fizzbuzz = (i) =>
  bryter (i mod 3, i mod 5) {
  | (0, 0) => "FizzBuzz"
  | (0, _) => "Fizz"
  | (_, 0) => "Buzz"
  | _ => string_of_int (i)
  };
for (i i 1 til 100) {
  Js.log (fizzbuzz (i))
};

Selv om vi bruker mønstermatching i dette eksemplet, er det fortsatt ganske likt JavaScript, ikke sant?

Imidlertid er det eneste anvendelige språket for nettlesere fremdeles JavaScript, noe som betyr at vi trenger å samle til det.

BuckleScript

En av grunnens kraftige funksjoner er BuckleScript-kompilatoren, som tar Reason-koden din, og kompilerer den til lesbar og utøvende JavaScript med stor eliminering av dødkoder. Du vil sette pris på lesbarheten hvis du jobber med et team der ikke alle er kjent med grunn, siden de fortsatt vil kunne lese den kompilerte JavaScript-koden.

Likheten med JavaScript er så nær at noen av Årsaks koder ikke trenger å endres av kompilatoren i det hele tatt. Så du kan glede deg over fordelene med det statisk skrevne språket uten å endre koden overhodet.

la legge til = (a, b) => a + b;
legg til (6, 9);

Dette er gyldig kode i både grunn og JavaScript.

BuckleScript leveres med fire biblioteker: standardbiblioteket kalt Belt (OCaml standardbibliotek er utilstrekkelig), og bindinger til JavaScript, Node.js og DOM APIer.

Siden BuckleScript er basert på OCaml-kompilator, vil du få en lynrask rask samling som er mye raskere enn Babel og flere ganger raskere enn TypeScript.

La oss sammenstille vår FizzBuzz-algoritme skrevet i grunn til JavaScript.

Årsaken til kodesammenstilling til JavaScript gjennom BuckleScript

Som du kan se, er den resulterende JavaScript-koden ganske lesbar. Det virker som om det er skrevet av en JavaScript-utvikler.

Ikke bare kompilerer Reason til JavaScript, men også til innfødt og bytecode. Så du kan skrive en enkelt applikasjon ved å bruke Reason-syntaks og kunne kjøre den i nettleseren på MacOS, Android og iOS-telefoner. Det er et spill som heter Gravitron av Jared Forsyth som er skrevet i Reason og det kan kjøres på alle plattformene jeg nettopp har nevnt.

JavaScript interop

BuckleScript gir oss også JavaScript-interoperabilitet. Ikke bare kan du lime inn den fungerende JavaScript-koden i Reason-kodebasen, men din Reason-kode kan også samhandle med den JavaScript-koden. Dette betyr at du enkelt kan integrere Årsakskode i din eksisterende JavaScript-kodebase. Dessuten kan du bruke alle JavaScript-pakkene fra NPM-økosystemet i din grunnkode. Du kan for eksempel kombinere Flow, TypeScript og Reason sammen i et enkelt prosjekt.

Imidlertid er det ikke så enkelt. For å bruke JavaScript-biblioteker eller -kode i grunn, må du først porte den til grunn via begrunnelsesbindinger. Med andre ord trenger du typer for den ikke-skrevne JavaScript-koden for å kunne dra nytte av Rases sterke type system.

Når du trenger å bruke et JavaScript-bibliotek i Reason-koden, kan du sjekke om biblioteket allerede er portet til Reason ved å bla gjennom Redex-databasen. Det er et nettsted som samler forskjellige biblioteker og verktøy skrevet i grunner og JavaScript-biblioteker med fornuftbindinger. Hvis du fant biblioteket ditt der, kan du bare installere det som en avhengighet og bruke det i din Reason-applikasjon.

Hvis du ikke fant biblioteket ditt, må du selv skrive begrunnelsesbindinger. Hvis du bare begynner med grunn, må du huske at det å skrive bindinger ikke er noe du vil begynne med, siden det er noe av det mer utfordrende i Rases økosystem.

Heldigvis skriver jeg bare et innlegg om å skrive fornuftbindinger, så følg med!

Når du trenger litt funksjonalitet fra et JavaScript-bibliotek, trenger du ikke å skrive årsaksbindingene for et bibliotek som helhet. Du kan gjøre det bare for funksjonene eller komponentene du trenger å bruke.

ReasonReact

Denne artikkelen handler om å skrive React in Reason, som du kan gjøre takket være ReasonReact-biblioteket.

Kanskje du nå tenker "Jeg vet fremdeles ikke hvorfor jeg burde bruke React med grunn."

Vi har allerede nevnt hovedgrunnen til det - grunn er mer kompatibel med React enn JavaScript. Hvorfor er den mer kompatibel? Fordi React ble utviklet av grunn, eller mer presist, for OCaml.

Veien til ReasonReact

Reacts første prototype ble utviklet av Facebook og ble skrevet på Standard Meta Language (StandardML), en fetter til OCaml. Deretter ble den flyttet til OCaml. React ble også transkribert til JavaScript.

Dette var fordi hele nettet brukte JavaScript, og det var sannsynligvis ikke smart å si: "Nå skal vi bygge UI i OCaml." Og det fungerte - React in JavaScript har blitt bredt adoptert.

Så vi ble vant til å reagere som et JavaScript-bibliotek. Reagerer sammen med andre biblioteker og språk - Elm, Redux, Compompose, Ramda og PureScript - gjort funksjonell programmering i JavaScript populær. Og med fremveksten av Flow og TypeScript ble statisk skriving også populær. Som et resultat ble det funksjonelle programmeringsparadigmet med statiske typer mainstream i frontend-verdenen.

I 2016 utviklet og utviklet Bloomberg BuckleScript, kompilatoren som transformerer OCaml til JavaScript. Dette gjorde det mulig for dem å skrive sikker kode i front-end ved hjelp av OCamls sterke type system. De tok den optimaliserte og flammende raske OCaml-kompilatoren og byttet den bakre enden som genererte innfødt kode for en JavaScript-genererende en.

Populariteten til funksjonell programmering sammen med utgivelsen av BuckleScript genererte det ideelle klimaet for Facebook for å komme tilbake til den opprinnelige ideen om React, som opprinnelig ble skrevet på et ML-språk.

ReasonReact

De tok OCaml semantikk og JavaScript-syntaks, og opprettet Reason. De opprettet også Reason-innpakningen rundt React - ReasonReact-biblioteket - med tilleggsfunksjoner som innkapsling av Redux-prinsippene i stateful komponenter. Ved å gjøre dette returnerte de React til de opprinnelige røttene.

Kraften til å reagere i grunn

Da React kom inn i JavaScript, justerte vi JavaScript til Reacts behov ved å introdusere forskjellige biblioteker og verktøy. Dette betydde også mer avhengighet for prosjektene våre. For ikke å nevne at disse bibliotekene fremdeles er under utvikling og bryteendringer blir introdusert regelmessig. Så du må opprettholde disse avhengighetene med omhu i prosjektene dine.

Dette la enda et lag med kompleksitet til JavaScript-utviklingen.

Den typiske React-applikasjonen har minst disse avhengighetene:

  • statisk skriving - Flow / TypeScript
  • uforanderlighet - uforanderligJS
  • ruting - ReactRouter
  • formatering - Prettier
  • fôring - ESLint
  • hjelperfunksjon - Ramda / Lodash

La oss nå bytte JavaScript React for ReasonReact.

Trenger vi fortsatt alle disse avhengighetene?

  • statisk skriving - innebygd
  • uforanderlighet - innebygd
  • ruting - innebygd
  • formatering - innebygd
  • fôring - innebygd
  • hjelperfunksjoner - innebygd

Du kan lære mer om disse innebygde funksjonene i det andre innlegget mitt.

I ReasonReact-applikasjonen trenger du ikke disse og mange andre avhengigheter siden mange viktige funksjoner som gjør utviklingen din enklere allerede er inkludert i selve språket. Så vedlikehold av pakkene dine blir enklere, og du har ikke en økning i kompleksitet over tid.

Dette takket være OCaml, som er mer enn 20 år gammel. Det er et modnet språk med alle sine grunnprinsipper på plass og stabilt.

Wrap-up

I begynnelsen hadde skaperne av Reason to alternativer. Å ta JavaScript og på en eller annen måte gjøre det bedre. Ved å gjøre det må de også takle dets historiske byrder.

Imidlertid gikk de en annen vei. De tok OCaml som et modnet språk med god ytelse og endret det slik at det ligner JavaScript.

React er også basert på prinsippene til OCaml. Det er derfor du får en mye bedre utvikleropplevelse når du bruker den med Reason. React in Reason representerer en tryggere måte å bygge React-komponenter på, siden systemet med sterk type har fått ryggen din og du ikke trenger å håndtere de fleste av JavaScript-problemene (arven).

Hva blir det neste?

Hvis du kommer fra JavaScript-verdenen, vil det være lettere for deg å komme i gang med Reason, på grunn av syntakslikheten med JavaScript. Hvis du har programmert i React, vil det være enda enklere for deg siden du kan bruke all React-kunnskapen din da ReasonReact har den samme mentale modellen som React og veldig lik arbeidsflyt. Dette betyr at du ikke trenger å starte helt fra bunnen av. Du lærer fornuft når du utvikler deg.

Den beste måten å begynne å bruke Reason i prosjektene dine er å gjøre det trinnvis. Jeg har allerede nevnt at du kan ta Reason-kode og bruke den i JavaScript, og omvendt. Du kan gjøre det samme med ReasonReact. Du tar din ReasonReact-komponent og bruker den i React JavaScript-applikasjonen, og omvendt.

Denne trinnvise tilnærmingen er valgt av Facebook-utviklere som bruker Reason mye i utviklingen av Facebook Messenger-appen.

Hvis du vil bygge et program ved hjelp av React in Reason og lære det grunnleggende om Reason på en praktisk måte, kan du sjekke den andre artikkelen min der vi skal bygge et Tic Tac Toe-spill sammen.

Hvis du har spørsmål, kritikk, observasjoner eller tips til forbedring, kan du gjerne skrive en kommentar nedenfor eller nå meg via Twitter eller bloggen min.