![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*79xB5xyUPER8uNMKRpHXUw.png\")
Radio-knapper krever overraskende mye kode. Det ble ekstra tydelig da jeg jobbet med radio-komponenten i Gnist \u2728, designsystemet v\u00e5rt hos M\u00f8ller. Gleden var stor da jeg snublet over et m\u00f8nster som gjorde hele greia dramatisk enklere. Jeg kan avsl\u00f8re at l\u00f8sningen var React Context, men brukt p\u00e5 en m\u00e5te jeg egentlig har oversett.
\nDet hele startet med f\u00f8lgende kodesnutt:
\n<RadioGroup label=\"Hvilken type tjeneste vil du bestille?\">\n
<RadioButton
label=\"EU-kontroll\"
value=\"eu\"
checked={currentService === \"eu\"}
onChange={handleChange}
name=\"service\"
/>
<RadioButton
label=\"Bytte vindusvisker\"
value=\"wiper\"
checked={currentService === \"wiper\"}
onChange={handleChange}
name=\"service\"
/>
<RadioButton
label=\"Hjulskift\"
value=\"wheels\"
checked={currentService === \"wheels\"}
onChange={handleChange}
name=\"service\"
/>
</RadioGroup>
Ganske mye gjentagelse, ikke\u00a0sant?
\n\u00c5rsaken er at input-felt av typen radio trenger en del\u00a0verdier:
\nVi kan jo se at det er to ting som gjentar seg her som har samme verdier: onChange og name. Hva om vi kunne ha definerert dem p\u00e5 ett\u00a0sted?
\nN\u00e5r jeg utvikler en ny komponent i designsystemet, titter jeg ofte p\u00e5 andre designsystemer (som ogs\u00e5 er et hot tips, ettersom du b\u00f8r f\u00f8lge etablerte m\u00f8nstre). Jeg skal innr\u00f8mme at jeg ofte henter inspirasjon fra Aksel, NAVs designsystem. De har god dokumentasjon og f\u00f8lger gode praksiser til komponenter\u200a\u2014\u200asom gir mening og st\u00f8tter universell utforming.
\nDer fant jeg f\u00f8lgende representasjon (dog byttet litt med mine egne komponenter):
\n<RadioGroup\n
label=\"Hvilken type tjeneste vil du bestille?\"
// \ud83d\udc47 onChange og name ligger n\u00e5 i RadioGroup
onChange={handleChange}
name=\"service\"
// \ud83d\udc47 value i Group holder rede p\u00e5 n\u00e5v\u00e6rende verdi
value={currentService}
>
<RadioButton
label=\"EU-kontroll\"
value=\"eu\"
/>
<RadioButton
label=\"Bytte vindusvisker\"
value=\"wiper\"
/>
<RadioButton
label=\"Hjulskift\"
value=\"wheels\"
/>
</RadioGroup>
Wow. Vakkert.
\nMed ett sted \u00e5 definere name, kan jeg plutselig slippe irriterende bugs som at den ene inputen ikke fungerer. Ogs\u00e5 nyter jeg jo alltid \u00e5 ha mindre kode \u00e5 skrive, og mindre kode \u00e5 lese\u200a\u2014\u200asom jo er en bonus n\u00e5r du utvikler en komponent til et komponentbibliotek, som mange skal bruke. S\u00e5 hvordan f\u00e5 til denne forenklingen?
\nVi vet at RadioButton alltid kommer til \u00e5 brukes sammen med RadioGroup. Hvordan kan vi gi RadioButton props fra sin parent, uten at de er videresendt direkte?
\nEtter \u00e5 ha smygtittet inn i Aksels kildekode, oppdaga jeg at forenklingen er oppn\u00e5dd med en React Context (senere har jeg oppdaga at ogs\u00e5 material UI har lignende implementasjon).
\nLikt som at vi kan pakke inn hele appen i en darkmode- kontekst for \u00e5 tilgjengeliggj\u00f8re en verdi, kan vi ogs\u00e5 pakke inn mindre deler eller enkeltkomponenter. En fun fact er at Facebook har 140 lag med kontekster.
\nVi kan bruke React Context ved \u00e5 ta fellesvariablene vi f\u00e5r fra RadioGroup og mate de inn i en kontekst. Konteksten pakkes rundt children, alts\u00e5 der vi forventer RadioButtons:
\nexport function RadioGroup({
label,
children,
name,
value,
onChange,
...props
}: RadioGroupProps) {
return (
<fieldset {...props}>
<legend>{label}</legend>
{/* \ud83d\udc47 Context tilgjengeliggj\u00f8r verdier til children */}
<RadioGroupContext
{/*
\ud83d\udc47 Sender verdier satt i RadioGroup
ned til RadioButtons via Context
*/}
value={{
name: name,
value: value,
onChange: onChange,
}}
>
{children}
</RadioGroupContext>
</fieldset>
);
}\nOg s\u00e5 konsumerer vi konteksten med use(), s\u00e5 vi f\u00e5r verdiene fra RadioButton. Til dette kan vi lage en hook som gj\u00f8r det litt lettere \u00e5 hente\u00a0verdier:
\nconst RadioGroupContext =\n
createContext<RadioGroupContextProps | null>(null);
// \ud83d\udc47 Konsumerer konteksten og returnerer verdiene
export function useRadio() {
const context = use(RadioGroupContext);
if (!context) {
throw new Error(
\"RadioButton must be used within a RadioGroup component\",
);
}
return context;
}
S\u00e5 tar vi i bruk verdiene i RadioButton:
\nexport function RadioButton({ label, value, ...props }: Props) {
// \ud83d\udc47 Henter verdiene fra context
const { onChange, name, value: currentValue } = useRadio();
/*
\ud83d\udc47 Impliserer om checked skal bli satt utifra
verdi fra parent og fra RadioButton
*/
const isChecked = currentValue === value;
return (
<label>
{label}
<input
type=\"radio\"
name={name}
onChange={(e) => onChange(e.target.value)}
value={value}
checked={isChecked}
{...props}
/>
</label>
);
}\nN\u00e5 kan vi slippe \u00e5 eksplisitt sette onChange, name og checked p\u00e5 RadioButton. De blir heller sendt ned fra konteksten (og checked blir implisert basert p\u00e5 n\u00e5v\u00e6rende verdi).
\nDette m\u00f8nsteret kalles \u201ccompound components\u201d (takk for innspill, Aurora Scharff \ud83d\udca1). Compound components inneb\u00e6rer ikke n\u00f8dvendigvis at React Context er brukt, men er n\u00e5r komponenter er beregnet \u00e5 bli brukt sammen\u200a\u2014\u200asom her at RadioGroup holder rede p\u00e5 tilstand for RadioItem. Ofte ser du compound components n\u00e5r komponenter eksporterer en hovedkomponent Card, og du kan bygge opp komponenten med Card.Header, Card.Body og Card.Footer.
\nReact Context trenger alts\u00e5 ikke \u00e5 v\u00e6re kun for de store, globale tingene, men ogs\u00e5 for sm\u00e5 komponenter der vi vet parent og child kommer til \u00e5 brukes sammen. I dette tilfellet ga det et renere API, f\u00e6rre muligheter for feil og, kanskje viktigst, en komponent som er lettere \u00e5\u00a0bruke.
\nGj\u00f8r komponentene dine enklere med React Context was originally published in M\u00f8ller Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nRadio-knapper krever overraskende mye kode. Det ble ekstra tydelig da jeg jobbet med radio-komponenten i Gnist \u2728, designsystemet v\u00e5rt hos M\u00f8ller. Gleden var stor da jeg snublet over et m\u00f8nster som gjorde hele greia dramatisk enklere. Jeg kan avsl\u00f8re at l\u00f8sningen var React Context, men brukt p\u00e5 en m\u00e5te jeg egentlig har oversett.
\nDet hele startet med f\u00f8lgende kodesnutt:
\n<RadioGroup label=\"Hvilken type tjeneste vil du bestille?\">\n
<RadioButton
label=\"EU-kontroll\"
value=\"eu\"
checked={currentService === \"eu\"}
onChange={handleChange}
name=\"service\"
/>
<RadioButton
label=\"Bytte vindusvisker\"
value=\"wiper\"
checked={currentService === \"wiper\"}
onChange={handleChange}
name=\"service\"
/>
<RadioButton
label=\"Hjulskift\"
value=\"wheels\"
checked={currentService === \"wheels\"}
onChange={handleChange}
name=\"service\"
/>
</RadioGroup>
Ganske mye gjentagelse, ikke\u00a0sant?
\n\u00c5rsaken er at input-felt av typen radio trenger en del\u00a0verdier:
\nVi kan jo se at det er to ting som gjentar seg her som har samme verdier: onChange og name. Hva om vi kunne ha definerert dem p\u00e5 ett\u00a0sted?
\nN\u00e5r jeg utvikler en ny komponent i designsystemet, titter jeg ofte p\u00e5 andre designsystemer (som ogs\u00e5 er et hot tips, ettersom du b\u00f8r f\u00f8lge etablerte m\u00f8nstre). Jeg skal innr\u00f8mme at jeg ofte henter inspirasjon fra Aksel, NAVs designsystem. De har god dokumentasjon og f\u00f8lger gode praksiser til komponenter\u200a\u2014\u200asom gir mening og st\u00f8tter universell utforming.
\nDer fant jeg f\u00f8lgende representasjon (dog byttet litt med mine egne komponenter):
\n<RadioGroup\n
label=\"Hvilken type tjeneste vil du bestille?\"
// \ud83d\udc47 onChange og name ligger n\u00e5 i RadioGroup
onChange={handleChange}
name=\"service\"
// \ud83d\udc47 value i Group holder rede p\u00e5 n\u00e5v\u00e6rende verdi
value={currentService}
>
<RadioButton
label=\"EU-kontroll\"
value=\"eu\"
/>
<RadioButton
label=\"Bytte vindusvisker\"
value=\"wiper\"
/>
<RadioButton
label=\"Hjulskift\"
value=\"wheels\"
/>
</RadioGroup>
Wow. Vakkert.
\nMed ett sted \u00e5 definere name, kan jeg plutselig slippe irriterende bugs som at den ene inputen ikke fungerer. Ogs\u00e5 nyter jeg jo alltid \u00e5 ha mindre kode \u00e5 skrive, og mindre kode \u00e5 lese\u200a\u2014\u200asom jo er en bonus n\u00e5r du utvikler en komponent til et komponentbibliotek, som mange skal bruke. S\u00e5 hvordan f\u00e5 til denne forenklingen?
\nVi vet at RadioButton alltid kommer til \u00e5 brukes sammen med RadioGroup. Hvordan kan vi gi RadioButton props fra sin parent, uten at de er videresendt direkte?
\nEtter \u00e5 ha smygtittet inn i Aksels kildekode, oppdaga jeg at forenklingen er oppn\u00e5dd med en React Context (senere har jeg oppdaga at ogs\u00e5 material UI har lignende implementasjon).
\nLikt som at vi kan pakke inn hele appen i en darkmode- kontekst for \u00e5 tilgjengeliggj\u00f8re en verdi, kan vi ogs\u00e5 pakke inn mindre deler eller enkeltkomponenter. En fun fact er at Facebook har 140 lag med kontekster.
\nVi kan bruke React Context ved \u00e5 ta fellesvariablene vi f\u00e5r fra RadioGroup og mate de inn i en kontekst. Konteksten pakkes rundt children, alts\u00e5 der vi forventer RadioButtons:
\nexport function RadioGroup({
label,
children,
name,
value,
onChange,
...props
}: RadioGroupProps) {
return (
<fieldset {...props}>
<legend>{label}</legend>
{/* \ud83d\udc47 Context tilgjengeliggj\u00f8r verdier til children */}
<RadioGroupContext
{/*
\ud83d\udc47 Sender verdier satt i RadioGroup
ned til RadioButtons via Context
*/}
value={{
name: name,
value: value,
onChange: onChange,
}}
>
{children}
</RadioGroupContext>
</fieldset>
);
}\nOg s\u00e5 konsumerer vi konteksten med use(), s\u00e5 vi f\u00e5r verdiene fra RadioButton. Til dette kan vi lage en hook som gj\u00f8r det litt lettere \u00e5 hente\u00a0verdier:
\nconst RadioGroupContext =\n
createContext<RadioGroupContextProps | null>(null);
// \ud83d\udc47 Konsumerer konteksten og returnerer verdiene
export function useRadio() {
const context = use(RadioGroupContext);
if (!context) {
throw new Error(
\"RadioButton must be used within a RadioGroup component\",
);
}
return context;
}
S\u00e5 tar vi i bruk verdiene i RadioButton:
\nexport function RadioButton({ label, value, ...props }: Props) {
// \ud83d\udc47 Henter verdiene fra context
const { onChange, name, value: currentValue } = useRadio();
/*
\ud83d\udc47 Impliserer om checked skal bli satt utifra
verdi fra parent og fra RadioButton
*/
const isChecked = currentValue === value;
return (
<label>
{label}
<input
type=\"radio\"
name={name}
onChange={(e) => onChange(e.target.value)}
value={value}
checked={isChecked}
{...props}
/>
</label>
);
}\nN\u00e5 kan vi slippe \u00e5 eksplisitt sette onChange, name og checked p\u00e5 RadioButton. De blir heller sendt ned fra konteksten (og checked blir implisert basert p\u00e5 n\u00e5v\u00e6rende verdi).
\nDette m\u00f8nsteret kalles \u201ccompound components\u201d (takk for innspill, Aurora Scharff \ud83d\udca1). Compound components inneb\u00e6rer ikke n\u00f8dvendigvis at React Context er brukt, men er n\u00e5r komponenter er beregnet \u00e5 bli brukt sammen\u200a\u2014\u200asom her at RadioGroup holder rede p\u00e5 tilstand for RadioItem. Ofte ser du compound components n\u00e5r komponenter eksporterer en hovedkomponent Card, og du kan bygge opp komponenten med Card.Header, Card.Body og Card.Footer.
\nReact Context trenger alts\u00e5 ikke \u00e5 v\u00e6re kun for de store, globale tingene, men ogs\u00e5 for sm\u00e5 komponenter der vi vet parent og child kommer til \u00e5 brukes sammen. I dette tilfellet ga det et renere API, f\u00e6rre muligheter for feil og, kanskje viktigst, en komponent som er lettere \u00e5\u00a0bruke.
\nGj\u00f8r komponentene dine enklere med React Context was originally published in M\u00f8ller Digital on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["frontend","javascript","design-system-tips","react","software-engineering"]},{"title":"<ForrigeUke uke=\u201d15\u201d \u00e5r=\u201d2025\u201d />","pubDate":"2025-04-15 07:28:48","link":"https://blogg.bekk.no/forrigeuke-uke-15-%C3%A5r-2025-abb589551c3a?source=rss-417bd6fed236------2","guid":"https://medium.com/p/abb589551c3a","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for feilh\u00e5ndtering og alt-var-bedre-f\u00f8r\u200a\u2014\u200aog 1504 ting som skjedde i frontendverdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*wmBGMek0XM-WzDIb\")
Next.js er stadig verkt\u00f8yet jeg strekker meg etter, enten det er hobbyprosjekt eller profesjonelt. Men i de siste ukene har jeg sett en del poster om at Next.js- sider oppleves\u00a0tregt.
\nEn av postene var fra \u201cDocumenso\u201d, som skrev appen sin i Next.js. Men etter hvert som appen vokste og de tok i bruk React serverkomponenter og server actions, opplevde de problemer med debugging av server actions og bisarre bygg-feil.
\nOgs\u00e5 i frontendmilj\u00f8et i Bekk har vi diskutert bruken av server actions. Forrige uke var det noen kolleger som sleit med at server actions f\u00f8rte til at navigasjon mellom sider var tregt. Det viste seg at en av \u00e5rsakene er at server actions kj\u00f8rer sekvensielt, og vil i mellomtiden hindre navigasjon. Dette er trolig grunnen til at Next.js-dokumentasjonen anbefaler \u00e5 holde server actions lette\u200a\u2014\u200aalts\u00e5 \u00e5 bruke dem kun til muteringer, og ikke til \u00e5 hente\u00a0data.
\nOm du m\u00e5 ha annen funksjonalitet i server actions, kan du flytte funksjonalitet som ikke m\u00e5 skje med engang (som tracing og analytics) i en after-funksjon.
\nSelv om du bruker server actions riktig, kan du likevel m\u00f8te p\u00e5 problemer, som vist av denne ul\u00f8ste GitHub-issuen fra mai 2023. Om tipsene over ikke hjelper, s\u00e5 var oppfordringen b\u00e5de fra frontendmilj\u00f8et og i Documensos blogg \u00e5 bruke tRPC. Da slipper du i likhet med server actions \u00e5 definere API-endepunkter, kan kalle funksjonene du har definert p\u00e5 serveren og du f\u00e5r full typesikkerhet.
\nEn annen rot til treghet i Next.js- sider har v\u00e6rt React serverkomponenter. S\u00e5 merkbart var det, at en utvikler mente at han kunne kjenne igjen sider som brukte serverkomponenter:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*F9TFg0h45G7Dm5BFT9IU4w.png\")
Utvikler og YouTuber Theo Browne mener derimot at tregheten ikke kommer fra serverkomponentene i seg selv, men heller brukerfeil fra utviklerne. De har rett og slett glemt \u00e5 oppgi loading-tilstand.
\nBrukere forventer at apper er raske, og n\u00e5r du gj\u00f8r en handling og ikke f\u00e5r respons, oppleves appen treg og uresponsiv\u200a\u2014\u200asom kan f\u00f8re til rageclicks eller at brukeren forlater\u00a0appen.
\nN\u00e5r du laster data i klientsiden, er det lett \u00e5 huske \u00e5 gi loading tilstand. For om du pr\u00f8ver \u00e5 laste data, vil du f\u00e5 typefeil som sier at data kan v\u00e6re udefinert. Derfor laster du data f\u00f8rst n\u00e5r loading-tilstanden er\u00a0ferdig:
\nfunction ClientComponent () {
const { data, loading } = await getData();
if (isLoading) return <Spinner />
return <Component data={data} />
}\nMen med serverkomponenter fungerer det annerledes. Komponenten rendres \u00e9n gang f\u00f8rst n\u00e5r alle dataene er ferdig hentet. Du kan alts\u00e5 ikke rendre \u00e9n gang med spinner, s\u00e5 en gang med dataene. Dette betyr at hele komponenten blokkeres til await-kallet er ferdig, og det gir ingen synlig tilbakemelding til brukeren i mellomtiden:
\nasync function ServerComponent () {
const { data } = await getData();
return <Component data={data} />
}\nFor \u00e5 l\u00f8se dette m\u00e5 du eksplisitt bruke mekanismer som Next.js sin loading.tsx eller en Suspense-grense for \u00e5 vise noe mens dataene\u00a0lastes:
\n// loading.tsx\n
function Loading () {
return <p>Loading ...</p>
}
Siden datahentingen er p\u00e5 serveren, b\u00f8r hentingen skje raskere enn p\u00e5 klienten. Men om brukeren ikke ser noe endring, f\u00f8les appen tregere. I videoen forklarer Theo forskjellene p\u00e5 en multi page app og en single page app, og hvordan serverkomponenter havner\u00a0imellom.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*Bx6GI_8W3tDggKuw4KWmAA.png\")
Videoen er lang, men innsiktsfull. Ta en\u00a0titt!
\nhttps://medium.com/media/c30d8bb8bfff8392567d10750cc00246/hrefFor \u00e5 bringe litt lys tilbake i Next.js, deler jeg med deg ogs\u00e5 en utfyllende post om hvordan fem nettsider har f\u00e5tt forbedret ytelsen, ogs\u00e5 ved bruk av nye React og Next.js-funksjoner. Osmani og Djirde viser deg hvilken konsekvens trege nettsider har \u00e5 si. Du f\u00e5r se at n\u00e5r det er snakk om markedsplasser, kan millisekunder virkelig v\u00e6re forskjellen p\u00e5 om et bes\u00f8k blir til et salg eller noen som bare trykker seg\u00a0videre.
\nForfatterne deler utfordringer og l\u00f8sninger, og konkluderer dette i syv undertemaer, og gir deg seks bestepraksiser du kan ta med\u00a0videre:
\nOm du er nysgjerrig p\u00e5 hvordan de havna p\u00e5 disse seks praksisene, ta en titt p\u00e5 casene her: https://largeapps.dev/case-studies/advanced/
\nI fjor\u00e5rets React Conf hadde React-profil Dan Abramov et foredrag til hensikt \u00e5 forklare React serverkomponenter, og foredraget kalte han \u201cReact for two computers\u201d. Abramov gikk helt til det grunnleggende, og abstrakte, om hvordan du snakker mellom klient- og serversiden.
\nJeg husker jeg hadde noen a-ha \u00f8yeblikk under foredraget\u200a\u2014\u200aog jeg m\u00e5 innr\u00f8mme at jeg ogs\u00e5 hadde en del sp\u00f8rsm\u00e5lstegn. N\u00e5 har Abramov gitt foredraget i form av en bloggpost, en slags 2.0 for \u00e5 utdype poengene hans, men fra den oppf\u00f8lgende BlueSky-tweeten, har jeg ikke store forventninger om \u00e5 f\u00e5 sp\u00f8rsm\u00e5lstegnene oppklart:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*RvP69e6xrF0zCIJCyofSNQ.png\")
Jeg tror ikke det du f\u00e5r ut av posten er s\u00e5 anvendbart\u200a\u2014\u200ahvert fall ikke i f\u00f8rste omgang. Men det var en del interessante poeng der, som du ikke tenker p\u00e5 i din vanlige\u00a0hverdag.
\nBare i noen av de f\u00f8rste avsnittene sammenligner han tags og funksjoner. Har du fundert p\u00e5 at tags kan tenkes p\u00e5 som substantiver, mens funksjoner er\u00a0verb?
\nEtter posten har du kanskje oppdatert din mentale modell for serverkomponenter, og kanskje webutvikling og koding generelt.
\nS\u00e5 ta en titt p\u00e5 posten. Njutes best med en solo og en kvikklunsj eller to. Ogs\u00e5 er det ingen skam \u00e5\u00a0snu:
\n\nDet var alt for denne gang. Ha en riktig god\u00a0p\u00e5ske!
\n<ForrigeUke uke=\u201d15\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for feilh\u00e5ndtering og alt-var-bedre-f\u00f8r\u200a\u2014\u200aog 1504 ting som skjedde i frontendverdenen!
\nNext.js er stadig verkt\u00f8yet jeg strekker meg etter, enten det er hobbyprosjekt eller profesjonelt. Men i de siste ukene har jeg sett en del poster om at Next.js- sider oppleves\u00a0tregt.
\nEn av postene var fra \u201cDocumenso\u201d, som skrev appen sin i Next.js. Men etter hvert som appen vokste og de tok i bruk React serverkomponenter og server actions, opplevde de problemer med debugging av server actions og bisarre bygg-feil.
\nOgs\u00e5 i frontendmilj\u00f8et i Bekk har vi diskutert bruken av server actions. Forrige uke var det noen kolleger som sleit med at server actions f\u00f8rte til at navigasjon mellom sider var tregt. Det viste seg at en av \u00e5rsakene er at server actions kj\u00f8rer sekvensielt, og vil i mellomtiden hindre navigasjon. Dette er trolig grunnen til at Next.js-dokumentasjonen anbefaler \u00e5 holde server actions lette\u200a\u2014\u200aalts\u00e5 \u00e5 bruke dem kun til muteringer, og ikke til \u00e5 hente\u00a0data.
\nOm du m\u00e5 ha annen funksjonalitet i server actions, kan du flytte funksjonalitet som ikke m\u00e5 skje med engang (som tracing og analytics) i en after-funksjon.
\nSelv om du bruker server actions riktig, kan du likevel m\u00f8te p\u00e5 problemer, som vist av denne ul\u00f8ste GitHub-issuen fra mai 2023. Om tipsene over ikke hjelper, s\u00e5 var oppfordringen b\u00e5de fra frontendmilj\u00f8et og i Documensos blogg \u00e5 bruke tRPC. Da slipper du i likhet med server actions \u00e5 definere API-endepunkter, kan kalle funksjonene du har definert p\u00e5 serveren og du f\u00e5r full typesikkerhet.
\nEn annen rot til treghet i Next.js- sider har v\u00e6rt React serverkomponenter. S\u00e5 merkbart var det, at en utvikler mente at han kunne kjenne igjen sider som brukte serverkomponenter:
\nUtvikler og YouTuber Theo Browne mener derimot at tregheten ikke kommer fra serverkomponentene i seg selv, men heller brukerfeil fra utviklerne. De har rett og slett glemt \u00e5 oppgi loading-tilstand.
\nBrukere forventer at apper er raske, og n\u00e5r du gj\u00f8r en handling og ikke f\u00e5r respons, oppleves appen treg og uresponsiv\u200a\u2014\u200asom kan f\u00f8re til rageclicks eller at brukeren forlater\u00a0appen.
\nN\u00e5r du laster data i klientsiden, er det lett \u00e5 huske \u00e5 gi loading tilstand. For om du pr\u00f8ver \u00e5 laste data, vil du f\u00e5 typefeil som sier at data kan v\u00e6re udefinert. Derfor laster du data f\u00f8rst n\u00e5r loading-tilstanden er\u00a0ferdig:
\nfunction ClientComponent () {
const { data, loading } = await getData();
if (isLoading) return <Spinner />
return <Component data={data} />
}\nMen med serverkomponenter fungerer det annerledes. Komponenten rendres \u00e9n gang f\u00f8rst n\u00e5r alle dataene er ferdig hentet. Du kan alts\u00e5 ikke rendre \u00e9n gang med spinner, s\u00e5 en gang med dataene. Dette betyr at hele komponenten blokkeres til await-kallet er ferdig, og det gir ingen synlig tilbakemelding til brukeren i mellomtiden:
\nasync function ServerComponent () {
const { data } = await getData();
return <Component data={data} />
}\nFor \u00e5 l\u00f8se dette m\u00e5 du eksplisitt bruke mekanismer som Next.js sin loading.tsx eller en Suspense-grense for \u00e5 vise noe mens dataene\u00a0lastes:
\n// loading.tsx\n
function Loading () {
return <p>Loading ...</p>
}
Siden datahentingen er p\u00e5 serveren, b\u00f8r hentingen skje raskere enn p\u00e5 klienten. Men om brukeren ikke ser noe endring, f\u00f8les appen tregere. I videoen forklarer Theo forskjellene p\u00e5 en multi page app og en single page app, og hvordan serverkomponenter havner\u00a0imellom.
\nVideoen er lang, men innsiktsfull. Ta en\u00a0titt!
\nhttps://medium.com/media/c30d8bb8bfff8392567d10750cc00246/hrefFor \u00e5 bringe litt lys tilbake i Next.js, deler jeg med deg ogs\u00e5 en utfyllende post om hvordan fem nettsider har f\u00e5tt forbedret ytelsen, ogs\u00e5 ved bruk av nye React og Next.js-funksjoner. Osmani og Djirde viser deg hvilken konsekvens trege nettsider har \u00e5 si. Du f\u00e5r se at n\u00e5r det er snakk om markedsplasser, kan millisekunder virkelig v\u00e6re forskjellen p\u00e5 om et bes\u00f8k blir til et salg eller noen som bare trykker seg\u00a0videre.
\nForfatterne deler utfordringer og l\u00f8sninger, og konkluderer dette i syv undertemaer, og gir deg seks bestepraksiser du kan ta med\u00a0videre:
\nOm du er nysgjerrig p\u00e5 hvordan de havna p\u00e5 disse seks praksisene, ta en titt p\u00e5 casene her: https://largeapps.dev/case-studies/advanced/
\nI fjor\u00e5rets React Conf hadde React-profil Dan Abramov et foredrag til hensikt \u00e5 forklare React serverkomponenter, og foredraget kalte han \u201cReact for two computers\u201d. Abramov gikk helt til det grunnleggende, og abstrakte, om hvordan du snakker mellom klient- og serversiden.
\nJeg husker jeg hadde noen a-ha \u00f8yeblikk under foredraget\u200a\u2014\u200aog jeg m\u00e5 innr\u00f8mme at jeg ogs\u00e5 hadde en del sp\u00f8rsm\u00e5lstegn. N\u00e5 har Abramov gitt foredraget i form av en bloggpost, en slags 2.0 for \u00e5 utdype poengene hans, men fra den oppf\u00f8lgende BlueSky-tweeten, har jeg ikke store forventninger om \u00e5 f\u00e5 sp\u00f8rsm\u00e5lstegnene oppklart:
\nJeg tror ikke det du f\u00e5r ut av posten er s\u00e5 anvendbart\u200a\u2014\u200ahvert fall ikke i f\u00f8rste omgang. Men det var en del interessante poeng der, som du ikke tenker p\u00e5 i din vanlige\u00a0hverdag.
\nBare i noen av de f\u00f8rste avsnittene sammenligner han tags og funksjoner. Har du fundert p\u00e5 at tags kan tenkes p\u00e5 som substantiver, mens funksjoner er\u00a0verb?
\nEtter posten har du kanskje oppdatert din mentale modell for serverkomponenter, og kanskje webutvikling og koding generelt.
\nS\u00e5 ta en titt p\u00e5 posten. Njutes best med en solo og en kvikklunsj eller to. Ogs\u00e5 er det ingen skam \u00e5\u00a0snu:
\n\nDet var alt for denne gang. Ha en riktig god\u00a0p\u00e5ske!
\n<ForrigeUke uke=\u201d15\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["react","technology","forrigeuke","frontend","javascript"]},{"title":"<ForrigeUke uke=\u201d11\u201d \u00e5r=\u201d2025\u201d />","pubDate":"2025-03-18 11:04:49","link":"https://blogg.bekk.no/forrigeuke-uke-11-%C3%A5r-2025-8cf7115c4d4f?source=rss-417bd6fed236------2","guid":"https://medium.com/p/8cf7115c4d4f","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for selektiv versjonering og slettede l\u00f8fter\u200a\u2014\u200aog 1705 ting som skjedde i frontendverdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*z9kOiPRxN3YSnMaM\")
Jeg var ganske blown away da jeg h\u00f8rte at en luring av en kollega hadde brukt Next.js\u200a\u2014\u200aikke for grensesnittet\u200a\u2014\u200amen for \u00e5 sette opp et API. F\u00f8r du tenker at det er overkill \u00e5 bruke et rammeverk for bare en br\u00f8kdel av funksjonaliteten, s\u00e5 kan jeg si hvorfor valget falt dit: det viste seg at med Vercels enkle oppsett, var det raskere \u00e5 bruke Next.js for hans m\u00e5l, enn \u00e5 spinne opp en simplere Express-server.
\nLee Robinson har n\u00e5 hosta opp en ny guide for hvordan du ogs\u00e5 kan bygge API-er med Next.js. Du kan sjekke ut posten for detaljene, men mest interessant syns jeg det var \u00e5 h\u00f8re om n\u00e5r det er lurt og\u00a0ikke.
\nRobinson gir deg fire grunner til hvorfor du kan \u00f8nske \u00e5 bruke API via Next.js (da ogs\u00e5 med et tilh\u00f8rende grensesnitt):
\nHelt enkelt kan et endepunkt i Next.js se slik\u00a0ut:
\n// app/api/users/route.ts\n
export async function GET(request: Request) {
// \ud83d\udc47 Her henter du for eksempel data fra databasen din
const users = [
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' }
];
return new Response(JSON.stringify(users), {
status: 200,
headers: { 'Content-Type': 'application/json' }
});
}
S\u00e5 kan du kalle API-et med en GET til /api/users.
\nDet er ogs\u00e5 tilfeller du ikke trenger \u00e5 lage API-er i Next.js. Om alle dataene er kun brukt i Next-appen din, trenger du ikke eksponere API-et\u200a\u2014\u200aog kan heller ta i bruk React serverkomponenter.
\nDet kan se slik\u00a0ut:
\n// app/users/page.tsx\n
export default async function UsersPage() {
// \ud83d\udc47 Denne fetchen kj\u00f8rer p\u00e5 serveren
const res = await fetch('https://api.example.com/users');
const data = await res.json();
return (
<ul>
{data.map((user: any) => (
<li key={user.id}>{user.name}</li>
))}
</ul>
);
En annen m\u00e5te \u00e5 kommunisere med serveren p\u00e5 er ved hjelp av Server Actions. Robinson forklarer at Server Actions er som automatisk genererte API-ruter for POST-requests, som kan bli kalt fra klienten. Selv om det skjer en request, definerer du ikke ruta manuelt. URL-pathen er nemlig autogenerert og kryptert, s\u00e5 du kan ikke aksessere ruta via /api/users i nettleseren.
\nRent praktisk definerer du en funksjon med \u201cuse server\u201d- direktivet:
\n// actions.ts\n
\"use server\";
import { getCurrentUser } from \"@/data/auth\"; // Henter innlogget bruker
import { db } from \"@/lib/db\"; // Simulert database
export async function updateUser(name: string) {
const user = await getCurrentUser();
if (!user) {
throw new Error(\"Du m\u00e5 v\u00e6re innlogget for \u00e5 oppdatere brukeren din.\");
}
await db.user.update({
where: { id: user.id },
data: { name },
});
}
S\u00e5 kan du kalle funksjonen i klienten, uten \u00e5 trenge \u00e5 definere\u00a0rute:
\n// updateUser.tsx\n
\"use client\";
import { updateUser } from \"@/actions\"; // Importer Server Action
export default function UpdateUserForm() {
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
try {
const message = await updateUser(name);
} catch (error) {
alert(\"Noe gikk galt!\");
}
S\u00e5 hvor passer server actions inn sammen med RSC og API-ruter?
\nOm du lurer mer p\u00e5 sikkerhet rundt disse valgene, ta en titt\u00a0her:
\nHow to Think About Security in Next.js
\nLikt som at det fins mange valg for \u00e5 kommunisere med serveren, er det ogs\u00e5 mange valg for state i klienten. Der tror jeg URL-er er et ofte oversett\u00a0verkt\u00f8y.
\n\u201cVil jeg at brukeren skal beholde samme innhold etter refresh av siden?\u201d, er sp\u00f8rsm\u00e5let Sahaj Jain oppfordrer deg til \u00e5 stille n\u00e5r du lurer p\u00e5 hvilket tilstandsverkt\u00f8y du vil\u00a0bruke.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*AEzohvcvPxjwi1LDkO8Y1g.png\")
Om du \u00f8nsker at en modal skal forbli \u00e5pen etter refresh, kan du ikke bare ty til useState, for da vil tilstanden forsvinne med arbeidsminnet. P\u00e5 den andre siden h\u00f8res en database-oppf\u00f8ring ut som et overkill for en modal, for ikke \u00e5 snakke om tregt. Men en URL vil la deg persistere innholdet p\u00e5 tvers av \u00f8kter, og lar brukeren ogs\u00e5 dele tilstanden med andre. Og det kan til og med v\u00e6re raskere enn localstorage.
\nDet kan se slik\u00a0ut:
\neksempelside.no/dashboard?modal=open\n
For utvikleren kan bruk av URL ogs\u00e5 forenkle koden, ved at tilstanden er global, s\u00e5 du slipper \u00e5 prop-drille eller ta i bruk andre verkt\u00f8y for verdier som gj\u00f8r dataene tilgjengelig.
\nF\u00f8r har det v\u00e6rt en utfordring med typesikring for URL-parametere, men n\u00e5 har det blitt til salgspunktene for visse verkt\u00f8y, som TanStack\u00a0Router.
\nMen la meg gi deg en liten advarsel, f\u00f8r URL-ene dine ender opp\u00a0slik:
\neksempelside.no/dashboard?modal=open&darkmode=true&username=ola&pw=123\n
Ta ogs\u00e5 en titt p\u00e5 n\u00e5r du ikke b\u00f8r bruke URL-er for\u00a0state:
\nThe URL is a great place to store state in React
\nDet var alt for denne gang. H\u00e5per du f\u00e5r en solrik uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d11\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for selektiv versjonering og slettede l\u00f8fter\u200a\u2014\u200aog 1705 ting som skjedde i frontendverdenen!
\nJeg var ganske blown away da jeg h\u00f8rte at en luring av en kollega hadde brukt Next.js\u200a\u2014\u200aikke for grensesnittet\u200a\u2014\u200amen for \u00e5 sette opp et API. F\u00f8r du tenker at det er overkill \u00e5 bruke et rammeverk for bare en br\u00f8kdel av funksjonaliteten, s\u00e5 kan jeg si hvorfor valget falt dit: det viste seg at med Vercels enkle oppsett, var det raskere \u00e5 bruke Next.js for hans m\u00e5l, enn \u00e5 spinne opp en simplere Express-server.
\nLee Robinson har n\u00e5 hosta opp en ny guide for hvordan du ogs\u00e5 kan bygge API-er med Next.js. Du kan sjekke ut posten for detaljene, men mest interessant syns jeg det var \u00e5 h\u00f8re om n\u00e5r det er lurt og\u00a0ikke.
\nRobinson gir deg fire grunner til hvorfor du kan \u00f8nske \u00e5 bruke API via Next.js (da ogs\u00e5 med et tilh\u00f8rende grensesnitt):
\nHelt enkelt kan et endepunkt i Next.js se slik\u00a0ut:
\n// app/api/users/route.ts\n
export async function GET(request: Request) {
// \ud83d\udc47 Her henter du for eksempel data fra databasen din
const users = [
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' }
];
return new Response(JSON.stringify(users), {
status: 200,
headers: { 'Content-Type': 'application/json' }
});
}
S\u00e5 kan du kalle API-et med en GET til /api/users.
\nDet er ogs\u00e5 tilfeller du ikke trenger \u00e5 lage API-er i Next.js. Om alle dataene er kun brukt i Next-appen din, trenger du ikke eksponere API-et\u200a\u2014\u200aog kan heller ta i bruk React serverkomponenter.
\nDet kan se slik\u00a0ut:
\n// app/users/page.tsx\n
export default async function UsersPage() {
// \ud83d\udc47 Denne fetchen kj\u00f8rer p\u00e5 serveren
const res = await fetch('https://api.example.com/users');
const data = await res.json();
return (
<ul>
{data.map((user: any) => (
<li key={user.id}>{user.name}</li>
))}
</ul>
);
En annen m\u00e5te \u00e5 kommunisere med serveren p\u00e5 er ved hjelp av Server Actions. Robinson forklarer at Server Actions er som automatisk genererte API-ruter for POST-requests, som kan bli kalt fra klienten. Selv om det skjer en request, definerer du ikke ruta manuelt. URL-pathen er nemlig autogenerert og kryptert, s\u00e5 du kan ikke aksessere ruta via /api/users i nettleseren.
\nRent praktisk definerer du en funksjon med \u201cuse server\u201d- direktivet:
\n// actions.ts\n
\"use server\";
import { getCurrentUser } from \"@/data/auth\"; // Henter innlogget bruker
import { db } from \"@/lib/db\"; // Simulert database
export async function updateUser(name: string) {
const user = await getCurrentUser();
if (!user) {
throw new Error(\"Du m\u00e5 v\u00e6re innlogget for \u00e5 oppdatere brukeren din.\");
}
await db.user.update({
where: { id: user.id },
data: { name },
});
}
S\u00e5 kan du kalle funksjonen i klienten, uten \u00e5 trenge \u00e5 definere\u00a0rute:
\n// updateUser.tsx\n
\"use client\";
import { updateUser } from \"@/actions\"; // Importer Server Action
export default function UpdateUserForm() {
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
try {
const message = await updateUser(name);
} catch (error) {
alert(\"Noe gikk galt!\");
}
S\u00e5 hvor passer server actions inn sammen med RSC og API-ruter?
\nOm du lurer mer p\u00e5 sikkerhet rundt disse valgene, ta en titt\u00a0her:
\nHow to Think About Security in Next.js
\nLikt som at det fins mange valg for \u00e5 kommunisere med serveren, er det ogs\u00e5 mange valg for state i klienten. Der tror jeg URL-er er et ofte oversett\u00a0verkt\u00f8y.
\n\u201cVil jeg at brukeren skal beholde samme innhold etter refresh av siden?\u201d, er sp\u00f8rsm\u00e5let Sahaj Jain oppfordrer deg til \u00e5 stille n\u00e5r du lurer p\u00e5 hvilket tilstandsverkt\u00f8y du vil\u00a0bruke.
\nOm du \u00f8nsker at en modal skal forbli \u00e5pen etter refresh, kan du ikke bare ty til useState, for da vil tilstanden forsvinne med arbeidsminnet. P\u00e5 den andre siden h\u00f8res en database-oppf\u00f8ring ut som et overkill for en modal, for ikke \u00e5 snakke om tregt. Men en URL vil la deg persistere innholdet p\u00e5 tvers av \u00f8kter, og lar brukeren ogs\u00e5 dele tilstanden med andre. Og det kan til og med v\u00e6re raskere enn localstorage.
\nDet kan se slik\u00a0ut:
\neksempelside.no/dashboard?modal=open\n
For utvikleren kan bruk av URL ogs\u00e5 forenkle koden, ved at tilstanden er global, s\u00e5 du slipper \u00e5 prop-drille eller ta i bruk andre verkt\u00f8y for verdier som gj\u00f8r dataene tilgjengelig.
\nF\u00f8r har det v\u00e6rt en utfordring med typesikring for URL-parametere, men n\u00e5 har det blitt til salgspunktene for visse verkt\u00f8y, som TanStack\u00a0Router.
\nMen la meg gi deg en liten advarsel, f\u00f8r URL-ene dine ender opp\u00a0slik:
\neksempelside.no/dashboard?modal=open&darkmode=true&username=ola&pw=123\n
Ta ogs\u00e5 en titt p\u00e5 n\u00e5r du ikke b\u00f8r bruke URL-er for\u00a0state:
\nThe URL is a great place to store state in React
\nDet var alt for denne gang. H\u00e5per du f\u00e5r en solrik uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d11\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["technology","forrigeuke","frontend","javascript","react"]},{"title":"<ForrigeUke uke=\u201d7\u201d \u00e5r=\u201d2025\u201d />","pubDate":"2025-02-19 07:34:12","link":"https://blogg.bekk.no/forrigeuke-uke-7-%C3%A5r-2025-53aa2d782c0b?source=rss-417bd6fed236------2","guid":"https://medium.com/p/53aa2d782c0b","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for typefeil og valentinesdates\u200a\u2014\u200aog 1402 ting som skjedde i frontendverdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*hG9UirbhpADpfFoM\")
Da jeg browset YouTube forrige uke, ble jeg gledelig overrasket: Honeypot har kommet ut med en ny dokumentar! Forrige gang s\u00e5 vi dramaet til Vue og React, fra id\u00e9 til popul\u00e6rt verkt\u00f8y, og denne gangen ser vi historien om\u00a0\u2026 \ud83e\udd41\u00a0Angular!
\nPersonlig har jeg bare r\u00f8rt Angular \u00e9n gang. Det var da jeg lagde en todo-app som forberedelse til et jobbintervju, hvor jeg hadde h\u00f8rt bedriften brukte Angular. Det viste seg at jobben ikke var i en stilling som webutvikler, s\u00e5 det ble med den samtalen.
\nEllers er min kilde til kunnskap om Angular fra memes, hvor det gjerne gj\u00f8res narr av hvor komplisert eller gammelt det\u00a0er.
\nEtter \u00e5 ha sett dokumentaren, tror jeg at Angular er misforst\u00e5tt. Fireship syns hvert fall at det b\u00f8r ha mer\u00a0respekt.
\nDokumentaren belyser noen av \u00e5rsakene til at Angular ikke er s\u00e5 lett \u00e5 forst\u00e5. Massive omskrivinger har f\u00f8rt til at utviklere b\u00e5de har falt av og ikke helt skj\u00f8nt hvilken variant det egentlig snakkes om. I dag er Angular p\u00e5 versjon 19, og brukes av et av de st\u00f8rste selskapene i verden\u200a\u2014\u200aGoogle\u200a\u2014\u200asom det ogs\u00e5 finansieres av.
\nSelv om jeg sikkert ikke kommer til \u00e5 bruke Angular med det f\u00f8rste, har jeg likevel tre refleksjoner jeg tar med tilbake i min lille React-boble:
\nAngular har p\u00e5virket frontendverdenen gjennom\u00a0\u00e5rene
\nF\u00f8r Angular, var jQuery det dominerende verkt\u00f8yet for \u00e5 oppdatere UI. Men jQuery kunne f\u00f8re til mye komplisert kode, der utviklere manuelt m\u00e5tte manipulere DOM-en. Angular forenklet dette ved \u00e5 popularisere deklarative komponenter\u200a\u2014\u200aen tiln\u00e6rming som har inspirert mange moderne frontend-rammeverk.
\nEt annet modig valg, var \u00e5 ta i bruk TypeScript. Angular m\u00f8tte mye skepsis for \u00e5 ta i bruk et typesystem, som f\u00f8r bare h\u00f8rte hjemme i backend. Men i dag er TypeScript standard for nye frontend-prosjekter.
\nFor ett \u00e5r siden tok Angular ogs\u00e5 i bruk signals, inspirert av SolidJS og Svelte. Forenkling eller ikke, opp gjennom har Angular pr\u00f8vd ut mange ting for \u00e5 pr\u00f8ve \u00e5 gj\u00f8re webutvikling enklere.
\nState kan l\u00f8ses p\u00e5 mange\u00a0m\u00e5ter
\nAngulars introduksjon av signals viser at du kan l\u00f8se tilstand p\u00e5 mange\u00a0m\u00e5ter.
\nOpprinnelig benyttet Angular2 RxJS for tilstandsh\u00e5ndtering, hvor utviklere brukte \u201cobservables\u201d og \u201csubscriptions\u201d for \u00e5 h\u00e5ndtere tilstandsendringer, b\u00e5de for synkron og asynkron tilstand. Dette kunne f\u00f8re til kompleks kode og krevde manuell h\u00e5ndtering av abonnementer for \u00e5 unng\u00e5 minnelekkasjer. For \u00e5 forenkle denne prosessen, byttet Angular den synkrone oppdateringen med signals. Om du er nysgjerrig p\u00e5 hvorfor ha begge deler, har Joshua Morony en forklaring her.
\nI React endrer du tilstand, s\u00e5 re-rendrer du hele komponenten. Men med signals ser du ikke p\u00e5 tilstand som en rekke av hendelser, men du ser p\u00e5 hvordan den enkelte verdien endres over tid. Dermed kan du presist endre deler av grensesnittet, uten \u00e5 re-rendre hele komponenten. Dette kan forbedre ytelsen ved \u00e5 redusere un\u00f8dvendig arbeid.
\nSignals h\u00f8res n\u00e5 lurt ut, s\u00e5 hvorfor har ikke ogs\u00e5 React tatt signals i\u00a0bruk?
\nReact har flere ganger diskutert bruken av signals. Men React og Angular g\u00e5r mot forskjellige veier n\u00e5r det kommer til UI-oppdatering. React har sett til andre l\u00f8sninger for \u00e5 forbedre tilstandsh\u00e5ndteringen, som \u00e5 effektivisere re-rendringen som f\u00f8lger. React la til memoiseringsfunksjoner som useMemo, og nylig introduserte de React-kompilatoren hvor du slipper \u00e5 tenke p\u00e5 \u00e5 legge til disse funksjonene selv\u200a\u2014\u200adet skjer automatisk. React kom ogs\u00e5 n\u00e5 med RSC, hvor du laster inn UI-et sammen med dataene p\u00e5 forh\u00e5nd\u200a\u2014\u200as\u00e5 du slipper \u00e5 holde dataene i\u00a0sync.
\nDu kan miste mange brukere ved store endringer\u200a\u2014\u200aeller for\u00a0f\u00e5
\nAngular-teamet har introdusert hvert fall to store endringer som har utfordret brukerne\u00a0deres.
\nOvergangen fra AngularJS til Angular2 tvang konsumerne \u00e5 gj\u00f8re store omskrivinger. \u201cOmskrivingen kunne likegodt bli kalt \u2018GoogleJS\u2019\u201d, sa en utvikler, for omskrivingen var s\u00e5 stor at det kunne f\u00e5tt et nytt navn. Det var heller ikke bare \u00e5 google til seg endringene som var gjort, fordi det dukket opp dokumentasjon for det gamle, og det var ikke tydelig hva som var nytt eller\u00a0gammelt.
\nAngular-teamet gjorde ogs\u00e5 en stor endring i det s\u00e5kalte Ivy-prosjektet, som var en massiv refaktorering. Konsumerne merket lite til refaktoreringen direkte, men det krevde mye tid av Angular-teamet, som f\u00f8rte til at det var flere \u00e5r hvor det ikke kom noe s\u00e6rlig ny funksjonalitet. Angular opplevdes derfor d\u00f8d, s\u00e5 Angular mistet\u00a0moment.
\nReact har lykkes ved \u00e5 jevnlig levere mindre oppdateringer. Alts\u00e5, du har den store introduksjonen av hooks som ga noen hjertesukk, men ogs\u00e5 denne var opt-in. React har til n\u00e5 v\u00e6rt mer forsiktig med radikale endringer. Men med introduksjonen av RSC, kanskje vi kan se lignende utfordringer?
\nTa en titt p\u00e5 origin-storyen, dramaet som utspilte seg, og hvor det er p\u00e5 vei i\u00a02025:
\nhttps://medium.com/media/7993e8b04046fcb2c0ebc5bebc598e91/hrefOm ikke annet, s\u00e5 har Angular hvert fall en fordel over React: du m\u00e5 ikke \u00e5rlig l\u00e6re deg hvordan du starter opp et nytt prosjekt.
\nAngular kommer med batterier inkludert, mens med React m\u00e5 du gj\u00f8re en dr\u00f8ss med valg. Heldigvis har Robin Wieruch gitt oss React-guiden for i\u00a0\u00e5r.
\nArtikkelen gir oss tre alternativer \u00e5 vurdere: Vite, NextJS eller Astro. S\u00e5 hva skal brukes\u00a0n\u00e5r?
\nOm du bare trenger en lettvekts-app, bruk Vite. Da kan du selv dra inn de bibliotekene du vil ha. Det er best om du bare trenger klientside-rendring.
\nVite passer ogs\u00e5 bra n\u00e5r du skal l\u00e6re deg React. For da kan du l\u00e6re det fundamentale ved React, istedenfor \u00e5 havne borti NextJS-spesifikke greier.
\nOm du ser etter \u00e5 ha batterier inkludert, er NextJS er godt valg. Det er den mest modne l\u00f8sningen n\u00e5, og gir deg funksjonalitet som routing, rendringsstrategier, SEO og bildeoptimalisering. En stor fordel med NextJS er at det er et fullstack rammeverk, s\u00e5 du kan koble deg til databaser og autentisering, uten \u00e5 skifte mellom kodebaser.
\nOm du hovedsakelig skal h\u00e5ndtere innholds-fokuserte nettsider, kan Astro v\u00e6re et bedre valg enn NextJS. \u00c5rsaken er at Astro har en \u00f8y-arkitektur\u200a\u2014\u200aalts\u00e5 hver side er sin egen greie. Dette gj\u00f8r at sidene lastes mye raskere. Med Astro har du alts\u00e5 ikke en SPA, men en MPA\u200a\u2014\u200amulti page application.
\nTa en titt p\u00e5 flere av forskjellene i bloggposten:
\nHow to start a React Project [2025]
\nDet var alt for denne gangen\u200a\u2014\u200asnakkes neste uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d7\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for typefeil og valentinesdates\u200a\u2014\u200aog 1402 ting som skjedde i frontendverdenen!
\nDa jeg browset YouTube forrige uke, ble jeg gledelig overrasket: Honeypot har kommet ut med en ny dokumentar! Forrige gang s\u00e5 vi dramaet til Vue og React, fra id\u00e9 til popul\u00e6rt verkt\u00f8y, og denne gangen ser vi historien om\u00a0\u2026 \ud83e\udd41\u00a0Angular!
\nPersonlig har jeg bare r\u00f8rt Angular \u00e9n gang. Det var da jeg lagde en todo-app som forberedelse til et jobbintervju, hvor jeg hadde h\u00f8rt bedriften brukte Angular. Det viste seg at jobben ikke var i en stilling som webutvikler, s\u00e5 det ble med den samtalen.
\nEllers er min kilde til kunnskap om Angular fra memes, hvor det gjerne gj\u00f8res narr av hvor komplisert eller gammelt det\u00a0er.
\nEtter \u00e5 ha sett dokumentaren, tror jeg at Angular er misforst\u00e5tt. Fireship syns hvert fall at det b\u00f8r ha mer\u00a0respekt.
\nDokumentaren belyser noen av \u00e5rsakene til at Angular ikke er s\u00e5 lett \u00e5 forst\u00e5. Massive omskrivinger har f\u00f8rt til at utviklere b\u00e5de har falt av og ikke helt skj\u00f8nt hvilken variant det egentlig snakkes om. I dag er Angular p\u00e5 versjon 19, og brukes av et av de st\u00f8rste selskapene i verden\u200a\u2014\u200aGoogle\u200a\u2014\u200asom det ogs\u00e5 finansieres av.
\nSelv om jeg sikkert ikke kommer til \u00e5 bruke Angular med det f\u00f8rste, har jeg likevel tre refleksjoner jeg tar med tilbake i min lille React-boble:
\nAngular har p\u00e5virket frontendverdenen gjennom\u00a0\u00e5rene
\nF\u00f8r Angular, var jQuery det dominerende verkt\u00f8yet for \u00e5 oppdatere UI. Men jQuery kunne f\u00f8re til mye komplisert kode, der utviklere manuelt m\u00e5tte manipulere DOM-en. Angular forenklet dette ved \u00e5 popularisere deklarative komponenter\u200a\u2014\u200aen tiln\u00e6rming som har inspirert mange moderne frontend-rammeverk.
\nEt annet modig valg, var \u00e5 ta i bruk TypeScript. Angular m\u00f8tte mye skepsis for \u00e5 ta i bruk et typesystem, som f\u00f8r bare h\u00f8rte hjemme i backend. Men i dag er TypeScript standard for nye frontend-prosjekter.
\nFor ett \u00e5r siden tok Angular ogs\u00e5 i bruk signals, inspirert av SolidJS og Svelte. Forenkling eller ikke, opp gjennom har Angular pr\u00f8vd ut mange ting for \u00e5 pr\u00f8ve \u00e5 gj\u00f8re webutvikling enklere.
\nState kan l\u00f8ses p\u00e5 mange\u00a0m\u00e5ter
\nAngulars introduksjon av signals viser at du kan l\u00f8se tilstand p\u00e5 mange\u00a0m\u00e5ter.
\nOpprinnelig benyttet Angular2 RxJS for tilstandsh\u00e5ndtering, hvor utviklere brukte \u201cobservables\u201d og \u201csubscriptions\u201d for \u00e5 h\u00e5ndtere tilstandsendringer, b\u00e5de for synkron og asynkron tilstand. Dette kunne f\u00f8re til kompleks kode og krevde manuell h\u00e5ndtering av abonnementer for \u00e5 unng\u00e5 minnelekkasjer. For \u00e5 forenkle denne prosessen, byttet Angular den synkrone oppdateringen med signals. Om du er nysgjerrig p\u00e5 hvorfor ha begge deler, har Joshua Morony en forklaring her.
\nI React endrer du tilstand, s\u00e5 re-rendrer du hele komponenten. Men med signals ser du ikke p\u00e5 tilstand som en rekke av hendelser, men du ser p\u00e5 hvordan den enkelte verdien endres over tid. Dermed kan du presist endre deler av grensesnittet, uten \u00e5 re-rendre hele komponenten. Dette kan forbedre ytelsen ved \u00e5 redusere un\u00f8dvendig arbeid.
\nSignals h\u00f8res n\u00e5 lurt ut, s\u00e5 hvorfor har ikke ogs\u00e5 React tatt signals i\u00a0bruk?
\nReact har flere ganger diskutert bruken av signals. Men React og Angular g\u00e5r mot forskjellige veier n\u00e5r det kommer til UI-oppdatering. React har sett til andre l\u00f8sninger for \u00e5 forbedre tilstandsh\u00e5ndteringen, som \u00e5 effektivisere re-rendringen som f\u00f8lger. React la til memoiseringsfunksjoner som useMemo, og nylig introduserte de React-kompilatoren hvor du slipper \u00e5 tenke p\u00e5 \u00e5 legge til disse funksjonene selv\u200a\u2014\u200adet skjer automatisk. React kom ogs\u00e5 n\u00e5 med RSC, hvor du laster inn UI-et sammen med dataene p\u00e5 forh\u00e5nd\u200a\u2014\u200as\u00e5 du slipper \u00e5 holde dataene i\u00a0sync.
\nDu kan miste mange brukere ved store endringer\u200a\u2014\u200aeller for\u00a0f\u00e5
\nAngular-teamet har introdusert hvert fall to store endringer som har utfordret brukerne\u00a0deres.
\nOvergangen fra AngularJS til Angular2 tvang konsumerne \u00e5 gj\u00f8re store omskrivinger. \u201cOmskrivingen kunne likegodt bli kalt \u2018GoogleJS\u2019\u201d, sa en utvikler, for omskrivingen var s\u00e5 stor at det kunne f\u00e5tt et nytt navn. Det var heller ikke bare \u00e5 google til seg endringene som var gjort, fordi det dukket opp dokumentasjon for det gamle, og det var ikke tydelig hva som var nytt eller\u00a0gammelt.
\nAngular-teamet gjorde ogs\u00e5 en stor endring i det s\u00e5kalte Ivy-prosjektet, som var en massiv refaktorering. Konsumerne merket lite til refaktoreringen direkte, men det krevde mye tid av Angular-teamet, som f\u00f8rte til at det var flere \u00e5r hvor det ikke kom noe s\u00e6rlig ny funksjonalitet. Angular opplevdes derfor d\u00f8d, s\u00e5 Angular mistet\u00a0moment.
\nReact har lykkes ved \u00e5 jevnlig levere mindre oppdateringer. Alts\u00e5, du har den store introduksjonen av hooks som ga noen hjertesukk, men ogs\u00e5 denne var opt-in. React har til n\u00e5 v\u00e6rt mer forsiktig med radikale endringer. Men med introduksjonen av RSC, kanskje vi kan se lignende utfordringer?
\nTa en titt p\u00e5 origin-storyen, dramaet som utspilte seg, og hvor det er p\u00e5 vei i\u00a02025:
\nhttps://medium.com/media/7993e8b04046fcb2c0ebc5bebc598e91/hrefOm ikke annet, s\u00e5 har Angular hvert fall en fordel over React: du m\u00e5 ikke \u00e5rlig l\u00e6re deg hvordan du starter opp et nytt prosjekt.
\nAngular kommer med batterier inkludert, mens med React m\u00e5 du gj\u00f8re en dr\u00f8ss med valg. Heldigvis har Robin Wieruch gitt oss React-guiden for i\u00a0\u00e5r.
\nArtikkelen gir oss tre alternativer \u00e5 vurdere: Vite, NextJS eller Astro. S\u00e5 hva skal brukes\u00a0n\u00e5r?
\nOm du bare trenger en lettvekts-app, bruk Vite. Da kan du selv dra inn de bibliotekene du vil ha. Det er best om du bare trenger klientside-rendring.
\nVite passer ogs\u00e5 bra n\u00e5r du skal l\u00e6re deg React. For da kan du l\u00e6re det fundamentale ved React, istedenfor \u00e5 havne borti NextJS-spesifikke greier.
\nOm du ser etter \u00e5 ha batterier inkludert, er NextJS er godt valg. Det er den mest modne l\u00f8sningen n\u00e5, og gir deg funksjonalitet som routing, rendringsstrategier, SEO og bildeoptimalisering. En stor fordel med NextJS er at det er et fullstack rammeverk, s\u00e5 du kan koble deg til databaser og autentisering, uten \u00e5 skifte mellom kodebaser.
\nOm du hovedsakelig skal h\u00e5ndtere innholds-fokuserte nettsider, kan Astro v\u00e6re et bedre valg enn NextJS. \u00c5rsaken er at Astro har en \u00f8y-arkitektur\u200a\u2014\u200aalts\u00e5 hver side er sin egen greie. Dette gj\u00f8r at sidene lastes mye raskere. Med Astro har du alts\u00e5 ikke en SPA, men en MPA\u200a\u2014\u200amulti page application.
\nTa en titt p\u00e5 flere av forskjellene i bloggposten:
\nHow to start a React Project [2025]
\nDet var alt for denne gangen\u200a\u2014\u200asnakkes neste uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d7\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["javascript","technology","forrigeuke","react","frontend"]},{"title":"Test ideene dine med en egenprodusert podcast\u200a\u2014\u200ai 3 enkle steg","pubDate":"2025-02-13 07:38:55","link":"https://blogg.bekk.no/test-ideene-dine-med-en-egenprodusert-podcast-i-3-enkle-steg-6f90fe3d2c79?source=rss-417bd6fed236------2","guid":"https://medium.com/p/6f90fe3d2c79","author":"Marcus Haaland","thumbnail":"","description":"\nUnder koronatiden eksploderte mengden podcaster. Tre \u00e5r senere kan du lage din egen i 3 enkle steg. Men hvorfor i all verden skal du gj\u00f8re det? Ikke for \u00e5 bli den neste Friminutt eller Radioresepsjonen. Men av to andre grunner: for \u00e5 l\u00e6re og \u00e5 l\u00e6re\u00a0bort.
\nOm du er som meg, kan tunge, lange tekster f\u00e5 luften til \u00e5 forsvinne ut av deg. En samtale, derimot, hvor du f\u00e5r h\u00f8re sp\u00f8rsm\u00e5l og det tilh\u00f8rende svaret, holder oppmerksomheten p\u00e5 en helt annen m\u00e5te. N\u00e5 kan du dra nytte av dette prinsippet for \u00e5 teste ideene dine. For med NotebookLM kan du lage en podcast basert p\u00e5 notatene du har\u200a\u2014\u200aenten det er en presentasjon eller bloggpost du holder p\u00e5 \u00e5 forberede.
\nI tre enkle steg kan du f\u00e5 generert en samtale som angriper temaet ditt fra ulike vinkler\u200a\u2014\u200aog du kan ogs\u00e5 spesifisere hvordan narrativet skal\u00a0v\u00e6re.
\nStegene tar bare 5 minutter. Og nevnte jeg at det var\u00a0gratis?
\nDu starter f\u00f8rst med \u00e5 g\u00e5 inn p\u00e5 NotebookLMs nettside (https://notebooklm.google.com/). Du logger inn med Google og oppretter en ny notatbok:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*rv84c-_YN2fa4J9WVOYyHw.png\")
Idet du \u00e5pner notatboka, ser du tre\u00a0faner:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*0zFs55m8lKruDpkb-oBfWg.png\")
Disse tre delene\u00a0er:
\nFor \u00e5 lage en podcast trenger vi bare \u00e5 bry oss om kilder- og studio-fanen.
\nFor \u00e5 lage podcasten, trenger vertene noen kilder \u00e5 prate om. Det legger du til i venstre\u00a0fane:
\n![\"\"](\"https://cdn-images-1.medium.com/max/878/1*PV33xkMLopkinpqqcsJhWQ.png\")
Som du ser, kan du laste opp p\u00e5 mange ulike formater:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*p3GnilxTUSMoz0xywJviKg.png\")
Om du \u00f8nsker \u00e5 utforske om en bloggpost eller presentasjon kan fungere, kan du legge inn disposisjonen i \u201cLim inn tekst\u201d. Om du har kilder du refererer til, som en Wikipedia-side eller kode-dokumentasjon, legg til disse som\u00a0lenker.
\nEt genialt lite triks er \u00e5 kaste disposisjonen inn i ChatGPT, s\u00e5 sp\u00f8rre om et utkast for en bloggpost. Da f\u00e5r du litt mer fyll og mulighet til \u00e5 redigere f\u00f8r du genererer podcasten.
\nF\u00f8r du genererer podcasten, anbefaler jeg deg ogs\u00e5 \u00e5 tilpasse podcasten.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*PJmVq6OwYxms14aBf24d5g.png\")
Da f\u00e5r du en mindre generell podcast, og samtalen blir n\u00e6rere temaet du bryr deg om. Du kan spesifisere \u00e5 vektlegge visse kilder, som \u00e5 la podcasten utspille seg fra disposisjonen du har\u00a0oppgitt:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*L8Tj4ThwrGv9MwnuMq8LGA.png\")
Etter et par minutter, f\u00e5r du en podcast p\u00e5 alt fra 5 til 30 minutter (avhengig av mengde kilder) om ditt favoritt-tema!
\n![\"\"](\"https://cdn-images-1.medium.com/max/854/1*bM5QzNCP-TUgNtBisl3i2Q.png\")
Nysgjerrig p\u00e5 resultatet? Ta en lytt: https://notebooklm.google.com/notebook/c08e704b-7a5f-4fbf-892b-d09dd8b03225/audio
\nEtter \u00e5 ha generert podcasten, m\u00e5 du ikke bli sittende p\u00e5 PC-en for \u00e5 h\u00f8re den. Du kan g\u00e5 p\u00e5 inn p\u00e5 NotebookLM p\u00e5 mobilen, og h\u00f8re p\u00e5 lydklippet der, for det ligger p\u00e5 samme Google-konto.
\nDu kan ogs\u00e5 generere en offentlig lenke som du kan sende til deg selv eller venner. Bare \u00e5 trykke p\u00e5 \u201cDele\u201d-ikonet:
\n![\"\"](\"https://cdn-images-1.medium.com/max/830/1*EExkptZ7w4-CXAqPWkTd6w.png\")
Og kopier delingslenken:
\n![\"\"](\"https://cdn-images-1.medium.com/max/870/1*O6eVv0EXZHf_DDEREJhbNQ.png\")
Om du ikke liker det du h\u00f8rte, kan du slette podcasten, tilpasse teksten og pr\u00f8ve p\u00e5\u00a0nytt.
\nOm du fortsatt er i researchmodus, kan du f\u00e5 kildene oppsummert ved noen enkle tastetrykk. Under \u201cLydoversikten\u201d, er en meny \u201cNotater\u201d. Ved \u00e5 klikke p\u00e5 \u201cVanlige sp\u00f8rsm\u00e5l\u201d, kan du f\u00e5 generert sp\u00f8rsm\u00e5l og svar om konsepter fra\u00a0kildene:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*B7Hpg5LdNJQICQAurphMRQ.png\")
Du kan ogs\u00e5 sp\u00f8rre om \u201cStudieveiledning\u201d, som gir deg quizsp\u00f8rsm\u00e5l, som kan hjelpe deg \u00e5 huske materialet bedre. Om du arbeider med historie, kan du til og med f\u00e5 generert en tidslinje av\u00a0kildene.
\nDu kan ogs\u00e5 ta i bruk chat-funksjonen, i midtre fane, for \u00e5 stille spesifikke sp\u00f8rsm\u00e5l du lurer p\u00e5, med svar tilbake til\u00a0kildene.
\nNeste gang du vil l\u00e6re om et tema eller l\u00e6re noe bort, test ut hva podcasten spytter ut av materiale. Kanskje du finner en ny vinkling?
\nDet er gratis \u00e5 teste ut. Jeg fikk lagd 3\u20135 podcaster, f\u00f8r jeg fikk varsel om at jeg overskred dagskvota. \u00d8nsker du flere, m\u00e5 du forel\u00f8pig betale 259 kr per\u00a0m\u00e5ned.
\nFor \u00e5 se NotebookLM i action, anbefaler jeg deg bare \u00e5 \u00e5pne NotebookLM selv og begynne \u00e5 leke. Det er virkelig s\u00e5\u00a0enkelt.
\n\ud83d\udc9b Takk til Jens Andreas Huseby som tipset meg om NotebookLM. Og takk til Maria Skaaden som kom p\u00e5 ideen om \u00e5 bruke verkt\u00f8yet til \u00e5 teste ut en presentasjon.
\nTest ideene dine med en egenprodusert podcast\u200a\u2014\u200ai 3 enkle steg was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nUnder koronatiden eksploderte mengden podcaster. Tre \u00e5r senere kan du lage din egen i 3 enkle steg. Men hvorfor i all verden skal du gj\u00f8re det? Ikke for \u00e5 bli den neste Friminutt eller Radioresepsjonen. Men av to andre grunner: for \u00e5 l\u00e6re og \u00e5 l\u00e6re\u00a0bort.
\nOm du er som meg, kan tunge, lange tekster f\u00e5 luften til \u00e5 forsvinne ut av deg. En samtale, derimot, hvor du f\u00e5r h\u00f8re sp\u00f8rsm\u00e5l og det tilh\u00f8rende svaret, holder oppmerksomheten p\u00e5 en helt annen m\u00e5te. N\u00e5 kan du dra nytte av dette prinsippet for \u00e5 teste ideene dine. For med NotebookLM kan du lage en podcast basert p\u00e5 notatene du har\u200a\u2014\u200aenten det er en presentasjon eller bloggpost du holder p\u00e5 \u00e5 forberede.
\nI tre enkle steg kan du f\u00e5 generert en samtale som angriper temaet ditt fra ulike vinkler\u200a\u2014\u200aog du kan ogs\u00e5 spesifisere hvordan narrativet skal\u00a0v\u00e6re.
\nStegene tar bare 5 minutter. Og nevnte jeg at det var\u00a0gratis?
\nDu starter f\u00f8rst med \u00e5 g\u00e5 inn p\u00e5 NotebookLMs nettside (https://notebooklm.google.com/). Du logger inn med Google og oppretter en ny notatbok:
\nIdet du \u00e5pner notatboka, ser du tre\u00a0faner:
\nDisse tre delene\u00a0er:
\nFor \u00e5 lage en podcast trenger vi bare \u00e5 bry oss om kilder- og studio-fanen.
\nFor \u00e5 lage podcasten, trenger vertene noen kilder \u00e5 prate om. Det legger du til i venstre\u00a0fane:
\nSom du ser, kan du laste opp p\u00e5 mange ulike formater:
\nOm du \u00f8nsker \u00e5 utforske om en bloggpost eller presentasjon kan fungere, kan du legge inn disposisjonen i \u201cLim inn tekst\u201d. Om du har kilder du refererer til, som en Wikipedia-side eller kode-dokumentasjon, legg til disse som\u00a0lenker.
\nEt genialt lite triks er \u00e5 kaste disposisjonen inn i ChatGPT, s\u00e5 sp\u00f8rre om et utkast for en bloggpost. Da f\u00e5r du litt mer fyll og mulighet til \u00e5 redigere f\u00f8r du genererer podcasten.
\nF\u00f8r du genererer podcasten, anbefaler jeg deg ogs\u00e5 \u00e5 tilpasse podcasten.
\nDa f\u00e5r du en mindre generell podcast, og samtalen blir n\u00e6rere temaet du bryr deg om. Du kan spesifisere \u00e5 vektlegge visse kilder, som \u00e5 la podcasten utspille seg fra disposisjonen du har\u00a0oppgitt:
\nEtter et par minutter, f\u00e5r du en podcast p\u00e5 alt fra 5 til 30 minutter (avhengig av mengde kilder) om ditt favoritt-tema!
\nNysgjerrig p\u00e5 resultatet? Ta en lytt: https://notebooklm.google.com/notebook/c08e704b-7a5f-4fbf-892b-d09dd8b03225/audio
\nEtter \u00e5 ha generert podcasten, m\u00e5 du ikke bli sittende p\u00e5 PC-en for \u00e5 h\u00f8re den. Du kan g\u00e5 p\u00e5 inn p\u00e5 NotebookLM p\u00e5 mobilen, og h\u00f8re p\u00e5 lydklippet der, for det ligger p\u00e5 samme Google-konto.
\nDu kan ogs\u00e5 generere en offentlig lenke som du kan sende til deg selv eller venner. Bare \u00e5 trykke p\u00e5 \u201cDele\u201d-ikonet:
\nOg kopier delingslenken:
\nOm du ikke liker det du h\u00f8rte, kan du slette podcasten, tilpasse teksten og pr\u00f8ve p\u00e5\u00a0nytt.
\nOm du fortsatt er i researchmodus, kan du f\u00e5 kildene oppsummert ved noen enkle tastetrykk. Under \u201cLydoversikten\u201d, er en meny \u201cNotater\u201d. Ved \u00e5 klikke p\u00e5 \u201cVanlige sp\u00f8rsm\u00e5l\u201d, kan du f\u00e5 generert sp\u00f8rsm\u00e5l og svar om konsepter fra\u00a0kildene:
\nDu kan ogs\u00e5 sp\u00f8rre om \u201cStudieveiledning\u201d, som gir deg quizsp\u00f8rsm\u00e5l, som kan hjelpe deg \u00e5 huske materialet bedre. Om du arbeider med historie, kan du til og med f\u00e5 generert en tidslinje av\u00a0kildene.
\nDu kan ogs\u00e5 ta i bruk chat-funksjonen, i midtre fane, for \u00e5 stille spesifikke sp\u00f8rsm\u00e5l du lurer p\u00e5, med svar tilbake til\u00a0kildene.
\nNeste gang du vil l\u00e6re om et tema eller l\u00e6re noe bort, test ut hva podcasten spytter ut av materiale. Kanskje du finner en ny vinkling?
\nDet er gratis \u00e5 teste ut. Jeg fikk lagd 3\u20135 podcaster, f\u00f8r jeg fikk varsel om at jeg overskred dagskvota. \u00d8nsker du flere, m\u00e5 du forel\u00f8pig betale 259 kr per\u00a0m\u00e5ned.
\nFor \u00e5 se NotebookLM i action, anbefaler jeg deg bare \u00e5 \u00e5pne NotebookLM selv og begynne \u00e5 leke. Det er virkelig s\u00e5\u00a0enkelt.
\n\ud83d\udc9b Takk til Jens Andreas Huseby som tipset meg om NotebookLM. Og takk til Maria Skaaden som kom p\u00e5 ideen om \u00e5 bruke verkt\u00f8yet til \u00e5 teste ut en presentasjon.
\nTest ideene dine med en egenprodusert podcast\u200a\u2014\u200ai 3 enkle steg was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["technology","ai","learning"]},{"title":"<ForrigeUke uke=\u201d4\u201d \u00e5r=\u201d2025\u201d />","pubDate":"2025-01-28 07:48:19","link":"https://blogg.bekk.no/forrigeuke-uke-4-%C3%A5r-2025-f6c05aec8d82?source=rss-417bd6fed236------2","guid":"https://medium.com/p/f6c05aec8d82","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for ulest lesestoff og en litt for menneskelig bestevenn\u200a\u2014\u200aog 595 ting som skjedde i frontendverdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*io6px4feR2IIaF2Q\")
Tidligere denne m\u00e5neden introduserte NAVs designsystem darkmode til designsystemet, og Ken Aleksander Johansen skrev en fantastisk bloggpost om veien\u00a0dit.
\nF\u00f8rst, hvorfor skal du i det hele tatt bry deg om darkmode? Vel, det handler ikke kun om \u00e5 se ut som en 1337 h4x0r. Hvor mange ganger har du ikke v\u00e6rt p\u00e5 en m\u00f8rk nettside, for s\u00e5 \u00e5 trykke p\u00e5 en ny fane som har en ytelsestest av\u00a0lumen?
\nDarkmode handler om brukervennlighet. Brukere har ulik preferanse og ulik evne til \u00e5 lese m\u00f8rke eller lyse nettsider\u200a\u2014\u200as\u00e5 la brukerne\u00a0velge.
\nN\u00e5r det kommer til fargevalg, utbroderer Johansen hvorfor darkmode ikke kun inneb\u00e6rer \u00e5 invertere alle fargene. Et enkelt eksempel p\u00e5 dette er at, ikke overraskende, s\u00e5 fungerer skygger ganske d\u00e5rlig i\u00a0m\u00f8rket.
\nImplementeringen av darkmode var ikke bare fargevalg, men ogs\u00e5 en teknisk utfordring. Det krevde endring i struktur, mer spesifikt i hvordan tokensene var organisert. Underveis gikk teamet ogs\u00e5 fra et m\u00e5l om \u00e5 bygge gode l\u00f8sninger til brukerne deres, til \u00e5 hjelpe teamene deres med \u00e5 bygge l\u00f8sninger.
\nTa en titt p\u00e5 hvordan Johansen og teamet l\u00f8ste\u00a0dette:
\nDarkmode: Mer enn bare estetikk - aksel.nav.no
\nForrige uke ble en ny podcast for designsystemer lansert\u200a\u2014\u200a\u201cOn Theme: Design systems in depth\u201d. Og for \u00e5 sparke showet igang, var det ingen ringere enn \u201cAtomic design\u201d- legenden Brad Frost som dukket\u00a0opp.
\nEfficiency, respect, and the origins of design systems with Brad Frost #1 - On Theme podcast
\nI f\u00f8rste episode diskuterer vert Elyse Holladay og Frost om hvordan dagens designsystemer ble til\u200a\u2014\u200aog hvordan ordet \u201cdesignsystem\u201d i det hele tatt dukket\u00a0opp.
\nVi f\u00e5r et tilbakeblikk p\u00e5 da vi hadde egne nettsider for mobil, desktop og etterhvert iPad, og hvordan vi hadde egen kode for hvert stykke av nettsiden. Dette var en tid f\u00f8r ordet \u201ckomponent\u201d var\u00a0utbredt.
\nVi turer innom hvordan Bootstrap hjalp \u00e5 minske duplikat kode gjennom forh\u00e5ndsdefinerte CSS-klasser, men inns\u00e5 at kun gjenbruk av stiler ikke var nok. Vi h\u00f8rer hvordan React forbedret komponent-tankegangen, men ogs\u00e5 hvordan det splittet opp CSS vekk fra resten av koden, og hvordan dette fortsatt er en utfordring i dag. Vi h\u00f8rer ogs\u00e5 om hvordan \u201cdesignsystem\u201d var noe som levde som et photoshop-prosjekt som kun designere jobbet i, til det n\u00e5 ogs\u00e5 er noe utviklere forholder seg\u00a0til.
\nSelv om designsystemer har hindret mye dobbeltarbeid og gjort appene v\u00e5re mer konsistente, er det ogs\u00e5 noen slagsider ved disse fordelene. Designere mister mulighet for kreativitet, alle apper blir seende like ut og komponenter kan bli brukt feil. Ulempene nevnes kort i podcast-episoden, men for mer dybde kan jeg varmt anbefale Cam Worboys sitt foredrag \u201cThe broken promises of design systems\u201d:
\nhttps://medium.com/media/e6b59fe4d62488cfb8507815096fbbac/hrefF\u00f8r Storybook ble til, hadde mange bedrifter sine egne improviserte l\u00f8sninger for \u00e5 visualisere komponenter. Selv om Storybook ikke er perfekt, er det mye du f\u00e5r ut av boksen, med en rask, standard oversikt over komponentene dine og en plattform du lettere kan teste komponentene dine.
\nNylig ble versjon 8.5 lansert, og gj\u00f8r nettopp testing enklere. F\u00f8r hadde du UU-testing per story, men n\u00e5 kan du kj\u00f8re tester p\u00e5 tvers i prosjektet, og lettere avdekke om komponentene dine er kosher. Dette gjelder ogs\u00e5 vanlige\u00a0tester.
\nDet har ogs\u00e5 kommet ca. 100 andre forbedringer i versjon 8.5, som du kan ta en titt p\u00e5\u00a0her:
\n\nDet var alt for denne gang. Ha en riktig god uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d4\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for ulest lesestoff og en litt for menneskelig bestevenn\u200a\u2014\u200aog 595 ting som skjedde i frontendverdenen!
\nTidligere denne m\u00e5neden introduserte NAVs designsystem darkmode til designsystemet, og Ken Aleksander Johansen skrev en fantastisk bloggpost om veien\u00a0dit.
\nF\u00f8rst, hvorfor skal du i det hele tatt bry deg om darkmode? Vel, det handler ikke kun om \u00e5 se ut som en 1337 h4x0r. Hvor mange ganger har du ikke v\u00e6rt p\u00e5 en m\u00f8rk nettside, for s\u00e5 \u00e5 trykke p\u00e5 en ny fane som har en ytelsestest av\u00a0lumen?
\nDarkmode handler om brukervennlighet. Brukere har ulik preferanse og ulik evne til \u00e5 lese m\u00f8rke eller lyse nettsider\u200a\u2014\u200as\u00e5 la brukerne\u00a0velge.
\nN\u00e5r det kommer til fargevalg, utbroderer Johansen hvorfor darkmode ikke kun inneb\u00e6rer \u00e5 invertere alle fargene. Et enkelt eksempel p\u00e5 dette er at, ikke overraskende, s\u00e5 fungerer skygger ganske d\u00e5rlig i\u00a0m\u00f8rket.
\nImplementeringen av darkmode var ikke bare fargevalg, men ogs\u00e5 en teknisk utfordring. Det krevde endring i struktur, mer spesifikt i hvordan tokensene var organisert. Underveis gikk teamet ogs\u00e5 fra et m\u00e5l om \u00e5 bygge gode l\u00f8sninger til brukerne deres, til \u00e5 hjelpe teamene deres med \u00e5 bygge l\u00f8sninger.
\nTa en titt p\u00e5 hvordan Johansen og teamet l\u00f8ste\u00a0dette:
\nDarkmode: Mer enn bare estetikk - aksel.nav.no
\nForrige uke ble en ny podcast for designsystemer lansert\u200a\u2014\u200a\u201cOn Theme: Design systems in depth\u201d. Og for \u00e5 sparke showet igang, var det ingen ringere enn \u201cAtomic design\u201d- legenden Brad Frost som dukket\u00a0opp.
\nEfficiency, respect, and the origins of design systems with Brad Frost #1 - On Theme podcast
\nI f\u00f8rste episode diskuterer vert Elyse Holladay og Frost om hvordan dagens designsystemer ble til\u200a\u2014\u200aog hvordan ordet \u201cdesignsystem\u201d i det hele tatt dukket\u00a0opp.
\nVi f\u00e5r et tilbakeblikk p\u00e5 da vi hadde egne nettsider for mobil, desktop og etterhvert iPad, og hvordan vi hadde egen kode for hvert stykke av nettsiden. Dette var en tid f\u00f8r ordet \u201ckomponent\u201d var\u00a0utbredt.
\nVi turer innom hvordan Bootstrap hjalp \u00e5 minske duplikat kode gjennom forh\u00e5ndsdefinerte CSS-klasser, men inns\u00e5 at kun gjenbruk av stiler ikke var nok. Vi h\u00f8rer hvordan React forbedret komponent-tankegangen, men ogs\u00e5 hvordan det splittet opp CSS vekk fra resten av koden, og hvordan dette fortsatt er en utfordring i dag. Vi h\u00f8rer ogs\u00e5 om hvordan \u201cdesignsystem\u201d var noe som levde som et photoshop-prosjekt som kun designere jobbet i, til det n\u00e5 ogs\u00e5 er noe utviklere forholder seg\u00a0til.
\nSelv om designsystemer har hindret mye dobbeltarbeid og gjort appene v\u00e5re mer konsistente, er det ogs\u00e5 noen slagsider ved disse fordelene. Designere mister mulighet for kreativitet, alle apper blir seende like ut og komponenter kan bli brukt feil. Ulempene nevnes kort i podcast-episoden, men for mer dybde kan jeg varmt anbefale Cam Worboys sitt foredrag \u201cThe broken promises of design systems\u201d:
\nhttps://medium.com/media/e6b59fe4d62488cfb8507815096fbbac/hrefF\u00f8r Storybook ble til, hadde mange bedrifter sine egne improviserte l\u00f8sninger for \u00e5 visualisere komponenter. Selv om Storybook ikke er perfekt, er det mye du f\u00e5r ut av boksen, med en rask, standard oversikt over komponentene dine og en plattform du lettere kan teste komponentene dine.
\nNylig ble versjon 8.5 lansert, og gj\u00f8r nettopp testing enklere. F\u00f8r hadde du UU-testing per story, men n\u00e5 kan du kj\u00f8re tester p\u00e5 tvers i prosjektet, og lettere avdekke om komponentene dine er kosher. Dette gjelder ogs\u00e5 vanlige\u00a0tester.
\nDet har ogs\u00e5 kommet ca. 100 andre forbedringer i versjon 8.5, som du kan ta en titt p\u00e5\u00a0her:
\n\nDet var alt for denne gang. Ha en riktig god uke!\u00a0\ud83d\udc4b
\n<ForrigeUke uke=\u201d4\u201d \u00e5r=\u201d2025\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["forrigeuke","react","frontend","javascript","technology"]},{"title":"<ForrigeUke uke=\u201d49\u201d \u00e5r=\u201d2024\u201d />","pubDate":"2024-12-10 08:44:43","link":"https://blogg.bekk.no/forrigeuke-uke-49-%C3%A5r-2024-60f941e61076?source=rss-417bd6fed236------2","guid":"https://medium.com/p/60f941e61076","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for kodekunst og at Tim f\u00e5r kull\u200a\u2014\u200aog 1040 ting skjedde i frontend-verdenen!
\nWow. React 19 er ute, og det hele f\u00f8les antiklimatisk etter \u00e5 ha snakket om alle de nye funksjonene i s\u00e5 lang tid. Vi har prekt om hvordan React f\u00e5r en rekke nye hooks som kan forenkle ting, og samtidig hvordan frontend dyttes mot serveren, og at vi m\u00e5 l\u00e6re oss nye m\u00e5ter \u00e5 gj\u00f8re ting p\u00e5. N\u00e5 er versjonen offisielt ute i en stabil form, s\u00e5 n\u00e5 har vi plutselig muligheten til \u00e5 bruke\u00a0det.
\n![\"\"](\"https://cdn-images-1.medium.com/max/750/1*goO5FBRJp0X6n9WK5yn9PQ.jpeg\")
Istedenfor \u00e5 gjenta alle de kule, nye funksjonalitetene du kan ta i bruk, skal jeg gj\u00f8re noe helt annet. \u00c5 migrere over til ny versjon av noe som helst kan v\u00e6re ganske terskel, s\u00e6rlig i en lang liste av andre oppgaver \u00e5 gj\u00f8re. Etter \u00e5 ha lest oppgraderingsguiden, vil jeg heller oppsummere stegene for deg i fire enkle\u00a0punkter:
\nSteg 1: Oppgrader versjon i package.json
\nJeg skulle \u00f8nske jeg kunne si til deg det bare var \u00e5 bumpe Reacts versjon til 19, men slik er det oftest\u00a0ikke.
\n![\"\"](\"https://cdn-images-1.medium.com/max/480/1*0PNAjmqa-mjBAlQsISBhUg.png\")
I mitt tilfelle var flere av de andre pakkene i prosjektet avhengig av en viss React versjon. S\u00e5 etter \u00e5 ha installert React 19, fikk jeg \u00f8ye p\u00e5 en rekke pakker som ogs\u00e5 trenger oppgradering, som TanStack\u00a0Query*:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*I1jI_McEsrU7y6h2FXFhFA.png\")
Noen av pakkene hadde ikke noen nyere versjon, og st\u00f8ttet enda ikke React 19. Det er ikke veldig overraskende, siden nyeste versjon kom for bare fem dager\u00a0siden.
\nDermed kan andre pakker v\u00e6re en blokkade for deg som vil over til React 19. Men etter at du har oppgradert avhengighetene dine, eller byttet dem ut med alternativer, kan du g\u00e5 videre til neste\u00a0seg.
\nSteg 2: La codemod gj\u00f8re jobben for\u00a0deg
\ncodemod er et verkt\u00f8y som tar grovarbeidet ved bytting av kodesnutter, som \u00e5 bytte fra n\u00e5 deprecated defaultProps til \u00e5 heller bruke default-parametere.
\nEtter \u00e5 ha kj\u00f8rt React-codemod-scriptet, skal mange av filene ha blitt omskrevet til st\u00f8ttede skrivem\u00e5ter.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*tB1qGTHNwndr3_SFqWanhw.png\")
Steg 3: Fjern deprecated funksjonalitet
\ncodemod gj\u00f8r mye, men fikser ikke all funksjonalitet som er deprecated. Om du kommer fra React 18.3.0, har du nok fjernet funksjonalitet som ikke lenger ville bli st\u00f8ttet i React 19 allerede. Ta likevel en titt p\u00e5 deprecation-notatene om du kjenner igjen noe fra kodebasen din.
\nSteg 4: Sjekk om applikasjonen kj\u00f8rer
\nEtter disse endringene, vil applikasjonen kj\u00f8re?
\nStart med npm build for \u00e5 sjekke etter byggfeil og kj\u00f8r testene. Om alt er gr\u00f8nt og skj\u00f8nt, fyr opp applikasjonen ogs\u00e5. Om du heller ikke her ser varsler i consolen, vil jeg bare gratulere. N\u00e5 kan du endelig ikke bare lese om all den nye funksjonaliten React 19 gir, men ogs\u00e5 ta den i\u00a0bruk!
\nDen lettere og lettere sjokoladekalenderen min sier at jula er rett rundt hj\u00f8rnet. Det fins mange julekalendere der ute, s\u00e5 jeg vil anbefale noen til deg som er spesielt interessert i frontend.
\nHTMhell er for deg som vil ha drypp av HTML- tips og triks, som igjen kan hjelpe deg \u00e5 skrive b\u00e5de universelt utformet kode og lage brukervennlige l\u00f8sninger. I de f\u00f8rste to lukene finner du hvilken alt-tag som er rett for en logo og hvordan du kan bruke \u201cautofocus\u201d i et innloggingsskjema.
\nOm du ogs\u00e5 vil style HTML-en du produserer, kan jeg anbefale \u00e5 ta en titt p\u00e5 cssadventcalendar. Der f\u00e5r du en kort forklaring p\u00e5 en CSS-regel hver dag. Om du har lyst til \u00e5 doble antall CSS-regler per dag, kan jeg ogs\u00e5 tipse om at kollega Einar dytter ut daglige CSS-regler i Bekk Christmas. G\u00e5rsdagen kunne by p\u00e5 en kul funksjonalitet hvor du kan f\u00e5 scrolling til \u00e5 skje seksjonsvis.
\nOm 2025 er \u00e5ret du vil makse lighthouse-scoren p\u00e5 nettsiden din, er det verdt \u00e5 ta en titt p\u00e5 Web Performance-kalenderen. Der kan du blant annet lese om hvordan JavaScript bare har \u00e9n hoved-tr\u00e5d, men likevel h\u00e5ndterer flere oppgaver samtidig.
\nOm du har et vannfall av datahentinger, tipper jeg lighthouse-sk\u00e5ren g\u00e5r ned. Det er noe vi har snakket om tidligere i ForrigeUke, og hvordan rammeverk kan hjelpe p\u00e5\u00a0dette.
\nEn m\u00e5te \u00e5 unng\u00e5 vannfall-effekten p\u00e5, er \u00e5 ikke gj\u00f8re all datahentingen sekvensielt, men vente til alt er\u00a0klart:
\nconst Post = async ({ postId }: { postId: string }) => {
const postPromise = getPost(postId);
const commentsPromise = getComments(postId);
// \ud83d\udc47 Venter til begge fetch-ene er ferdige
const [post, comments] = await Promise.all([
postPromise,
commentsPromise,
]);\nRobin Wieruch skriver om hvordan du b\u00f8r implementere disse datahentings-m\u00f8nstrene. Ta en\u00a0titt:
\n\n*jammen fikk jeg lurt inn TanStack Query i denne posten\u00a0ogs\u00e5
\nDet var alt for denne gang. Ha en fin\u00a0uke!
\n<ForrigeUke uke=\u201d49\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for kodekunst og at Tim f\u00e5r kull\u200a\u2014\u200aog 1040 ting skjedde i frontend-verdenen!
\nWow. React 19 er ute, og det hele f\u00f8les antiklimatisk etter \u00e5 ha snakket om alle de nye funksjonene i s\u00e5 lang tid. Vi har prekt om hvordan React f\u00e5r en rekke nye hooks som kan forenkle ting, og samtidig hvordan frontend dyttes mot serveren, og at vi m\u00e5 l\u00e6re oss nye m\u00e5ter \u00e5 gj\u00f8re ting p\u00e5. N\u00e5 er versjonen offisielt ute i en stabil form, s\u00e5 n\u00e5 har vi plutselig muligheten til \u00e5 bruke\u00a0det.
\nIstedenfor \u00e5 gjenta alle de kule, nye funksjonalitetene du kan ta i bruk, skal jeg gj\u00f8re noe helt annet. \u00c5 migrere over til ny versjon av noe som helst kan v\u00e6re ganske terskel, s\u00e6rlig i en lang liste av andre oppgaver \u00e5 gj\u00f8re. Etter \u00e5 ha lest oppgraderingsguiden, vil jeg heller oppsummere stegene for deg i fire enkle\u00a0punkter:
\nSteg 1: Oppgrader versjon i package.json
\nJeg skulle \u00f8nske jeg kunne si til deg det bare var \u00e5 bumpe Reacts versjon til 19, men slik er det oftest\u00a0ikke.
\nI mitt tilfelle var flere av de andre pakkene i prosjektet avhengig av en viss React versjon. S\u00e5 etter \u00e5 ha installert React 19, fikk jeg \u00f8ye p\u00e5 en rekke pakker som ogs\u00e5 trenger oppgradering, som TanStack\u00a0Query*:
\nNoen av pakkene hadde ikke noen nyere versjon, og st\u00f8ttet enda ikke React 19. Det er ikke veldig overraskende, siden nyeste versjon kom for bare fem dager\u00a0siden.
\nDermed kan andre pakker v\u00e6re en blokkade for deg som vil over til React 19. Men etter at du har oppgradert avhengighetene dine, eller byttet dem ut med alternativer, kan du g\u00e5 videre til neste\u00a0seg.
\nSteg 2: La codemod gj\u00f8re jobben for\u00a0deg
\ncodemod er et verkt\u00f8y som tar grovarbeidet ved bytting av kodesnutter, som \u00e5 bytte fra n\u00e5 deprecated defaultProps til \u00e5 heller bruke default-parametere.
\nEtter \u00e5 ha kj\u00f8rt React-codemod-scriptet, skal mange av filene ha blitt omskrevet til st\u00f8ttede skrivem\u00e5ter.
\nSteg 3: Fjern deprecated funksjonalitet
\ncodemod gj\u00f8r mye, men fikser ikke all funksjonalitet som er deprecated. Om du kommer fra React 18.3.0, har du nok fjernet funksjonalitet som ikke lenger ville bli st\u00f8ttet i React 19 allerede. Ta likevel en titt p\u00e5 deprecation-notatene om du kjenner igjen noe fra kodebasen din.
\nSteg 4: Sjekk om applikasjonen kj\u00f8rer
\nEtter disse endringene, vil applikasjonen kj\u00f8re?
\nStart med npm build for \u00e5 sjekke etter byggfeil og kj\u00f8r testene. Om alt er gr\u00f8nt og skj\u00f8nt, fyr opp applikasjonen ogs\u00e5. Om du heller ikke her ser varsler i consolen, vil jeg bare gratulere. N\u00e5 kan du endelig ikke bare lese om all den nye funksjonaliten React 19 gir, men ogs\u00e5 ta den i\u00a0bruk!
\nDen lettere og lettere sjokoladekalenderen min sier at jula er rett rundt hj\u00f8rnet. Det fins mange julekalendere der ute, s\u00e5 jeg vil anbefale noen til deg som er spesielt interessert i frontend.
\nHTMhell er for deg som vil ha drypp av HTML- tips og triks, som igjen kan hjelpe deg \u00e5 skrive b\u00e5de universelt utformet kode og lage brukervennlige l\u00f8sninger. I de f\u00f8rste to lukene finner du hvilken alt-tag som er rett for en logo og hvordan du kan bruke \u201cautofocus\u201d i et innloggingsskjema.
\nOm du ogs\u00e5 vil style HTML-en du produserer, kan jeg anbefale \u00e5 ta en titt p\u00e5 cssadventcalendar. Der f\u00e5r du en kort forklaring p\u00e5 en CSS-regel hver dag. Om du har lyst til \u00e5 doble antall CSS-regler per dag, kan jeg ogs\u00e5 tipse om at kollega Einar dytter ut daglige CSS-regler i Bekk Christmas. G\u00e5rsdagen kunne by p\u00e5 en kul funksjonalitet hvor du kan f\u00e5 scrolling til \u00e5 skje seksjonsvis.
\nOm 2025 er \u00e5ret du vil makse lighthouse-scoren p\u00e5 nettsiden din, er det verdt \u00e5 ta en titt p\u00e5 Web Performance-kalenderen. Der kan du blant annet lese om hvordan JavaScript bare har \u00e9n hoved-tr\u00e5d, men likevel h\u00e5ndterer flere oppgaver samtidig.
\nOm du har et vannfall av datahentinger, tipper jeg lighthouse-sk\u00e5ren g\u00e5r ned. Det er noe vi har snakket om tidligere i ForrigeUke, og hvordan rammeverk kan hjelpe p\u00e5\u00a0dette.
\nEn m\u00e5te \u00e5 unng\u00e5 vannfall-effekten p\u00e5, er \u00e5 ikke gj\u00f8re all datahentingen sekvensielt, men vente til alt er\u00a0klart:
\nconst Post = async ({ postId }: { postId: string }) => {
const postPromise = getPost(postId);
const commentsPromise = getComments(postId);
// \ud83d\udc47 Venter til begge fetch-ene er ferdige
const [post, comments] = await Promise.all([
postPromise,
commentsPromise,
]);\nRobin Wieruch skriver om hvordan du b\u00f8r implementere disse datahentings-m\u00f8nstrene. Ta en\u00a0titt:
\n\n*jammen fikk jeg lurt inn TanStack Query i denne posten\u00a0ogs\u00e5
\nDet var alt for denne gang. Ha en fin\u00a0uke!
\n<ForrigeUke uke=\u201d49\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["technology","react","forrigeuke","frontend","javascript"]},{"title":"<ForrigeUke uke=\u201d48\u201d \u00e5r=\u201d2024\u201d />","pubDate":"2024-12-03 09:20:04","link":"https://blogg.bekk.no/forrigeuke-uke-48-%C3%A5r-2024-31b7ded2c1e5?source=rss-417bd6fed236------2","guid":"https://medium.com/p/31b7ded2c1e5","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for teknisk arv og overreaksjoner\u200a\u2014\u200aog 737 ting som skjedde i frontend-verdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*jML4lTgTeac1jXFm\")
Vi har lenge visst at React Router 7 markerer sammensl\u00e5ingen av Remix og React Router, og forrige uke ble denne versjonen sluppet! S\u00e5 hva betyr dette i\u00a0praksis?
\nN\u00e5r du n\u00e5 starter et nytt prosjekt, kan du velge om du vil bruke React Router som et rammeverk eller kun som et bibliotek.
\n![\"\"](\"https://cdn-images-1.medium.com/max/638/1*moavec_PpiMWPPoHVxWccw.png\")
Om du bruker React Router kun som et bibliotek, er det et enkelt bibliotek for routing, slik du kjenner det fra f\u00f8r. Det matcher URL-er med riktig komponent, lar deg hente ut URL-data og navigere rundt i appen. Siden du bare f\u00e5r routing, m\u00e5 du selv gj\u00f8re valg for andre ting appen trenger, som \u00e5 bruke TanStack Query for datahenting.
\nOm du bruker React Router som et rammeverk, f\u00e5r du en del funksjonalitet ut fra boksen, som kodesplitting og lettere \u00e5 velge blant rendringsstrategier (SSR, SPA, SSG). Du f\u00e5r ogs\u00e5 et sett med konvensjoner, som at du m\u00e5 sette opp ruter p\u00e5 en viss m\u00e5te og at du gjerne bruker loaders for \u00e5 hente\u00a0data.
\nNoe som har manglet i React Router, er typesikring\u200a\u2014\u200anoe som ogs\u00e5 var en hovedmotivasjon for Tanner Linsey \u00e5 lage TanStack Router. N\u00e5 har typesikker routing ogs\u00e5 kommet til React Router, ogs\u00e5 med typesikring for loader-data og\u00a0actions.
\nFor \u00e5 gj\u00f8re oppgraderingen, er det variabelt hvor mye arbeid det er, utifra hvor du kommer fra. Om du tidligere har brukt React Router 6 og vil til nyeste versjon, er endringen enkelthen bare \u00e5 oppdatere en\u00a0import:
\n-import { useLocation } from \"react-router-dom\";
+import { useLocation } from \"react-router\";\nFor \u00e5 g\u00e5 fra Remix v2 til R7 er det mer arbeid. Du setter ikke lenger Remix-konfigurasjon, som SSR, via Remix-Vite-pluginen\u200a\u2014\u200amen gjennom filen react-router.config. Vite-pluginen du n\u00e5 vil bruke er React Router. S\u00e5 er det en del typesetting du m\u00e5 oppdatere. Se guide i\u00a0docs.
\nReact Router har ogs\u00e5 lagd en guide for deg som har brukt React Router 6 og vil n\u00e5 bruke React Router som et rammeverk.
\nMed alle disse endringene, er det verdt\u00a0det?
\nYouTuber Alam Tuzlak har en hjelpsom video for \u00e5 vurdere om du b\u00f8r oppgradere. Overgangen fra React Router 6 til React Router 7 som bibliotek er veldig enkel. Det fins ogs\u00e5 codemods for \u00e5 gj\u00f8re dette\u00a0raskt.
\nFor overgangen fra Remix til React Router 7, m\u00e5 du vurdere din situasjon. Det eneste nye for Remix v2 til React Router 7 er SSG og typesikker routing. S\u00e5 om du ikke trenger dette i prosjektet ditt n\u00e5, kanskje du ikke trenger \u00e5 flytte over med engang. Du kan dr\u00f8ye overgangen til mer funksjonalitet er lagt til, som React Serverkomponenter og middleware. Unntaket er om du skal til \u00e5 starte en ny applikasjon eller nettopp har starta. Da kan det v\u00e6re verdt \u00e5 migrere over med en gang, s\u00e5 du slipper merarbeid senere.
\nSe videoen\u00a0her:
\nhttps://medium.com/media/3965c8e8d9ff654107e33981d5b3d6b7/hrefVite er det mest elskede biblioteket, og er n\u00e5 ute i versjon 6! Vite er allerede standardvalget for mange JavaScript-rammeverk, s\u00e5 hva endres egentlig med denne nye versjonen?
\nFor den gjengse utvikler er det f\u00e5 nye ting. Men for rammeverk- utviklere har Vite blitt mer fleksibelt med Environment API.
\nEnvironment API gj\u00f8r det mulig for rammeverksutviklere \u00e5 st\u00f8tte runtime-milj\u00f8er som Deno og Bun, samtidig som de kan h\u00e5ndtere eldre Node.js-versjoner.
\nNy funksjonalitet gj\u00f8r bundling mer kompleks. Tidligere hadde du \u00e9n bundle for klientkoden og \u00e9n for SSR, men st\u00f8tte for React Server Components og middleware krever flere bundles, noe Environment API forenkler.
\nDu kan lese mer om Environment API\u00a0her:
\nIncreasing Vite's potential with the Environment API
\nEvan You, mannen bak Vite, hadde nylig en keynote og delte sine tanker om fremtiden til Vite\u200a\u2014\u200aog den er\u00a0rask.
\nVite er en bundler, som igjen er bygd opp\u00e5 tre komponenter: esbuild, rollup og\u00a0SWC:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*93oAMhc9z93FOA8950fuTA.png\")
Vite bruker alts\u00e5 to ulike bundlere. En for dev-milj\u00f8, og en for produksjonsmilj\u00f8. Dette fungerer bra for mange prosjekter, men for veldig store prosjekter, kan byggingen v\u00e6re treg. Siden det er to ulike bundlere, kan det ogs\u00e5 oppst\u00e5 forskjeller i dev- og prod- bundelen, som skaper feil du f\u00f8rst oppdager i\u00a0prod.
\nYou jobber derfor med \u00e5 g\u00e5 fra tre komponenter til ett verkt\u00f8y, og verkt\u00f8yet kaller han rolldown:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*tNSkMn0kD3SnJDH05jM9XA.png\")
Rolldown er skrevet i Rust. Ved \u00e5 ha ett verkt\u00f8y, h\u00e5per You \u00e5 gj\u00f8re byggeprosessen enklere og med f\u00e6rre feil. Og ikke minst ser verkt\u00f8yet ekstremt kjapp ut. Fra en case-study fikk teamet et allerede optimalisert bygg p\u00e5 8,5 sekunder ned til 1,11 sekunder ved \u00e5 bruke rolldown:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*V4ZgiS0ms_Q9n9VAO4yF4A.png\")
Siden mange JavaScript-rammeverk er bygd p\u00e5 Vite, ser fremtiden for oss ganske kjapp ut. Det blir interessant \u00e5 se hvordan dette p\u00e5virker Next.js sin Turbopack.
\nSe You's keynote\u00a0her:
\nhttps://medium.com/media/905769d078e7d05d90599b0b75610c9c/hrefDet var alt for denne gang\u200a\u2014\u200asees neste\u00a0uke!
\n<ForrigeUke uke=\u201d48\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for teknisk arv og overreaksjoner\u200a\u2014\u200aog 737 ting som skjedde i frontend-verdenen!
\nVi har lenge visst at React Router 7 markerer sammensl\u00e5ingen av Remix og React Router, og forrige uke ble denne versjonen sluppet! S\u00e5 hva betyr dette i\u00a0praksis?
\nN\u00e5r du n\u00e5 starter et nytt prosjekt, kan du velge om du vil bruke React Router som et rammeverk eller kun som et bibliotek.
\nOm du bruker React Router kun som et bibliotek, er det et enkelt bibliotek for routing, slik du kjenner det fra f\u00f8r. Det matcher URL-er med riktig komponent, lar deg hente ut URL-data og navigere rundt i appen. Siden du bare f\u00e5r routing, m\u00e5 du selv gj\u00f8re valg for andre ting appen trenger, som \u00e5 bruke TanStack Query for datahenting.
\nOm du bruker React Router som et rammeverk, f\u00e5r du en del funksjonalitet ut fra boksen, som kodesplitting og lettere \u00e5 velge blant rendringsstrategier (SSR, SPA, SSG). Du f\u00e5r ogs\u00e5 et sett med konvensjoner, som at du m\u00e5 sette opp ruter p\u00e5 en viss m\u00e5te og at du gjerne bruker loaders for \u00e5 hente\u00a0data.
\nNoe som har manglet i React Router, er typesikring\u200a\u2014\u200anoe som ogs\u00e5 var en hovedmotivasjon for Tanner Linsey \u00e5 lage TanStack Router. N\u00e5 har typesikker routing ogs\u00e5 kommet til React Router, ogs\u00e5 med typesikring for loader-data og\u00a0actions.
\nFor \u00e5 gj\u00f8re oppgraderingen, er det variabelt hvor mye arbeid det er, utifra hvor du kommer fra. Om du tidligere har brukt React Router 6 og vil til nyeste versjon, er endringen enkelthen bare \u00e5 oppdatere en\u00a0import:
\n-import { useLocation } from \"react-router-dom\";
+import { useLocation } from \"react-router\";\nFor \u00e5 g\u00e5 fra Remix v2 til R7 er det mer arbeid. Du setter ikke lenger Remix-konfigurasjon, som SSR, via Remix-Vite-pluginen\u200a\u2014\u200amen gjennom filen react-router.config. Vite-pluginen du n\u00e5 vil bruke er React Router. S\u00e5 er det en del typesetting du m\u00e5 oppdatere. Se guide i\u00a0docs.
\nReact Router har ogs\u00e5 lagd en guide for deg som har brukt React Router 6 og vil n\u00e5 bruke React Router som et rammeverk.
\nMed alle disse endringene, er det verdt\u00a0det?
\nYouTuber Alam Tuzlak har en hjelpsom video for \u00e5 vurdere om du b\u00f8r oppgradere. Overgangen fra React Router 6 til React Router 7 som bibliotek er veldig enkel. Det fins ogs\u00e5 codemods for \u00e5 gj\u00f8re dette\u00a0raskt.
\nFor overgangen fra Remix til React Router 7, m\u00e5 du vurdere din situasjon. Det eneste nye for Remix v2 til React Router 7 er SSG og typesikker routing. S\u00e5 om du ikke trenger dette i prosjektet ditt n\u00e5, kanskje du ikke trenger \u00e5 flytte over med engang. Du kan dr\u00f8ye overgangen til mer funksjonalitet er lagt til, som React Serverkomponenter og middleware. Unntaket er om du skal til \u00e5 starte en ny applikasjon eller nettopp har starta. Da kan det v\u00e6re verdt \u00e5 migrere over med en gang, s\u00e5 du slipper merarbeid senere.
\nSe videoen\u00a0her:
\nhttps://medium.com/media/3965c8e8d9ff654107e33981d5b3d6b7/hrefVite er det mest elskede biblioteket, og er n\u00e5 ute i versjon 6! Vite er allerede standardvalget for mange JavaScript-rammeverk, s\u00e5 hva endres egentlig med denne nye versjonen?
\nFor den gjengse utvikler er det f\u00e5 nye ting. Men for rammeverk- utviklere har Vite blitt mer fleksibelt med Environment API.
\nEnvironment API gj\u00f8r det mulig for rammeverksutviklere \u00e5 st\u00f8tte runtime-milj\u00f8er som Deno og Bun, samtidig som de kan h\u00e5ndtere eldre Node.js-versjoner.
\nNy funksjonalitet gj\u00f8r bundling mer kompleks. Tidligere hadde du \u00e9n bundle for klientkoden og \u00e9n for SSR, men st\u00f8tte for React Server Components og middleware krever flere bundles, noe Environment API forenkler.
\nDu kan lese mer om Environment API\u00a0her:
\nIncreasing Vite's potential with the Environment API
\nEvan You, mannen bak Vite, hadde nylig en keynote og delte sine tanker om fremtiden til Vite\u200a\u2014\u200aog den er\u00a0rask.
\nVite er en bundler, som igjen er bygd opp\u00e5 tre komponenter: esbuild, rollup og\u00a0SWC:
\nVite bruker alts\u00e5 to ulike bundlere. En for dev-milj\u00f8, og en for produksjonsmilj\u00f8. Dette fungerer bra for mange prosjekter, men for veldig store prosjekter, kan byggingen v\u00e6re treg. Siden det er to ulike bundlere, kan det ogs\u00e5 oppst\u00e5 forskjeller i dev- og prod- bundelen, som skaper feil du f\u00f8rst oppdager i\u00a0prod.
\nYou jobber derfor med \u00e5 g\u00e5 fra tre komponenter til ett verkt\u00f8y, og verkt\u00f8yet kaller han rolldown:
\nRolldown er skrevet i Rust. Ved \u00e5 ha ett verkt\u00f8y, h\u00e5per You \u00e5 gj\u00f8re byggeprosessen enklere og med f\u00e6rre feil. Og ikke minst ser verkt\u00f8yet ekstremt kjapp ut. Fra en case-study fikk teamet et allerede optimalisert bygg p\u00e5 8,5 sekunder ned til 1,11 sekunder ved \u00e5 bruke rolldown:
\nSiden mange JavaScript-rammeverk er bygd p\u00e5 Vite, ser fremtiden for oss ganske kjapp ut. Det blir interessant \u00e5 se hvordan dette p\u00e5virker Next.js sin Turbopack.
\nSe You's keynote\u00a0her:
\nhttps://medium.com/media/905769d078e7d05d90599b0b75610c9c/hrefDet var alt for denne gang\u200a\u2014\u200asees neste\u00a0uke!
\n<ForrigeUke uke=\u201d48\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["forrigeuke","react","frontend","javascript","technology"]},{"title":"<ForrigeUke uke=\u201d47\u201d \u00e5r=\u201d2024\u201d />","pubDate":"2024-11-26 08:14:59","link":"https://blogg.bekk.no/forrigeuke-uke-47-%C3%A5r-2024-60d5b76f8316?source=rss-417bd6fed236------2","guid":"https://medium.com/p/60d5b76f8316","author":"Marcus Haaland","thumbnail":"","description":"\nDette var uka for noen siste ord, balanse i universet og a/b-testing\u2014 og 2412 ting som skjedde i frontend-verdenen!
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*_iZuiTgU-GNIxuwp\")
En av mine favoritt-React-pedagoger p\u00e5 YouTube, Cosden Solutions, hadde nettopp et samarbeid med norske Aurora Scharff. Her snakket de om fremtiden til skjemaer.
\nReact trender mot serveren. React 19 introduserer nye hooks som useActionState, og du kan allerede se server-funksjoner i Next.js. Hvordan ser React-serverkode ut i forhold til react-klientkode, og hvordan p\u00e5virker dette brukeren?
\nLa oss f\u00f8rst se p\u00e5 forskjellene i kode. Et popul\u00e6rt bibliotek for skjemaer p\u00e5 klientsiden er React Hook Form. Det gir deg en del funksjonalitet, som \u00e5 lettere h\u00e5ndtere tilstand og feilmeldinger, med f\u00e6rre linjer\u00a0kode.
\nHer har du et eksempel p\u00e5 skjema, hvor en bruker kan skrive inn et\u00a0navn:
\n\"use client\"\n
export default function App() {
const {
register,
handleSubmit,
// \ud83d\udc47 Vi f\u00e5r error- og loading state fra hooken
formState: { errors, isSubmitting },
} = useForm<Inputs>()
// \ud83d\udc47 Vi registrerer input-ene, og data sendes via onSubmit
const onSubmit: SubmitHandler<Inputs> = (data) => submitData(data)
return (
<form onSubmit={handleSubmit(onSubmit)}>
<label>First Name</label>
<input {...register(\"firstName\")} />
Det er ikke noe galt i \u00e5 lage et skjema p\u00e5 denne m\u00e5ten. Men det kan v\u00e6re nyttig for deg \u00e5 vite noen svakheter ved et klientside skjema.
\nEt klientside skjema er avhengig av JavaScript. Det kan v\u00e6re flere grunner til at JavaScripten ikke er ferdig prosessert i klienten, enten av tregt nett eller en treg prosessor. Om du noen gang har begynt \u00e5 skrive i et tekstfelt, for s\u00e5 at teksten plutselig forsvinner, kan det v\u00e6re at JavaScripten har brukt tid p\u00e5 \u00e5 laste inn. S\u00e5 frustrerende!
\nSiden et klientside skjema kan gi noen d\u00e5rlige brukeropplevelser, hvordan kan skjema som kaller en serverfunksjon forbedre\u00a0dette?
\nLa oss se p\u00e5 koden, med den nye useActionState-hooken, som tar imot en server-funksjon:
\n// actions.ts\n
\"use server\" // \ud83d\udc48 Server-funksjoner rendres p\u00e5 serveren
export async submitData() {
// ...
}
// App.tsx
// \ud83d\udc47 Hooken brukes i klienten, for \u00e5 f\u00e5 med interaktivitet, som loading
\"use client\"
import { submitData } from \"./actions.ts\"
export default function App() {
// \ud83d\udc47 Vi f\u00e5r data fra skjema, action for skjema og loading-state fra hooken
const [state, formAction, isPending] = useActionState(submitData, {
error: undefined,
success: false
})
return (
// \ud83d\udc47 Denne gang bruker vi action, ikke onSubmit
<form action={formAction}>
<label>First Name</label>
<input name=\"firstName\" />
Denne gangen sender vi med skjemadata via nettleserens native form-funksjon, action, som gir flere fordeler. N\u00e5 trenger vi ikke JavaScript for \u00e5 sende inn dataen\u200a\u2014\u200adet fungerer ogs\u00e5 uten. S\u00e5, om brukeren ikke har JavaScript ferdig lastet inn, vil eneste konsekvens v\u00e6re at loading-tilstanden ikke\u00a0vises.
\nEr det noen svakheter ved \u00e5 h\u00e5ndtere skjema-logikken p\u00e5 serveren?
\nEn svakhet, hvert fall slik koden er n\u00e5, er at om det oppst\u00e5r feil ved innsending, blir skjemaet nullstilt, og du m\u00e5 skrive alt p\u00e5 nytt av. Men dette kan du l\u00f8se ved \u00e5 ogs\u00e5 returnere data fra server-funksjonen, og bruke dette som en defaultValue i inputfeltet.
\nEn annen svakhet er at du n\u00e5 ikke f\u00e5r tilbakemelding om feil f\u00f8r etter innsending. Dette kan du l\u00f8se med en onChange-funksjon og sjekke data l\u00f8pende, men det kan bli mye kode. En l\u00f8sning, som nevnes i videoen, er \u00e5 ta i bruk et bibliotek som conform, som lar deg kalle serverfunksjonen l\u00f8pende, s\u00e5 du kan f\u00e5 tilbakemelding om status underveis.
\nS\u00e5 ved \u00e5 ta i bruk et serverside skjema, kan du lage en l\u00f8sning som b\u00e5de f\u00e5r fordelene med et skjema som er umiddelbart tilgjengelig, og du kan f\u00e5 responsiviteten du kjenner igjen fra et klientside skjema.
\nHistorien pendler frem og tilbake. Som Scharff sier i videoen, har React hatt et fokus p\u00e5 klientside kode. Dette har f\u00f8rt til mye JavaScript hos klienten, som kan ta tid til \u00e5 laste inn. Vi har pr\u00f8vd \u00e5 flytte noe av dette til serveren, som har f\u00f8rt til at mer kode prosesseres i serveren, men det m\u00e5 fortsatt skje en hydrering i klienten for interaktivitet, som ogs\u00e5 kan ta tid. N\u00e5 flytter vi det som ikke trenger hydrering, som skjemaer, ogs\u00e5 til serveren.
\nSe videoen\u00a0her:
\nhttps://medium.com/media/f12cfb2353ca72ac74ac8d51b92dd8a5/href\u201cServeren er overhypet\u201d, sier Tanner Linsley. I Syntax-podcasten med Wes Bos og Scott Tolinski sier han at helt siden create-react-app ble deprecated, har det egentlig bare v\u00e6rt to store React rammeverk: Remix og Next.js. Disse er server f\u00f8rst. Og han syns det gj\u00f8r utvikling un\u00f8dvendig komplisert.
\nI forrige uke kom hans motsvar i beta: TanStack\u00a0Start.
\nTanner Linsley (@tannerlinsley.com)
\nHans nye rammeverk blir klient f\u00f8rst, og server opt-in. TanStack Start er visst 95% TanStack Router, 5% \u201cnoe\u00a0annet\u201d.
\nTanStack Router gir mye av funksjonalitet som du kan finne i React Router, som \u00e5 hente data f\u00f8r du laster inn en rute eller SSR. Men det har ogs\u00e5 et fokus p\u00e5 typesikker navigering, og er mer opptatt av bruk av URL-parametere som state. I tillegg er TanStack Query en stor del av TanStack Router, hvor det til og med er bygd inn en mini useQuery inn i datah\u00e5ndteringen, for cacheh\u00e5ndtering.
\nDenne 5% \u201cannet\u201d er ting som gj\u00f8r TanStack Start til et rammeverk. Dette er blant annet bundling, full-stack typesikkerhet og serverfunksjoner.
\nMed TanStack Start \u00f8nsker Linsey ogs\u00e5 \u00e5 st\u00f8tte React Server Komponenter. Som han beskriver i podcasten, har han et interessant take p\u00e5 det: han tenker ikke p\u00e5 serverkomponenter som noe mer annerledes enn annen asynkron data. Og hva er det beste biblioteket for asynkron data? TanStack\u00a0Query.
\nHan vil hente serverkomponenter med en useQuery. Det klarer jeg ikke helt \u00e5 forestille meg. I foredraget han hadde p\u00e5 Netlify-konferansen (som er verdt \u00e5 se for powerpoint-overganger alene!), viste han hvordan du kanskje kan rendre serverkomponenter via serverfunksjoner:
\n![\"\"](\"https://cdn-images-1.medium.com/max/878/1*hLTL0ver7Rn4EjR4NfKn1w.png\")
H\u00e5ndtering av RSC i TanStack Start er fortsatt i tenkeboksen. Det blir spennende \u00e5 se hvordan dette nye rammeverket kanskje kommer til \u00e5 trekke pendelen tilbake til klient-siden igjen.
\nHer er videoen fra Netlify-konferansen:
\nhttps://medium.com/media/0c1272e04e08284359e7185163f7805b/hrefMed snakket om klient versus server, og serverkomponenter oppi det hele, hva er egentlig forskjellen?
\nServerside-rendring (SSR) og React serverkomponenter (RSC) har begge ordet \u201cserver\u201d i seg, men dette er ulike konsepter. Kodaps Academy sier du heller b\u00f8r se p\u00e5 forskjellene i ordene, nemlig \u201crendring\u201d og \u201ckomponent\u201d.
\nImens SSR handler om hvordan du rendrer hele siden som en helhet, handler serverkomponent om at du rendrer en bit av siden, alts\u00e5 en komponent, p\u00e5 serveren. I tillegg kan serversside-rendret kode v\u00e6re interaktiv, mens serverkomponenter er statiske.
\nI videoen viser han ogs\u00e5 hvordan serverkomponenter ikke blir sendt som HTML, men som JSON-blob. Kanskje dette forklarer hvordan TanStack Start vil bruke useQuery p\u00e5 serverkomponenter?
\nJeg anbefaler \u00e5 ta en titt p\u00e5\u00a0videoen:
\nhttps://medium.com/media/e136a3d8de515fbc3d16a5203770208e/hrefVideoen er hentet fra Tymek Zapa\u0142a artikkel om de fem omr\u00e5dene SSR og RSC er forskjellige. Jeg har n\u00e5 allerede indirekte nevnt at SSR og RSC er forskjellige med tanke p\u00e5 komponent-tre og hydrering, men Zapa\u0142a peker ogs\u00e5 p\u00e5 forskjeller i bundle-st\u00f8rrelse, komponent-livssyklus og henting av\u00a0data.
\nLes mer om forskjellene her:
\n5 differences between React server components and server-side rendering * Tymek Zapa\u0142a
\nDette var virkelig uka for dypdykk i server vs. klient. Ogs\u00e5 m\u00e5 det selvf\u00f8lgelig ikke v\u00e6re et \u201cversus\u201d der. Ogs\u00e5 i foredraget om TanStack Start, sier Linsey at han er p\u00e5 en mellomting mellom klient og server. Men \u00e5 g\u00e5 fra server-f\u00f8rst til klient-f\u00f8rst er et brudd i hva som har v\u00e6rt trenden\u200a\u2014\u200as\u00e5 f\u00e5r vi se hvordan pendelen svinger inn i fremtiden.
\nDet var alt for denne uka\u200a\u2014\u200asnakkes i desember! \ud83d\udc4b
\n<ForrigeUke uke=\u201d47\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nDette var uka for noen siste ord, balanse i universet og a/b-testing\u2014 og 2412 ting som skjedde i frontend-verdenen!
\nEn av mine favoritt-React-pedagoger p\u00e5 YouTube, Cosden Solutions, hadde nettopp et samarbeid med norske Aurora Scharff. Her snakket de om fremtiden til skjemaer.
\nReact trender mot serveren. React 19 introduserer nye hooks som useActionState, og du kan allerede se server-funksjoner i Next.js. Hvordan ser React-serverkode ut i forhold til react-klientkode, og hvordan p\u00e5virker dette brukeren?
\nLa oss f\u00f8rst se p\u00e5 forskjellene i kode. Et popul\u00e6rt bibliotek for skjemaer p\u00e5 klientsiden er React Hook Form. Det gir deg en del funksjonalitet, som \u00e5 lettere h\u00e5ndtere tilstand og feilmeldinger, med f\u00e6rre linjer\u00a0kode.
\nHer har du et eksempel p\u00e5 skjema, hvor en bruker kan skrive inn et\u00a0navn:
\n\"use client\"\n
export default function App() {
const {
register,
handleSubmit,
// \ud83d\udc47 Vi f\u00e5r error- og loading state fra hooken
formState: { errors, isSubmitting },
} = useForm<Inputs>()
// \ud83d\udc47 Vi registrerer input-ene, og data sendes via onSubmit
const onSubmit: SubmitHandler<Inputs> = (data) => submitData(data)
return (
<form onSubmit={handleSubmit(onSubmit)}>
<label>First Name</label>
<input {...register(\"firstName\")} />
Det er ikke noe galt i \u00e5 lage et skjema p\u00e5 denne m\u00e5ten. Men det kan v\u00e6re nyttig for deg \u00e5 vite noen svakheter ved et klientside skjema.
\nEt klientside skjema er avhengig av JavaScript. Det kan v\u00e6re flere grunner til at JavaScripten ikke er ferdig prosessert i klienten, enten av tregt nett eller en treg prosessor. Om du noen gang har begynt \u00e5 skrive i et tekstfelt, for s\u00e5 at teksten plutselig forsvinner, kan det v\u00e6re at JavaScripten har brukt tid p\u00e5 \u00e5 laste inn. S\u00e5 frustrerende!
\nSiden et klientside skjema kan gi noen d\u00e5rlige brukeropplevelser, hvordan kan skjema som kaller en serverfunksjon forbedre\u00a0dette?
\nLa oss se p\u00e5 koden, med den nye useActionState-hooken, som tar imot en server-funksjon:
\n// actions.ts\n
\"use server\" // \ud83d\udc48 Server-funksjoner rendres p\u00e5 serveren
export async submitData() {
// ...
}
// App.tsx
// \ud83d\udc47 Hooken brukes i klienten, for \u00e5 f\u00e5 med interaktivitet, som loading
\"use client\"
import { submitData } from \"./actions.ts\"
export default function App() {
// \ud83d\udc47 Vi f\u00e5r data fra skjema, action for skjema og loading-state fra hooken
const [state, formAction, isPending] = useActionState(submitData, {
error: undefined,
success: false
})
return (
// \ud83d\udc47 Denne gang bruker vi action, ikke onSubmit
<form action={formAction}>
<label>First Name</label>
<input name=\"firstName\" />
Denne gangen sender vi med skjemadata via nettleserens native form-funksjon, action, som gir flere fordeler. N\u00e5 trenger vi ikke JavaScript for \u00e5 sende inn dataen\u200a\u2014\u200adet fungerer ogs\u00e5 uten. S\u00e5, om brukeren ikke har JavaScript ferdig lastet inn, vil eneste konsekvens v\u00e6re at loading-tilstanden ikke\u00a0vises.
\nEr det noen svakheter ved \u00e5 h\u00e5ndtere skjema-logikken p\u00e5 serveren?
\nEn svakhet, hvert fall slik koden er n\u00e5, er at om det oppst\u00e5r feil ved innsending, blir skjemaet nullstilt, og du m\u00e5 skrive alt p\u00e5 nytt av. Men dette kan du l\u00f8se ved \u00e5 ogs\u00e5 returnere data fra server-funksjonen, og bruke dette som en defaultValue i inputfeltet.
\nEn annen svakhet er at du n\u00e5 ikke f\u00e5r tilbakemelding om feil f\u00f8r etter innsending. Dette kan du l\u00f8se med en onChange-funksjon og sjekke data l\u00f8pende, men det kan bli mye kode. En l\u00f8sning, som nevnes i videoen, er \u00e5 ta i bruk et bibliotek som conform, som lar deg kalle serverfunksjonen l\u00f8pende, s\u00e5 du kan f\u00e5 tilbakemelding om status underveis.
\nS\u00e5 ved \u00e5 ta i bruk et serverside skjema, kan du lage en l\u00f8sning som b\u00e5de f\u00e5r fordelene med et skjema som er umiddelbart tilgjengelig, og du kan f\u00e5 responsiviteten du kjenner igjen fra et klientside skjema.
\nHistorien pendler frem og tilbake. Som Scharff sier i videoen, har React hatt et fokus p\u00e5 klientside kode. Dette har f\u00f8rt til mye JavaScript hos klienten, som kan ta tid til \u00e5 laste inn. Vi har pr\u00f8vd \u00e5 flytte noe av dette til serveren, som har f\u00f8rt til at mer kode prosesseres i serveren, men det m\u00e5 fortsatt skje en hydrering i klienten for interaktivitet, som ogs\u00e5 kan ta tid. N\u00e5 flytter vi det som ikke trenger hydrering, som skjemaer, ogs\u00e5 til serveren.
\nSe videoen\u00a0her:
\nhttps://medium.com/media/f12cfb2353ca72ac74ac8d51b92dd8a5/href\u201cServeren er overhypet\u201d, sier Tanner Linsley. I Syntax-podcasten med Wes Bos og Scott Tolinski sier han at helt siden create-react-app ble deprecated, har det egentlig bare v\u00e6rt to store React rammeverk: Remix og Next.js. Disse er server f\u00f8rst. Og han syns det gj\u00f8r utvikling un\u00f8dvendig komplisert.
\nI forrige uke kom hans motsvar i beta: TanStack\u00a0Start.
\nTanner Linsley (@tannerlinsley.com)
\nHans nye rammeverk blir klient f\u00f8rst, og server opt-in. TanStack Start er visst 95% TanStack Router, 5% \u201cnoe\u00a0annet\u201d.
\nTanStack Router gir mye av funksjonalitet som du kan finne i React Router, som \u00e5 hente data f\u00f8r du laster inn en rute eller SSR. Men det har ogs\u00e5 et fokus p\u00e5 typesikker navigering, og er mer opptatt av bruk av URL-parametere som state. I tillegg er TanStack Query en stor del av TanStack Router, hvor det til og med er bygd inn en mini useQuery inn i datah\u00e5ndteringen, for cacheh\u00e5ndtering.
\nDenne 5% \u201cannet\u201d er ting som gj\u00f8r TanStack Start til et rammeverk. Dette er blant annet bundling, full-stack typesikkerhet og serverfunksjoner.
\nMed TanStack Start \u00f8nsker Linsey ogs\u00e5 \u00e5 st\u00f8tte React Server Komponenter. Som han beskriver i podcasten, har han et interessant take p\u00e5 det: han tenker ikke p\u00e5 serverkomponenter som noe mer annerledes enn annen asynkron data. Og hva er det beste biblioteket for asynkron data? TanStack\u00a0Query.
\nHan vil hente serverkomponenter med en useQuery. Det klarer jeg ikke helt \u00e5 forestille meg. I foredraget han hadde p\u00e5 Netlify-konferansen (som er verdt \u00e5 se for powerpoint-overganger alene!), viste han hvordan du kanskje kan rendre serverkomponenter via serverfunksjoner:
\nH\u00e5ndtering av RSC i TanStack Start er fortsatt i tenkeboksen. Det blir spennende \u00e5 se hvordan dette nye rammeverket kanskje kommer til \u00e5 trekke pendelen tilbake til klient-siden igjen.
\nHer er videoen fra Netlify-konferansen:
\nhttps://medium.com/media/0c1272e04e08284359e7185163f7805b/hrefMed snakket om klient versus server, og serverkomponenter oppi det hele, hva er egentlig forskjellen?
\nServerside-rendring (SSR) og React serverkomponenter (RSC) har begge ordet \u201cserver\u201d i seg, men dette er ulike konsepter. Kodaps Academy sier du heller b\u00f8r se p\u00e5 forskjellene i ordene, nemlig \u201crendring\u201d og \u201ckomponent\u201d.
\nImens SSR handler om hvordan du rendrer hele siden som en helhet, handler serverkomponent om at du rendrer en bit av siden, alts\u00e5 en komponent, p\u00e5 serveren. I tillegg kan serversside-rendret kode v\u00e6re interaktiv, mens serverkomponenter er statiske.
\nI videoen viser han ogs\u00e5 hvordan serverkomponenter ikke blir sendt som HTML, men som JSON-blob. Kanskje dette forklarer hvordan TanStack Start vil bruke useQuery p\u00e5 serverkomponenter?
\nJeg anbefaler \u00e5 ta en titt p\u00e5\u00a0videoen:
\nhttps://medium.com/media/e136a3d8de515fbc3d16a5203770208e/hrefVideoen er hentet fra Tymek Zapa\u0142a artikkel om de fem omr\u00e5dene SSR og RSC er forskjellige. Jeg har n\u00e5 allerede indirekte nevnt at SSR og RSC er forskjellige med tanke p\u00e5 komponent-tre og hydrering, men Zapa\u0142a peker ogs\u00e5 p\u00e5 forskjeller i bundle-st\u00f8rrelse, komponent-livssyklus og henting av\u00a0data.
\nLes mer om forskjellene her:
\n5 differences between React server components and server-side rendering * Tymek Zapa\u0142a
\nDette var virkelig uka for dypdykk i server vs. klient. Ogs\u00e5 m\u00e5 det selvf\u00f8lgelig ikke v\u00e6re et \u201cversus\u201d der. Ogs\u00e5 i foredraget om TanStack Start, sier Linsey at han er p\u00e5 en mellomting mellom klient og server. Men \u00e5 g\u00e5 fra server-f\u00f8rst til klient-f\u00f8rst er et brudd i hva som har v\u00e6rt trenden\u200a\u2014\u200as\u00e5 f\u00e5r vi se hvordan pendelen svinger inn i fremtiden.
\nDet var alt for denne uka\u200a\u2014\u200asnakkes i desember! \ud83d\udc4b
\n<ForrigeUke uke=\u201d47\u201d \u00e5r=\u201d2024\u201d /> was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["forrigeuke","frontend","javascript","react","technology"]},{"title":"Det \u00e5penbare for deg kan v\u00e6re gull for andre","pubDate":"2024-09-20 09:09:28","link":"https://blogg.bekk.no/det-%C3%A5penbare-for-deg-kan-v%C3%A6re-gull-for-andre-576054f0abe8?source=rss-417bd6fed236------2","guid":"https://medium.com/p/576054f0abe8","author":"Marcus Haaland","thumbnail":"","description":"\nN\u00e5r du blir spurt om \u00e5 dele, enten det er en bloggpost eller presentasjon, dukker kanskje denne tanken opp: \u201cHva har jeg egentlig \u00e5 bidra med? Jeg har ingenting \u00e5 dele som andre ikke allerede\u00a0kan.\u201d
\nOfte undervurderer vi verdien av det vi gj\u00f8r daglig, fordi det har blitt rutine eller du vet om noen som kan mer enn deg. Men det du ser som trivielt, kan v\u00e6re akkurat det som hjelper\u00a0andre.
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/0*TsB2wzkvN-DkQLUh\")
Det m\u00e5 ikke alltid v\u00e6re edelt gull du deler. Noen ganger er kr\u00e5kes\u00f8lv bra nok det ogs\u00e5. I beste fall deler du noe som hjelper andre. I verste fall f\u00e5r du kritikk som lar deg forst\u00e5 temaet bedre. Uansett er diskusjonen som f\u00f8lger noe du kan ta med videre, og hjelper deg \u00e5 utvikle\u00a0deg.
\nF\u00f8r du blar nedover, ta en titt p\u00e5 Derek Sivers fine, korte video som sier dette p\u00e5 en fantastisk m\u00e5te:
\nhttps://medium.com/media/fbac8e07f1cad7a36f28d3a6589da8cb/hrefN\u00e5 som vi er enige i at ideer kan v\u00e6re store og sm\u00e5, hvordan kommer vi i gang med \u00e5 finne\u00a0ideene?
\nFor \u00e5 kickstarte idegenereringen anbefaler jeg Lucy Bains mini-sesjon for \u00e5 generere ideer. Her har hun samlet 12 sp\u00f8rsm\u00e5l som gir fart p\u00e5 de sm\u00e5 gr\u00e5,\u00a0som
\n\u00c5pne et tomt Word-ark, kopier inn sp\u00f8rsm\u00e5lene og sett kj\u00f8kkenklokka p\u00e5 30 minutter. Du vil bli overrasket av antall gullkorn du genererer.
\nLucy | How to come up with conference proposal ideas
\n\u00c5 kickstarte idegenereringen er nyttig for \u00e5 komme i gang, men ofte er det de spontane \u201cAHA\u201d-\u00f8yeblikkene i hverdagen som gir meg de beste\u00a0ideene.
\nDet kan v\u00e6re etter en frustrerende debugging-sesjon hvor jeg endelig forst\u00e5r noe jeg ikke visste f\u00f8r, eller etter sparring med en kollega som forteller om noe jeg \u00f8nsker \u00e5 l\u00e6re mer\u00a0om.
\nFor \u00e5 ikke glemme alle ideene, har jeg lagd et system for \u00e5 fange dem. I Notion har jeg en tavle best\u00e5ende av fire kolonner: ide, disposisjon, f\u00f8rsteutkast og publisert:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*AxIwx6htMVSJCzuVGi5Aug.png\")
Disse fire kolonnene er stadier av hvor langt jeg har kommet med en\u00a0ide:
\nFor hvert ide-dokument har jeg en simpel mal, s\u00e5 jeg kan fylle ut idemyldring, disposisjon og f\u00f8rsteutkast:
\n![\"\"](\"https://cdn-images-1.medium.com/max/1024/1*Dgx39vRWZUMeqjrJPA7B9Q.png\")
Jeg pr\u00f8ver \u00e5 kaste alle ideer som pirrer nysgjerrigheten inn i tavla, men det vanskeligste steget er \u00e5 g\u00e5 fra utkast til\u00a0deling.
\nHer syns jeg det hjelper \u00e5 tenke p\u00e5 klassikeren, som du forh\u00e5pentligvis h\u00f8rer f\u00f8r hver Q&A-sesjon: om du i en forsamling har et sp\u00f8rsm\u00e5l, kan du v\u00e6re sikker p\u00e5 at ti andre personer lurer p\u00e5 det samme sp\u00f8rsm\u00e5let.
\nS\u00e5 om ti andre lurer p\u00e5 det samme, kanskje det du har p\u00e5 hjertet ikke er s\u00e5 \u00e5penbart likevel?\u00a0\ud83d\udc9b
\n\ud83d\udc9b Det \u00e5penbare for deg kan v\u00e6re gull for andre was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","content":"\nN\u00e5r du blir spurt om \u00e5 dele, enten det er en bloggpost eller presentasjon, dukker kanskje denne tanken opp: \u201cHva har jeg egentlig \u00e5 bidra med? Jeg har ingenting \u00e5 dele som andre ikke allerede\u00a0kan.\u201d
\nOfte undervurderer vi verdien av det vi gj\u00f8r daglig, fordi det har blitt rutine eller du vet om noen som kan mer enn deg. Men det du ser som trivielt, kan v\u00e6re akkurat det som hjelper\u00a0andre.
\nDet m\u00e5 ikke alltid v\u00e6re edelt gull du deler. Noen ganger er kr\u00e5kes\u00f8lv bra nok det ogs\u00e5. I beste fall deler du noe som hjelper andre. I verste fall f\u00e5r du kritikk som lar deg forst\u00e5 temaet bedre. Uansett er diskusjonen som f\u00f8lger noe du kan ta med videre, og hjelper deg \u00e5 utvikle\u00a0deg.
\nF\u00f8r du blar nedover, ta en titt p\u00e5 Derek Sivers fine, korte video som sier dette p\u00e5 en fantastisk m\u00e5te:
\nhttps://medium.com/media/fbac8e07f1cad7a36f28d3a6589da8cb/hrefN\u00e5 som vi er enige i at ideer kan v\u00e6re store og sm\u00e5, hvordan kommer vi i gang med \u00e5 finne\u00a0ideene?
\nFor \u00e5 kickstarte idegenereringen anbefaler jeg Lucy Bains mini-sesjon for \u00e5 generere ideer. Her har hun samlet 12 sp\u00f8rsm\u00e5l som gir fart p\u00e5 de sm\u00e5 gr\u00e5,\u00a0som
\n\u00c5pne et tomt Word-ark, kopier inn sp\u00f8rsm\u00e5lene og sett kj\u00f8kkenklokka p\u00e5 30 minutter. Du vil bli overrasket av antall gullkorn du genererer.
\nLucy | How to come up with conference proposal ideas
\n\u00c5 kickstarte idegenereringen er nyttig for \u00e5 komme i gang, men ofte er det de spontane \u201cAHA\u201d-\u00f8yeblikkene i hverdagen som gir meg de beste\u00a0ideene.
\nDet kan v\u00e6re etter en frustrerende debugging-sesjon hvor jeg endelig forst\u00e5r noe jeg ikke visste f\u00f8r, eller etter sparring med en kollega som forteller om noe jeg \u00f8nsker \u00e5 l\u00e6re mer\u00a0om.
\nFor \u00e5 ikke glemme alle ideene, har jeg lagd et system for \u00e5 fange dem. I Notion har jeg en tavle best\u00e5ende av fire kolonner: ide, disposisjon, f\u00f8rsteutkast og publisert:
\nDisse fire kolonnene er stadier av hvor langt jeg har kommet med en\u00a0ide:
\nFor hvert ide-dokument har jeg en simpel mal, s\u00e5 jeg kan fylle ut idemyldring, disposisjon og f\u00f8rsteutkast:
\nJeg pr\u00f8ver \u00e5 kaste alle ideer som pirrer nysgjerrigheten inn i tavla, men det vanskeligste steget er \u00e5 g\u00e5 fra utkast til\u00a0deling.
\nHer syns jeg det hjelper \u00e5 tenke p\u00e5 klassikeren, som du forh\u00e5pentligvis h\u00f8rer f\u00f8r hver Q&A-sesjon: om du i en forsamling har et sp\u00f8rsm\u00e5l, kan du v\u00e6re sikker p\u00e5 at ti andre personer lurer p\u00e5 det samme sp\u00f8rsm\u00e5let.
\nS\u00e5 om ti andre lurer p\u00e5 det samme, kanskje det du har p\u00e5 hjertet ikke er s\u00e5 \u00e5penbart likevel?\u00a0\ud83d\udc9b
\n\ud83d\udc9b Det \u00e5penbare for deg kan v\u00e6re gull for andre was originally published in Bekk on Medium, where people are continuing the conversation by highlighting and responding to this story.
\n","enclosure":{},"categories":["technology","ideation","writing"]}]}