Bygg komponenter, ikke maler

La oss tenke nytt. Mye av det jeg kommer til å si her er ting som kommer til å utfordre måten du lager webapplikasjoner.

React er et rammeverk. I en MVC-modell kan React sees på som V, visningsmodellen. Den kombinerer generering av DOM og visningslogikken. Den gjør det ved å rendre appen på nytt for hver oppdatering. Den introduserer virtuell DOM og syntetiske hendelser.

Bygg komponenter, ikke maler. I praksis: miks markup med display-logikk. Bygg gjenbrukbare komponenter.

Er dette et steg tilbake? Hva med separation of concerns? Det har vært det sentrale temaet i webdesign de siste femten årene. Klassisk problem: putte mysql-select i visningsfilen til PHP.

Ta et steg tilbake. Hva betyr separation of concerns.

Redusere bindinger. I hvilken grad hver programmodul lener seg på de andre. Når du fikser en bug, eller legger til en funksjon i en modul, i hvilken grad må du endre andre moduler for at det skal virke. Dess flere som må endres, desto større er bindingene. Det øker kompleksiteten.

Øke kohesjon. I hvilken grad elementene i en modul hører sammen. Single responsibility. Litmus-testen: virker denne klassen fornuftig? Kan den refaktoreres til separate funksjoner?

Maler oppfordrer til å bryte med det prinsippet. View models har som regel en tett binding mellom malen og visningslogikken. Maler separerer teknologier, ikke virkeområder. De leveres i malsystemer som med vilje kan gjøre så lite som mulig. De er impotente, og det er gjort med vilje. De finner opp primitive abstraksjoner for ting som allerede finnes i JavaScript: undersider, databinding, løkker.

Rammeverket skal ikke bestemme hvordan du separerer logikken din. Applikasjonen skal det. Rammeverket skal gi deg kraftige, ekspressive verktøy og overlate resten.

React er et slikt verktøy. En kohesiv byggekloss for UI, løst koblet til andre komponenter. Du bygger en komponent én gang. Kompleksiteten er lineær. Appen din er bare så kompleks som din mest komplekse komponent. Komponenter kan enhetstestes. De er, tross alt, enheter. Du trenger ikke et stort dependency injection-rammeverk. Med mindre du liker sånt.

Kan dette føre til spagetti? Ja. Løsningen er enkel. Ikke skriv spagetti-kode. Vi vet hvordan vi skriver små komponenter i backend. Hvorfor ikke det samme foran. Tips: legg bare visningslogikk i komponentene. With great power comes great responsibility. Forslitt, og likevel.

Hva med XSS? Alltid en bekymring. Bruk den innebygde metoden:

React.DOM.a({href: 'http://inmeta.no'}, 'Et passe stort konsultasjonsselskap i Norge');

Hva med designere? Svaret er JSX. Syntaks som minner om HTML, oversatt til JavaScript React kan kjøre. Det er alt den gjør. Den enkle tilnærmingen fra malsystemene, med kraften fra språket.

Det er vanskelig å bygge brukergrensesnitt fordi det er så mange tilstander. En mengde UI-elementer. Designere som endrer mening. Helsprø miljøer. Et DOM i konstant endring. Bruker-input. Dataendring over tid er roten til alt ondt.

På 90-tallet lastet du siden på nytt når dataene endret seg. React gjør det på samme måte. Komponenter er i bunnen idempotente funksjoner. De beskriver tilstanden til grensesnittet på et gitt tidspunkt, som en serverrendret app. Hver gang data presenteres er det garantert oppdatert. Ingen magisk databinding. Ingen dirty checking. Ingen eksplisitte DOM-operasjoner. Alt er deklarativt.

Rendre DOM for hver endring? Kostbart, og du mister skjemafelter og skroll. Derfor virtuell DOM. React bygger et nytt subtre, differ mot det forrige, beregner det minste settet mutasjoner, kjører køen. Hendelsessystemet er reimplementert. Du kan overstyre oppdateringen om du må. Når du først har et virtuelt DOM er du ikke lenger bundet til nettleseren.

Det siste punktet er det som ble igjen. Et tre av komponenter, setState, render på nytt. Ikke Facebook. Ikke JSX om du ikke vil. Bare den modellen. Noen år senere heter runtime SvenJS, og den viser disse tekstene.