Psst! Her er hvorfor ReasonReact er den bedste måde at skrive React på

Bruger du React til at opbygge brugergrænseflader? Det er jeg også. Og nu lærer du, hvorfor du skal skrive dine React-applikationer ved hjælp af ReasonML.

React er en ret sej måde at skrive brugergrænseflader på. Men kunne vi gøre det endnu køligere? Bedre?

For at gøre det bedre skal vi først identificere dets problemer. Så hvad er hovedproblemet med React som et JavaScript-bibliotek?

React blev oprindeligt ikke udviklet til JavaScript

Hvis du ser nærmere på React, vil du se, at nogle af dets hovedprincipper er fremmed for JavaScript. Lad os især tale om uforanderlighed, funktionelle programmeringsprincipper og typesystem.

Uforanderlighed er et af de grundlæggende principper i React. Du vil ikke mutere dine rekvisitter eller din tilstand, for hvis du gør det, kan du opleve uforudsigelige konsekvenser. I JavaScript har vi ikke uforanderlighed ud af kassen. Vi holder vores datastrukturer uforanderlige efter en konvention, eller vi bruger biblioteker som immutableJS til at opnå det.

React er baseret på principperne for funktionel programmering, da dens applikationer er sammensætninger af funktioner. Selvom JavaScript har nogle af disse funktioner, såsom førsteklasses funktioner, er det ikke et funktionelt programmeringssprog. Når vi ønsker at skrive en god deklarativ kode, skal vi bruge eksterne biblioteker som Lodash / fp eller Ramda.

Så hvad sker der med typesystemet? I React havde vi PropTypes. Vi har brugt dem til at efterligne typerne i JavaScript, da det ikke selv er et statisk skrevet sprog. For at drage fordel af avanceret statisk skrivning er vi igen nødt til at bruge eksterne afhængigheder, såsom Flow og TypeScript.

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

Er der et andet programmeringssprog, der ville være mere kompatibelt med React end JavaScript?

Heldigvis har vi ReasonML.

I Reason får vi uforanderlighed ud af kassen. Da det er baseret på OCaml, det funktionelle programmeringssprog, har vi også sådanne funktioner indbygget i selve sproget. Fornuft giver os også et stærkt typesystem alene.

Fornuften er kompatibel med Reacts kerneprincipper.

Grund

Det er ikke et nyt sprog. Det er en alternativ JavaScript-lignende syntaks og værktøjskæde til OCaml, et funktionelt programmeringssprog, der har eksisteret i mere end 20 år. Årsagen blev oprettet af Facebook-udviklere, der allerede brugte OCaml i deres projekter (Flow, Infer).

Årsag med sin C-lignende syntaks gør OCaml tilgængelig for folk, der kommer fra almindelige sprog som JavaScript eller Java. Det giver dig bedre dokumentation (sammenlignet med OCaml) og et voksende samfund omkring det. Plus det gør det lettere at integrere med din eksisterende JavaScript-kodebase.

OCaml fungerer som baggrundssprog for Reason. Årsagen har samme semantik som OCaml - kun syntaksen er forskellig. Dette betyder, at du kan skrive OCaml ved hjælp af Reason's JavaScript-lignende syntaks. Som et resultat kan du drage fordel af OCamls fantastiske funktioner, såsom dens stærke typesystem og mønstermatchning.

Lad os se på et eksempel på Reason's syntaks.

let fizzbuzz = (i) => switch (i mod 3, i mod 5)  ; for (i in 1 to 100) { Js.log(fizzbuzz(i)) };

Selvom vi bruger mønstermatchning i dette eksempel, ligner det stadig JavaScript, ikke?

Imidlertid er det eneste anvendelige sprog for browsere stadig JavaScript, hvilket betyder, at vi skal kompilere til det.

Spændescript

En af Reason's kraftfulde funktioner er BuckleScript-compiler, som tager din Reason-kode og kompilerer den til læselig og performant JavaScript med stor eliminering af dead code. Du vil sætte pris på læsbarheden, hvis du arbejder i et team, hvor ikke alle er bekendt med Reason, da de stadig vil være i stand til at læse den kompilerede JavaScript-kode.

Ligheden med JavaScript er så tæt, at noget af Reason's kode slet ikke behøver at blive ændret af compileren. Så du kan nyde fordelene ved det statisk skrevne sprog uden at ændre koden overhovedet.

let add = (a, b) => a + b;add(6, 9);

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

BuckleScript leveres med fire biblioteker: standardbiblioteket kaldet Belt (OCaml-standardbiblioteket er utilstrækkeligt) og bindinger til JavaScript, Node.js og DOM API'er.

Da BuckleScript er baseret på OCaml-kompilator, får du en lynhurtig kompilering, der er meget hurtigere end Babel og flere gange hurtigere end TypeScript.

Lad os kompilere vores FizzBuzz-algoritme skrevet i Reason to JavaScript.

Som du kan se, er den resulterende JavaScript-kode ret læsbar. Det ser ud til, at det blev skrevet af en JavaScript-udvikler.

Ikke kun kompilerer Reason til JavaScript, men også til native og bytecode. Så du kan skrive en enkelt applikation ved hjælp af Reason-syntaks og være i stand til at køre den i browseren på MacOS-, Android- og iOS-telefoner. Der er et spil kaldet Gravitron af Jared Forsyth, der er skrevet i Reason, og det kan køres på alle de platforme, jeg lige har nævnt.

JavaScript interop

BuckleScript giver os også JavaScript-interoperabilitet. Ikke kun kan du indsætte din fungerende JavaScript-kode i din Reason-kodebase, men din Reason-kode kan også interagere med den JavaScript-kode. Dette betyder, at du nemt kan integrere årsagskode i din eksisterende JavaScript-kodebase. Desuden kan du bruge alle JavaScript-pakker fra NPM-økosystemet i din grundkode. For eksempel kan du kombinere Flow, TypeScript og Reason sammen i et enkelt projekt.

Det er dog ikke så simpelt. Hvis du vil bruge JavaScript-biblioteker eller kode i Reason, skal du først porte det til Reason via Reason-bindinger. Med andre ord har du brug for typer til din utypede JavaScript-kode for at kunne drage fordel af Reasons stærke typesystem.

Når du har brug for et JavaScript-bibliotek i din Årsagskode, skal du kontrollere, om biblioteket allerede blev overført til Årsag ved at gennemse databasen Reason Package Index (Redex). Det er et websted, der samler forskellige biblioteker og værktøjer, der er skrevet i Reason- og JavaScript-biblioteker med Reason-bindinger. Hvis du fandt dit bibliotek der, kan du bare installere det som en afhængighed og bruge det i din Reason-applikation.

Men hvis du ikke fandt dit bibliotek, skal du selv skrive Reason-bindinger. Hvis du lige starter med Reason, skal du huske at skrive bindinger ikke er en ting, du vil starte med, da det er en af ​​de mere udfordrende ting i Reason's økosystem.

Heldigvis skriver jeg bare et indlæg om at skrive Reason-bindinger, så hold dig opdateret!

Når du har brug for noget funktionalitet fra et JavaScript-bibliotek, behøver du ikke skrive Reason-bindingerne for et bibliotek som helhed. Du kan kun gøre det for de funktioner eller komponenter, du har brug for.

ÅrsagReager

Denne artikel handler om at skrive React in Reason, som du kan gøre takket være ReasonReact-biblioteket.

Måske tænker du nu ”Jeg ved stadig ikke, hvorfor jeg skal bruge React in Reason.”

Vi har allerede nævnt hovedårsagen til det - Reason er mere kompatibel med React end JavaScript. Hvorfor er det mere kompatibelt? Fordi React blev udviklet af Reason, eller mere præcist, for OCaml.

Vej til fornuft Reager

Reacts første prototype blev udviklet af Facebook og blev skrevet i Standard Meta Language (StandardML), en fætter til OCaml. Derefter blev det flyttet til OCaml. React blev også transkriberet til JavaScript.

Dette var fordi hele internettet brugte JavaScript, og det var sandsynligvis ikke smart at sige, "Nu bygger vi brugergrænseflade i OCaml." Og det fungerede - Reager i JavaScript er blevet bredt vedtaget.

Så vi blev vant til at reagere som et JavaScript-bibliotek. Reager sammen med andre biblioteker og sprog - Elm, Redux, Recompose, Ramda og PureScript - gjorde funktionel programmering i JavaScript populær. Og med stigningen i Flow og TypeScript blev statisk typning også populær. Som et resultat blev det funktionelle programmeringsparadigme med statiske typer mainstream i frontendens verden.

I 2016 udviklede Bloomberg og open source BuckleScript, compileren, der omdanner OCaml til JavaScript. Dette gjorde det muligt for dem at skrive sikker kode på frontend ved hjælp af OCamls stærke typesystem. De tog den optimerede og flammende hurtige OCaml-kompilator og byttede sin backend-genererende native-kode til en JavaScript-generering.

Populariteten af funktionel programmering sammen med frigivelsen af ​​BuckleScript skabte det ideelle klima for Facebook for at komme tilbage til den oprindelige idé om React, som oprindeligt blev skrevet på et ML-sprog.

De tog OCaml semantik og JavaScript syntaks og skabte Reason. De oprettede også Reason-omslaget omkring React - ReasonReact-biblioteket - med yderligere funktioner såsom indkapsling af Redux-principperne i stateful komponenter. Ved at gøre det vendte de tilbage Reager til sine oprindelige rødder.

Styrken ved at reagere med fornuft

Da React kom ind i JavaScript, tilpassede vi JavaScript til Reacts behov ved at introducere forskellige biblioteker og værktøjer. Dette betød også flere afhængigheder for vores projekter. For ikke at nævne, at disse biblioteker stadig er under udvikling, og brudende ændringer introduceres regelmæssigt. Så du er nødt til at opretholde disse afhængigheder med omhu i dine projekter.

Dette tilføjede endnu et lag af kompleksitet til JavaScript-udvikling.

Din typiske React-applikation har mindst disse afhængigheder:

  • statisk typing - Flow / TypeScript
  • uforanderlighed - uforanderligJS
  • routing - ReactRouter
  • formatering - Pænere
  • fnug - ESLint
  • hjælperfunktion - Ramda / Lodash

Lad os nu bytte JavaScript React for ReasonReact.

Har vi stadig brug for alle disse afhængigheder?

  • statisk typing - indbygget
  • uforanderlighed - indbygget
  • routing - indbygget
  • formatering - indbygget
  • fnug - indbygget
  • hjælperfunktioner - indbygget

Du kan lære mere om disse indbyggede funktioner i mit andet indlæg.

I ReasonReact-applikationen har du ikke brug for disse og mange andre afhængigheder, da mange vigtige funktioner, der gør din udvikling lettere, allerede er inkluderet i selve sproget. Så vedligeholdelse af dine pakker bliver lettere, og du har ikke en stigning i kompleksitet over tid.

Dette er takket være OCaml, som er mere end 20 år gammel. Det er et modnet sprog med alle dets kerneprincipper på plads og stabilt.

Afslutning

I starten havde skaberne af Reason to muligheder. At tage JavaScript og på en eller anden måde gøre det bedre. Ved at gøre det ville de også have brug for at håndtere dets historiske byrder.

De gik imidlertid en anden vej. De tog OCaml som et modnet sprog med stor ydeevne og ændrede det, så det ligner JavaScript.

React er også baseret på OCaml's principper. Derfor får du en meget bedre udvikleroplevelse, når du bruger den med Reason. React in Reason repræsenterer en sikrere måde at opbygge React-komponenter på, da det stærke typesystem har ryggen til dig, og du ikke behøver at håndtere de fleste af JavaScript (arv) -problemerne.

Hvad er det næste?

Hvis du kommer fra JavaScript-verdenen, bliver det lettere for dig at komme i gang med Reason på grund af dens syntakslignelighed med JavaScript. Hvis du har programmeret i React, bliver det endnu nemmere for dig, da du kan bruge al din React-viden, da ReasonReact har den samme mentale model som React og meget lignende arbejdsgang. Dette betyder, at du ikke behøver at starte fra bunden. Du lærer fornuft, når du udvikler dig.

Den bedste måde at begynde at bruge Reason på i dine projekter er at gøre det trinvist. Jeg har allerede nævnt, at du kan tage Reason-kode og bruge den i JavaScript og omvendt. Du kan gøre det samme med ReasonReact. Du tager din ReasonReact-komponent og bruger den i din React JavaScript-applikation og omvendt.

Denne inkrementelle tilgang er valgt af Facebook-udviklere, der bruger Reason i vid udstrækning i udviklingen af ​​Facebook Messenger-appen.

Hvis du vil opbygge en applikation ved hjælp af React in Reason og lære det grundlæggende i Reason på en praktisk måde, skal du tjekke min anden artikel, hvor vi sammen bygger et Tic Tac Toe-spil.

Hvis du har spørgsmål, kritik, observationer eller tip til forbedring, er du velkommen til at skrive en kommentar nedenfor eller nå mig via Twitter eller min blog.