Frond flyttar beroendehanteringen ut ur React-komponenterna

Frond är en ny frontend-runtime som modellerar din app som en graf av beroenden istället för att låta React-komponenter sköta både tillstånd och rendering. Runtimet löser upp beroendena i rätt ordning, håller reda på vad som är klart och lämnar över en färdig nod till React först när den faktiskt går att rendera. Projektet är i version 0, vilket betyder att API:et fortfarande kan ändras. Diskussionen kring projektet uppmärksammades bland annat på Hacker News, där utvecklare redan diskuterar hur idén skiljer sig från traditionell state-hantering.

Enkelt uttryckt: React ska bara rita gränssnittet. Frond tar hand om resten.

React blir en renderer, inte en tillståndsmaskin

Det vanliga problemet i större React-appar är att komponenterna dras med för mycket ansvar. En komponent ska hämta data, hantera laddningstillstånd, avbryta ett anrop om användaren navigerar bort, städa upp prenumerationer och sedan rendera resultatet. Logiken hamnar inuti komponenten, ofta utspridd över flera `useEffect`-anrop och blir svår att följa när appen växer.

Frond vänder på det. Du beskriver appens tjänster, resurser och skärmar som noder i en graf. Varje nod deklarerar på ett och samma ställe vad den beror på, hur den hämtas, hur den avbryts och hur den frigörs. Runtimet läser grafen, löser beroendena i beroendeordning och spårar när varje nod är redo.

När en komponent behöver en nod anropar den `useNode`. I stället för att komponenten själv reder ut om datan finns, väntar `useNode` tills noden är klar. React får alltså aldrig se en halvfärdig nod. Det liknar tänket bakom Immutable.js där state blir förutsägbart, fast här handlar det om ordningen saker blir klara i, inte om datan i sig.

Effect och MobX är de två motorerna under huven

Frond bygger inte sin egen kärna från grunden. I stället kombinerar det två etablerade JavaScript-bibliotek, vart och ett med en tydlig uppgift.

Effect är den del som gör de svåra sakerna kring asynkronitet: att ett anrop verkligen avbryts när det ska, att resurser frigörs och att fel hamnar i en typad kanal i stället för att spridas som otypade undantag.

MobX står för det reaktiva, alltså att ett gränssnitt uppdateras automatiskt när ett värde en nod observerar ändras. Valet är rimligt, eftersom båda biblioteken är testade i skarp produktion sedan flera år. Det Frond tillför är limmet mellan dem och grafmodellen som binder ihop det till en runtime.

Idén är gammal, förpackningen är ny

Att separera beroendeupplösning från rendering är inget Frond hittade på. Dependency injection har funnits i backend-ramverk i decennier och tanken att beskriva ett system som en graf av noder känns igen från byggverktyg och paketregister. Där handlar det ofta om beroenden mellan paket, här om beroenden mellan delar av en körande app.

Det nya är att flytta in det i frontend-lagret och binda det så nära React. Frond konkurrerar inte direkt med en state-hanterare som Redux eller Zustand. Det ligger snarare ett steg utanför och bestämmer i vilken ordning saker överhuvudtaget blir tillgängliga för renderingen.

Ett v0-API är inte stabilt

Frond presenterades i utvecklarkretsar som ett tidigt projekt och versionsnumret säger vad du behöver veta. Funktioner kan byta namn, signaturer kan ändras och hela koncept kan skrivas om mellan versioner.

För en produktionsapp med deadline är det ett tydligt varningstecken. För den som vill förstå hur nästa generations frontend-arkitektur kan se ut är det däremot en bra tidpunkt att titta, eftersom idéerna oftast är som mest lärorika innan de slipats ner till en färdig produkt.

FAQ

Ersätter Frond React?

Nej. Frond ersätter inte React utan använder det som renderer. React fortsätter rita gränssnittet, medan Frond tar över ansvaret för att lösa beroenden och hålla reda på vad som är klart att visa.

Behöver jag kunna Effect och MobX för att använda Frond?

Inte nödvändigtvis för att komma igång, eftersom Frond kapslar in dem bakom sitt eget API. Men om du vill förstå varför avbrytning, felhantering och liveuppdateringar beter sig som de gör hjälper det att känna till vad de två biblioteken gör var för sig. Effect sköter det asynkrona, MobX det reaktiva.

Är Frond redo att användas i skarpa projekt?

Nej, inte ännu. Projektet är i version 0 och API:et är inte stabiliserat, vilket betyder att kod du skriver idag kan sluta fungera i en kommande version. Det passar bättre för experiment och lärande än för en app som ska driftas långsiktigt.

Vill du dyka djupare i hur AI-genererad frontend ofta hamnar i just de spretiga komponenter Frond försöker undvika, finns en genomgång av hur du minskar generisk AI-kod i din frontend att läsa vidare i.