Psst! Det är därför ReasonReact är det bästa sättet att skriva React

Använder du React för att bygga användargränssnitt? Det är jag också. Och nu lär du dig varför du ska skriva dina React-applikationer med ReasonML.

React är ett ganska coolt sätt att skriva användargränssnitt. Men kan vi göra det ännu svalare? Bättre?

För att göra det bättre måste vi först identifiera problemen. Så, vad är huvudproblemet med React som ett JavaScript-bibliotek?

React utvecklades ursprungligen inte för JavaScript

Om du tittar närmare på React ser du att några av dess huvudprinciper är främmande för JavaScript. Låt oss prata om oföränderlighet, funktionella programmeringsprinciper och typsystem särskilt.

Oändlighet är en av grundprinciperna i React. Du vill inte mutera dina rekvisita eller ditt tillstånd eftersom om du gör det kan du få oförutsägbara konsekvenser. I JavaScript har vi inte oföränderlighet utanför rutan. Vi håller våra datastrukturer oföränderliga genom en konvention, eller vi använder bibliotek som immutableJS för att uppnå det.

React är baserat på principerna för funktionell programmering eftersom dess tillämpningar är kompositioner av funktioner. Även om JavaScript har några av dessa funktioner, till exempel förstklassiga funktioner, är det inte ett funktionellt programmeringsspråk. När vi vill skriva en trevlig deklarativ kod måste vi använda externa bibliotek som Lodash / fp eller Ramda.

Så vad händer med typsystemet? I React hade vi PropTypes. Vi har använt dem för att härma typerna i JavaScript eftersom det inte är ett statiskt typiskt språk i sig. För att dra nytta av avancerad statisk typ måste vi åter använda externa beroenden, till exempel Flow och TypeScript.

React och JavaScript jämförelse

Som du ser är JavaScript inte kompatibelt med Reacts grundprinciper.

Finns det ett annat programmeringsspråk som skulle vara mer kompatibelt med React än JavaScript?

Lyckligtvis har vi ReasonML.

Med anledning får vi oföränderlighet ut ur lådan. Eftersom det är baserat på OCaml, det funktionella programmeringsspråket, har vi också sådana funktioner inbyggda i själva språket. Förnuftet ger oss också ett starkt typsystem på egen hand.

React, JavaScript och anledning jämförelse

Anledningen är kompatibel med Reacts grundprinciper.

Anledning

Det är inte ett nytt språk. Det är en alternativ JavaScript-liknande syntax och verktygskedja för OCaml, ett funktionellt programmeringsspråk som har funnits i mer än 20 år. Anledning skapades av Facebook-utvecklare som redan använde OCaml i sina projekt (Flow, Infer).

Anledning, med sin C-liknande syntax, gör OCaml tillgänglig för människor som kommer från vanliga språk som JavaScript eller Java. Det ger dig bättre dokumentation (jämfört med OCaml) och ett växande samhälle kring det. Dessutom gör det lättare att integrera med din befintliga JavaScript-kodbas.

OCaml fungerar som stödspråk för Reason. Anledning har samma semantik som OCaml - bara syntaxen är annorlunda. Detta innebär att du kan skriva OCaml med Reason's JavaScript-liknande syntax. Som ett resultat kan du dra nytta av OCamls fantastiska funktioner, som dess starka typsystem och mönstermatchning.

Låt oss ta en titt på ett exempel på Reasons syntax.

låt fizzbuzz = (i) =>
  switch (i mod 3, i mod 5) {
  | (0, 0) => "FizzBuzz"
  | (0, _) => "Fizz"
  | (_, 0) => "Buzz"
  | _ => string_of_int (i)
  };
för (i i 1 till 100) {
  Js.log (fizzbuzz (i))
};

Även om vi använder mönstermatchning i det här exemplet, är det fortfarande ganska lik JavaScript, eller hur?

Det enda användbara språket för webbläsare är fortfarande JavaScript, vilket betyder att vi måste sammanställa till det.

BuckleScript

En av anledningens kraftfulla funktioner är BuckleScript-kompilator, som tar din Reason-kod och sammanställer den till läsbar och performant JavaScript med stor eliminering av dödkoder. Du kommer att uppskatta läsbarheten om du arbetar i ett team där inte alla är bekanta med anledning, eftersom de fortfarande kommer att kunna läsa den sammanställda JavaScript-koden.

Likheten med JavaScript är så nära att en del av Resons kod inte behöver ändras av kompilatorn alls. Så du kan njuta av fördelarna med det statiskt skrivna språket utan att ändra koden överhuvudtaget.

låt lägga till = (a, b) => a + b;
tillsätt (6, 9);

Detta är giltig kod i både anledning och JavaScript.

BuckleScript levereras med fyra bibliotek: standardbiblioteket kallas Belt (OCaml standardbibliotek är otillräckligt) och bindningar till JavaScript, Node.js och DOM API: er.

Eftersom BuckleScript är baserat på OCaml-kompilator får du en snabbt snabb kompilering som är mycket snabbare än Babel och flera gånger snabbare än TypeScript.

Låt oss sammanställa vår FizzBuzz-algoritm skriven i anledning till JavaScript.

Reasons kodsammanställning till JavaScript via BuckleScript

Som ni ser är den resulterande JavaScript-koden ganska läsbar. Det verkar som om det är skriven av en JavaScript-utvecklare.

Reason kompilerar inte bara JavaScript, utan även till inbyggd kod och kod. Så du kan skriva en enda applikation med Reason-syntax och kunna köra den i webbläsaren på MacOS-, Android- och iOS-telefoner. Det finns ett spel som heter Gravitron av Jared Forsyth som är skriven i Reason och det kan köras på alla de plattformar jag just har nämnt.

JavaScript interop

BuckleScript ger oss också JavaScript-interoperabilitet. Du kan inte bara klistra in din fungerande JavaScript-kod i din Reason-kodbas, men din Reason-kod kan också interagera med den JavaScript-koden. Detta innebär att du enkelt kan integrera Reason-kod i din befintliga JavaScript-kodbas. Dessutom kan du använda alla JavaScript-paket från NPM-ekosystemet i din skälkod. Till exempel kan du kombinera Flow, TypeScript och Reason tillsammans i ett enda projekt.

Men det är inte så enkelt. Om du vill använda JavaScript-bibliotek eller kod i anledning måste du först porta den till orsaken via förnuftbindningar. Med andra ord, du behöver typer för din otypade JavaScript-kod för att kunna dra nytta av Resons starka typsystem.

När du behöver använda ett JavaScript-bibliotek i din skälkod, kontrollera om biblioteket redan har portats till skälen genom att bläddra i Redex-databasen. Det är en webbplats som samlar olika bibliotek och verktyg skrivna i Reason- och JavaScript-bibliotek med Reason-bindningar. Om du hittade ditt bibliotek där kan du bara installera det som ett beroende och använda det i din Reason-applikation.

Men om du inte hittade ditt bibliotek måste du själv skriva anledningsbindningar. Om du precis börjar med anledning, kom ihåg att skriva bindningar inte är en sak du vill börja med, eftersom det är en av de mer utmanande sakerna i resurs ekosystem.

Lyckligtvis skriver jag bara ett inlägg om att skriva förnuftbindningar, så håll dig uppdaterad!

När du behöver viss funktionalitet från ett JavaScript-bibliotek behöver du inte skriva skälbindningarna för ett bibliotek som helhet. Du kan göra det bara för de funktioner eller komponenter du behöver använda.

ReasonReact

Den här artikeln handlar om att skriva React in Reason, vilket du kan göra tack vare ReasonReact-biblioteket.

Kanske tänker du nu "Jag vet fortfarande inte varför jag ska använda React med anledning."

Vi har redan nämnt det främsta skälet till detta - Anledningen är mer kompatibel med React än JavaScript. Varför är det mer kompatibelt? Eftersom React utvecklades av anledning, eller mer exakt, för OCaml.

Vägen till ReasonReact

Reacts första prototyp utvecklades av Facebook och skrevs i Standard Meta Language (StandardML), en kusin till OCaml. Sedan flyttades den till OCaml. React transkriberades också till JavaScript.

Det berodde på att hela webben använde JavaScript, och det var förmodligen inte smart att säga, "Nu kommer vi att bygga UI i OCaml." Och det fungerade - React in JavaScript har antagits i stor utsträckning.

Så vi blev vana att reagera som ett JavaScript-bibliotek. Reagera tillsammans med andra bibliotek och språk - Elm, Redux, Omkomponera, Ramda och PureScript - gjorde funktionell programmering i JavaScript populär. Och med ökningen av Flow och TypeScript blev statisk typning också populär. Som ett resultat blev det funktionella programmeringsparadigmet med statiska typer mainstream i frontend-världen.

2016 utvecklade och öppnade Bloomberg BuckleScript, kompilatorn som omvandlar OCaml till JavaScript. Detta gjorde det möjligt för dem att skriva säker kod i front-enden med hjälp av OCamls starka typsystem. De tog den optimerade och flammande snabba OCaml-kompilatorn och bytte ut dess bakre slutgenererande ursprungskod för en JavaScript-genererande en.

Populariteten för funktionell programmering tillsammans med lanseringen av BuckleScript genererade det ideala klimatet för Facebook för att komma tillbaka till den ursprungliga idén om React, som ursprungligen skrevs på ett ML-språk.

ReasonReact

De tog OCaml semantik och JavaScript-syntax och skapade Reason. De skapade också Reason-omslaget runt React - ReasonReact-biblioteket - med ytterligare funktioner såsom inkapsling av Redux-principerna i tillräckliga komponenter. Genom att göra det återvände de React till dess ursprungliga rötter.

Kraften i React i anledning

När React kom in i JavaScript anpassade vi JavaScript till Reacts behov genom att introducera olika bibliotek och verktyg. Detta innebar också mer beroenden för våra projekt. För att inte tala om att dessa bibliotek fortfarande är under utveckling och brytande förändringar introduceras regelbundet. Så du måste behålla dessa beroenden med omsorg i dina projekt.

Detta lägger till ytterligare ett lager av komplexitet i JavaScript-utvecklingen.

Din typiska React-applikation har åtminstone dessa beroenden:

  • statisk typ - Flow / TypeScript
  • immutability - immutableJS
  • routing - ReactRouter
  • formatering - vackrare
  • foder - ESLint
  • hjälpfunktion - Ramda / Lodash

Låt oss nu byta JavaScript React för ReasonReact.

Behöver vi fortfarande alla dessa beroenden?

  • statisk maskinskrivning - inbyggd
  • immutability - inbyggd
  • routing - inbyggd
  • formatering - inbyggd
  • fodring - inbyggd
  • hjälpfunktioner - inbyggd

Du kan lära dig mer om dessa inbyggda funktioner i mitt andra inlägg.

I ReasonReact-applikationen behöver du inte dessa och många andra beroenden eftersom många avgörande funktioner som underlättar din utveckling redan finns i själva språket. Så att underhålla dina paket blir enklare och du behöver inte öka komplexiteten över tid.

Detta är tack vare OCaml, som är mer än 20 år gammal. Det är ett moget språk med alla sina grundprinciper på plats och stabila.

Sammanfatta

I början hade skaparna av Reason två alternativ. Att ta JavaScript och på något sätt göra det bättre. Genom att göra det måste de också ta itu med dess historiska bördor.

Men de gick en annan väg. De tog OCaml som ett moget språk med bra prestanda och modifierade det så det liknar JavaScript.

React är också baserat på OCamls principer. Det är därför du får en mycket bättre utvecklarupplevelse när du använder den med Reason. React in Reason representerar ett säkrare sätt att bygga React-komponenter, eftersom systemet med stark typ har fått din rygg och du inte behöver ta itu med de flesta JavaScript-problem (äldre).

Vad kommer härnäst?

Om du kommer från JavaScript-världen blir det lättare för dig att komma igång med Reason på grund av dess syntaxlikhet med JavaScript. Om du har programmerat i React kommer det att bli ännu enklare för dig eftersom du kan använda all din React-kunskap eftersom ReasonReact har samma mentala modell som React och mycket liknande arbetsflöde. Det betyder att du inte behöver börja från början. Du lär dig förnuft när du utvecklas.

Det bästa sättet att börja använda Reason i dina projekt är att göra det stegvis. Jag har redan nämnt att du kan ta anledningskod och använda den i JavaScript, och tvärtom. Du kan göra samma sak med ReasonReact. Du tar din ReasonReact-komponent och använder den i din React JavaScript-applikation, och vice versa.

Denna stegvisa strategi har valts av Facebook-utvecklare som använder Reason i stor utsträckning i utvecklingen av Facebook Messenger-appen.

Om du vill bygga en applikation med React in Reason och lära dig grunderna i Reason på ett praktiskt sätt, kolla min andra artikel där vi ska bygga ett Tic Tac Toe-spel tillsammans.

Om du har några frågor, kritik, iakttagelser eller tips för förbättring kan du skriva en kommentar nedan eller nå mig via Twitter eller min blogg.