Psst! Her er grunden til, at ReasonReact er den bedste måde at skrive React på

Bruger du React til at oprette 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 temmelig cool 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 det største problem med React som et JavaScript-bibliotek?

React blev oprindeligt ikke udviklet til JavaScript

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

Uforanderlighed er et af kerneprincipperne i React. Du ønsker ikke at mutere dine rekvisitter eller din tilstand, fordi hvis du gør det, kan du opleve uforudsigelige konsekvenser. I JavaScript har vi ikke uforanderlighed ude af boksen. Vi holder vores datastrukturer uforanderlige ved en konvention, eller vi bruger biblioteker som immutableJS for 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 dejlig deklarativ kode, er vi nødt til at bruge eksterne biblioteker som Lodash / fp eller Ramda.

Så hvad sker der med typesystemet? Som reaktion havde vi PropTypes. Vi har brugt dem til at efterligne typerne i JavaScript, da det ikke er et statisk typisk sprog i sig selv. For at drage fordel af avanceret statisk typning skal vi igen bruge eksterne afhængigheder, såsom Flow og TypeScript.

Reaktion og JavaScript-sammenligning

Som du kan se, er JavaScript ikke kompatibel med Reacts grundprincipper.

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

Heldigvis har vi ReasonML.

Årsag 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 på egen hånd.

Reaktion, JavaScript og årsagssammenligning

Årsagen er kompatibel med Reacts grundlæggende principper.

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 mainstream-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 backing-sprog af grunden. Årsag har den samme semantik som OCaml - kun syntaks er anderledes. Dette betyder, at du kan skrive OCaml vha. Årsags JavaScript-lignende syntaks. Som et resultat kan du drage fordel af OCamls fantastiske funktioner, såsom dets stærke typesystem og mønster matching.

Lad os se på et eksempel på Årsags syntaks.

lad fizzbuzz = (i) =>
  switch (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))
};

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

Det eneste brugbare sprog til browsere er dog stadig JavaScript, hvilket betyder, at vi er nødt til at samle til det.

BuckleScript

En af Ræsons kraftfulde funktioner er BuckleScript-kompilator, der tager din Reason-kode og kompilerer den til læsbar og udøvende JavaScript med stor eliminering af dead code. Du vil sætte pris på læsbarheden, hvis du arbejder på et team, hvor ikke alle er bekendt med grunden, da de stadig vil være i stand til at læse den kompilerede JavaScript-kode.

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

lad tilføj = (a, b) => a + b;
tilføj (6, 9);

Dette er gyldig kode i både Årsag og JavaScript.

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

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

Lad os udarbejde vores FizzBuzz-algoritme skrevet i grund til JavaScript.

Årsagens kodekompilering til JavaScript gennem BuckleScript

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

Årsagen kompileres ikke kun til JavaScript, men også til indbygget og bytecode. Så du kan skrive et enkelt program ved hjælp af Reason-syntaks og være i stand til at køre det i browseren på MacOS, Android og iOS-telefoner. Der er et spil kaldet Gravitron af Jared Forsyth, som 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 Reason-kode. For eksempel kan du kombinere Flow, TypeScript og Reason sammen i et enkelt projekt.

Det er dog ikke så enkelt. Hvis du vil bruge JavaScript-biblioteker eller kode i Årsagen, skal du først porte den til Årsag via bindingsårsager. Med andre ord har du brug for typer til din ikke-indtastede JavaScript-kode for at kunne drage fordel af Reasons stærke typen system.

Hver gang du har brug for at bruge et JavaScript-bibliotek i din Reason-kode, skal du kontrollere, om biblioteket allerede var portet til Reason ved at gennemse databasen Reason Package Index (Redex). Det er et websted, der aggregerer forskellige biblioteker og værktøjer, der er skrevet i grunde og JavaScript-biblioteker med årsagsbindinger. Hvis du fandt dit bibliotek der, kan du bare installere det som en afhængighed og bruge det i din Reason-applikation.

Hvis du ikke fandt dit bibliotek, skal du selv skrive årsagsbindinger. Hvis du lige starter med Reason, skal du huske, at skrivning af bindinger ikke er en ting, du vil starte med, da det er en af ​​de mere udfordrende ting i Reasons økosystem.

Heldigvis skriver jeg bare et indlæg om at skrive bindende årsager, så hold dig tunet!

Når du har brug for noget funktionalitet fra et JavaScript-bibliotek, behøver du ikke at skrive årsagsbindingerne til et bibliotek som helhed. Det kan du kun gøre for de funktioner eller komponenter, du har brug for.

ReasonReact

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 af grund."

Vi har allerede nævnt den vigtigste grund til at gøre det - Årsagen er mere kompatibel med React end JavaScript. Hvorfor er det mere kompatibelt? Fordi React blev udviklet af grund eller mere præcist for OCaml.

Vejen til ReasonReact

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

Dette skyldtes, at hele nettet brugte JavaScript, og det var sandsynligvis ikke smart at sige, ”Nu skal vi bygge UI i OCaml.” Og det virkede - React in JavaScript er blevet bredt anvendt.

Så vi blev vant til at reagere som et JavaScript-bibliotek. Reager sammen med andre biblioteker og sprog - Elm, Redux, Compompose, Ramda og PureScript - gjort funktionel programmering i JavaScript populær. Og med fremkomsten af ​​Flow og TypeScript blev statisk skrivning også populær. Som et resultat blev det funktionelle programmeringsparadigme med statiske typer mainstream i frontend-verdenen.

I 2016 udviklede og udviklede Bloomberg BuckleScript, den kompilator, der omdanner OCaml til JavaScript. Dette gjorde dem i stand til at skrive sikker kode i front-end ved hjælp af OCamls stærke type system. De tog den optimerede og flammende hurtige OCaml-kompilator og byttede den bageste ende, der genererede native code, til en JavaScript-genererende en.

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

ReasonReact

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

Kraften ved at reagere med grund

Da React kom i JavaScript, justerede vi JavaScript til React's 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 bevare disse afhængigheder med omhu i dine projekter.

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

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

  • statisk indtastning - Flow / TypeScript
  • uforanderlighed - uforanderligJS
  • routing - ReactRouter
  • formatering - Prettier
  • fnug - ESLint
  • hjælperfunktion - Ramda / Lodash

Lad os nu bytte JavaScript React af ReasonReact.

Har vi stadig brug for alle disse afhængigheder?

  • statisk indtastning - 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 behøver du ikke 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, der er mere end 20 år gammel. Det er et modent sprog med alle dets grundlæggende principper på plads og stabilt.

Wrap-up

I begyndelsen 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 er de også nødt til at håndtere dens historiske byrder.

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

Reaktion er også baseret på principperne fra OCaml. 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 type system har fået din ryg, og du ikke behøver at tackle de fleste af JavaScript-problemer (ældre).

Hvad er det næste?

Hvis du kommer fra JavaScript-verdenen, er det lettere for dig at komme i gang med Reason på grund af dens syntakslighed med JavaScript. Hvis du har programmeret i React, vil det være endnu lettere 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 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 vice versa.

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

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

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