<ForrigeUke uke="4" år="2026" />
Dette var uka for enda flere nye nettleser-API-er — og et veiskille i bygging av React-komponenter.
Dette var uka for tverrfaglighet og bokstavelige datamaskiner — og 1047 ting som skjedde i frontendverdenen!
«<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var.»
Firefox-versjon 147
Året starter med noen nye nettleser-versjoner, og i forrige uke kunne Joachim melde om Temporal-API i Chrome. Også denne uka er nettleser-oppdatering i nyhetene, for denne gang har Firefox kommet til versjon 147.
Denne oppdateringen er ekstra interessante for oss React-utviklere:
Med innslag av View transition types også i Firefox, er det mange moderne nettlesere som støtter React-komponenten ViewTransition, når komponenten til slutt er klar for lansering. Spesifikt gjør view transition types det mulig å spesifisere hvilken animasjon du skal ha ved endringer i DOM-en. Det vil for eksempel la oss animere at elementer kommer inn fra siden eller fader unna.
CSS Anchor Positioning API gjør det enda enklere å lage komponenter som menyer og tooltips. Istedenfor å prøve å beregne hvor anker-elementet er og det tilknyttede elementet, kan vi posisjonere elementet i forhold til ankeret.
Det kan se slik ut, hvor vi har en knapp, så ønsker vi å vise innhold over:
.anchor-button {
/* 👇 Gir ankeret et navn */
anchor-name: --anchor-el;
}
.positioned-notice {
position: absolute;
/* 👇 Refererer til ankeret */
position-anchor: --anchor-el;
/* 👇 Bunnen av elementet er over ankeret */
bottom: anchor(top);
/* 👇 Sentralt plassert over ankeret */
justify-self: anchor-center;
}
Med inntoget av Navigation API kan vi enklere gjøre operasjoner ved navigering. For gamle history API var navigasjon bare et URL-bytte, så for å kansellere arbeid eller unngå race conditions, var en løsning å holde styr på request-ider. Navigation API introduserer en sentral navigate-hendelse som trigges idet navigering skjer. Dette kan vi lytte på, som gjør det enklere å reagere på navigeringer eller utføre spesifikk logikk for bestemte URL-stier.
shadcn lar deg velge mellom Radix og Base UI
Nå lar designbiblioteket shadcn oss velge mellom Radix- eller Base UI-komponenter ved initialisering i et nytt prosjekt. Dette viser at Base UI har fått mer fotfeste etter Radix-kontroversen. Base UI kom ut i versjon 1.0 rett før årsskifte, og med versjon 1.1 som kom ut midt i januar, fortsetter de å forbedre komponentene.

Så skal du velge Radix eller Base UI ved initiering av shadcn?
For de fleste prosjekter vil valget mellom Radix og Base UI i shadcn ha liten praktisk betydning. Komponentene importeres fra samme sti og deler i stor grad samme API.
En interessant forskjell på bibliotekene er hvordan de håndterer polymorfisme, altså at en komponent kan opptre som en annen, som at en lenke skal styles som en knapp.
Radix UI gir deg asChild- API-et, som under panseret kloner elementet. Det er også noen underliggende regler for om forelder- eller under-komponenten sine props skal ha forrang:
// Radix UI
import { Slot } from 'radix-ui';
function Button({ asChild, ...props }) {
const Comp = asChild ? Slot.Root : 'button';
return <Comp {...props} />;
}
// Bruk:
<Button asChild>
<a href="/contact">Contact</a>
</Button>Base UI har mer eksplisitt håndtering med en rendringfunksjon, hvor du må skrive hvordan potensielle props-kræsj skal håndteres:
// Base UI
import { useRender } from '@base-ui/react/use-render';
function Button({ render, ...props }) {
return useRender({
defaultTagName: 'button',
render,
props,
});
}
// Bruk:
<Button render={<a href="/contact" />}>Contact</Button>Om du er nysgjerrig på flere detaljer om hva som egentlig foregår, har utvikleren boda.sh skrevet en lengre guide.
Begge tilnærminger er gode, og det er verdt å nevne at Radix og Base UI er lagd av samme folka. Likevel peker forfatteren av artikkelen også på hva Base UI indikerer: React-miljøet er på vei mot mer eksplisitte, hook-baserte API-er fremfor komponenter som gjemmer bort implementasjonsdetaljer.
Det var alt for denne gang. Ha en riktig fin uke! 👋
