<h3>Optimistiske oppdateringer med TanStack Query</h3>
React 19 introduserer en ny hook kalt <a href="https://react.dev/reference/react/useOptimistic">useOptimistic</a>, som skal gjøre optimitiske oppdateringer enklere. I påvente av den, ønsker jeg å vise hva optimistiske oppdateringer er, og hvordan du kan implementere det i løsningen din allerede nå, uten å ty til en eksperimentell React-versjon. I denne posten viser jeg optimistiske oppdateringer med vanilla React og TanStack Query.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*L6CxY27TVlzwj5A88Qu3ag.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@dtopkin1?utm_content=creditCopyText&amp;utm_medium=referral&amp;utm_source=unsplash">Dayne Topkin</a> on <a href="https://unsplash.com/photos/woman-in-black-jacket-and-yellow-knit-cap-standing-on-sidewalk-during-daytime-KJBVIwYRkTE?utm_content=creditCopyText&amp;utm_medium=referral&amp;utm_source=unsplash">Unsplash</a></figcaption></figure><h3>Men først — hva er optimistiske oppdateringer?</h3>
Som bruker kan du bli usikker på om noe foregår om du trykker på en knapp, men ingenting skjer. I eksempelet under sender jeg en melding, men det tar en god stund før jeg får se resultatet av handlingen:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*8QJg2cgAU8TZQST2StPq0Q.gif"><figcaption>Bruker trykker på “melding”, og UI vises etter backend-kall har respondert</figcaption></figure>Om du forventer at handlingen har suksess flertallet av gangene, kan du gi brukeren en umiddelbar tilbakemelding, før backend-kallet er fullført, altså en optimistisk oppdatering:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*0vWIxVgDztB7YfHXAw2EbA.gif"><figcaption>Bruker trykker på “melding”, og ny UI vises umiddelbart, men transparent. Etter backend-kall har respondert, vises ny melding som vanlig</figcaption></figure><h3>Optimistisk oppdatering i tre steg</h3>
Selv om ulike biblioteker kan ha ulik syntaks, har optimistiske oppdateringer likevel et mønster som går igjen. Etter at brukeren har gjort en handling, som å sende en melding, er det tre steg:
<ol>
<li>Klient-tilstanden endres umiddelbart, for å vise endring til bruker a) Husk også gammel tilstand, tilfelle feil skjer og tilstand rulles tilbake</li>
<li>Et kall gjøres til serveren for å lagre tilstand til server</li>
<li>Etter API-kallet fullføres: a) Hvis kallet var vellykket, oppdater klient-tilstanden med den nye server-tilstanden b) Hvis kallet feiler, rull tilbake klient-tilstanden til gammel tilstand</li>
</ol>
Vi skal nå se på hvordan implementere dette i vanilla React og TanStack Query.
<h3>Optimistisk oppdatering i vanilla React</h3>
Før vi ser på hvordan vi implementerer optimistisk oppdatering i TanStack Query, kan det være nyttig å se hvordan du kan gjøre det i vanilla React.
Under har jeg implementert meldingslisten. Først litt setup, hvor vi starter med noen meldinger og lager et fake API-kall:
<pre>// 👇 Setter opp fake tilstand for backend-end kall const initialMessages = [ { id: "1", content: "Hei! Hvordan går det?" }, { id: "2", content: "Alt bra her, hva med deg?" }, { id: "3", content: "Veldig bra, takk for at du spurte!" }, ]; const fakeNewMessage = { id: "4", content: "Dette er en ny melding!", }; interface Message { id: string; content: string; } const fakeApiCall = (newMessage: Message): Promise&lt;Message[]&gt; =&gt; { return new Promise((resolve, reject) =&gt; { setTimeout(() =&gt; { if (Math.random() &gt; 0.1) { resolve([...initialMessages, fakeNewMessage]); } else { reject("Feil ved lagring av melding!"); } }, 1000); }); };</pre>
Så har vi meldings-komponenten, nå først uten optimistisk oppdatering. Her rendrer vi en enkel liste av meldinger. Så ved klikk på knappen, vil en hardkodet melding legges til i listen av meldinger:
<pre>export const MessageList = () =&gt; { const [messages, setMessages] = useState&lt;Message[]&gt;(initialMessages); const [loading, setLoading] = useState(false); const addMessage = async (newMessage: Message) =&gt; { setLoading(true); try { const messagesFromBackend = await fakeApiCall(newMessage); setMessages(messagesFromBackend); } catch (error) { console.error(error); } finally { setLoading(false); } }; function handleAddMessage() { void addMessage({ id: "temp-id", content: "Dette er en ny melding!", }); } return ( &lt;div&gt; &lt;h2&gt;Meldinger&lt;/h2&gt; &lt;ul&gt; {messages.map((message) =&gt; ( &lt;li key={message.id} &gt; {message.content} &lt;/li&gt; ))} &lt;/ul&gt; &lt;button onClick={handleAddMessage} disabled={loading}&gt; Legg til ny melding &lt;/button&gt; &lt;/div&gt; ); };</pre>
I kodesnutten under har jeg lagt til optimistisk oppdatering. Forskjellen er å legge til den nye meldingen i klient-tilstanden med engang.
Så vil meldingen lagres i backend, og vi oppdaterer tilstanden i klienten med data fra serveren. Ved feil ruller vi tilbake til den forrige tilstanden:
<pre>export const MessageList = () =&gt; { const [messages, setMessages] = useState&lt;Message[]&gt;(initialMessages); const [loading, setLoading] = useState(false); const addMessageOptimistically = async (newMessage: Message) =&gt; { // 👇 1a: Lagre forrige tilstand const prevMessages = messages; const optimisticMessages = [...prevMessages, newMessage]; // 👇 1: Setter state med ny melding med en gang setMessages(optimisticMessages); setLoading(true); try { // 👇 2: Lagre melding const messagesFromBackend = await fakeApiCall(newMessage); // 👇 3a: Setter tilstand med faktiske data setMessages(messagesFromBackend); } catch (error) { console.error(error); // 👇 3b: Resetter tilstand ved feil setMessages(prevMessages); } finally { setLoading(false); } }; function handleAddMessage() { void addMessageOptimistically({ id: "temp-id", // 👈 Setter en gjenkjennelig id, så jeg kan style melding content: "Dette er en ny melding!", }); } return ( &lt;div&gt; &lt;h2&gt;Meldinger&lt;/h2&gt; &lt;ul&gt; {messages.map((message) =&gt; ( &lt;li key={message.id} /* 👇 Ny melding er transparent */ style={{ opacity: message.id === "temp-id" ? 0.3 : 1 }} &gt; {message.content} &lt;/li&gt; ))} &lt;/ul&gt; &lt;button onClick={handleAddMessage} disabled={loading}&gt; Legg til ny melding &lt;/button&gt; &lt;/div&gt; ); };</pre>
<h3>TanStack Query</h3>
<a href="https://tanstack.com/query/latest">TanStack Query</a> er et populært bibliotek som forenkler datahenting. Også i dette biblioteket kan du gjøre optimistiske oppdateringer, og det følger samme mønster vi har sett på.
La oss igjen først se på eksempelet uten optimistisk oppdatering. I TanStack Query er det ikke en komponents state du skal oppdatere, men en cache som deles på tvers i applikasjonen. Her henter vi data med en useQuery og lagrer det på cache-nøkkelen “messages”. Vi bruker useMutation til å sende en melding, og etter suksess invaliderer vi cachen, så ny data oppdateres:
<pre>export const MessageList = () =&gt; { const queryClient = useQueryClient(); const { data: messages } = useQuery(["messages"], fetchMessages); const mutation = useMutation(fakeApiCall, { onSuccess: async () =&gt; { await queryClient.invalidateQueries(["messages"]); }, }); const handleAddMessage = () =&gt; { const newMessage: Message = { id: "temp-id", content: "Dette er en ny melding!", }; mutation.mutate(newMessage); }; return (...</pre>
La oss nå se på et eksempel med optimistisk oppdatering. Denne gangen har vi en funksjon “onMutate”, som setter ny tilstand umiddelbart. Vi har også lagt til feilhåndtering med “onError”, hvor tidligere tilstand settes ved feil. Invalideringen av cachen er flyttet fra “onSuccess” til “onSettled”, som betyr at invalideringen skjer både etter feil og etter suksess, så vi til slutt ender opp med lik tilstand i klienten og serveren:
<pre>export const MessageList = () =&gt; { const queryClient = useQueryClient(); const { data: messages } = useQuery(["messages"], fetchMessages); const mutation = useMutation(fakeApiCall, { // 👇 Ved mutering, gjør følgende: onMutate: async (newMessage: Message) =&gt; { // 👇 Stopp eventuelle pågående queries, for å unngå race condition await queryClient.cancelQueries(["messages"]); // 👇 1a: Lagre forrige tilstand const previousMessages = queryClient.getQueryData&lt;Message[]&gt;([ "messages", ]); // 👇 1: Setter tilstand med ny melding med en gang queryClient.setQueryData&lt;Message[]&gt;(["messages"], (old = []) =&gt; [ ...old, newMessage, ]); return { previousMessages }; }, onError: (err, newMessage, context) =&gt; { // 👇 3b: Resetter tilstand ved feil queryClient.setQueryData(["messages"], context?.previousMessages); }, onSettled: async () =&gt; { // 👇 3a/3b: Ved feil eller suksess, invalider cache for å hente ferske data await queryClient.invalidateQueries(["messages"]); }, }); const handleAddMessage = () =&gt; { const newMessage: Message = { id: "temp-id", content: "Dette er en ny melding!", }; mutation.mutate(newMessage); }; return (...</pre>
<h3>Videre lesing</h3>
For å lære mer om optimistiske oppdateringer i TanStack Query, ta en titt på docs. Der kan du også se en enklere syntaks til optimistisk oppdatering om muteringen skjer i samme komponent som dataene skal vises. Da kan du aksessere dataene (se variables) du sender med muteringen, og på den måten forhåndsvise endringene: <a href="https://tanstack.com/query/latest/docs/framework/react/guides/optimistic-updates#via-the-ui">https://tanstack.com/query/latest/docs/framework/react/guides/optimistic-updates#via-the-ui</a>
For å se hvordan optimistiske oppdateringer skjer med den nye useOptimistic-hooken, kan jeg anbefale Jack Herringtons video på temaet. Han viser også hvordan hooken kan brukes med TanStack Query, men jeg er usikker på om den forenkler noe, eller om eksempelet som vist over er bedre. Hva tror du? <a href="https://www.youtube.com/watch?v=QWVr7uDyBXE">https://www.youtube.com/watch?v=QWVr7uDyBXE</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=da70ceedf4a4" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/optimistiske-oppdateringer-i-tanstack-query-da70ceedf4a4">Optimistiske oppdateringer i TanStack Query</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Optimistiske oppdateringer i TanStack Query

Dette var uka for <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1f1nruj/idontgetthehype/#lightbox">manglende galvanisering</a>, <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1f0ygbf/yesletsencrypt/#lightbox">miskommunikasjon</a> og <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1f1j8od/noididnt/#lightbox">actionfylte (fil)typer</a> — og 278 andre ting som skjedde i frontend-verdenen!
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*OI_20AALtxD9XOKc"><figcaption>Photo by <a href="https://unsplash.com/@houcinencibphotography?utm_source=medium&amp;utm_medium=referral">Houcine Ncib</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Hvorfor Google Translate (og andre utvidelser) kræsjer nettsiden din</h3>
Om du har en bug som forsvinner når du besøker en inkognitofane, går min hovedmistanke mot en Chrome-utvidelse. Det er frustrerende når noe utenfor koden vår forårsaker trøbbel, og det er gjerne noe vi utforsker først etter noen timer debugging. Mange av disse problemene oppstår på grunn av hvordan React er optimalisert.
Martijn Hols beskriver hvordan Google Translate og andre utvidelser påvirker applikasjoner. Google Translate fjerner og dytter inn DOM-elementer i applikasjonen din. Det gjør den ved å bytte ut tekstnoder med et “font”-element:
<pre>&lt;h3&gt;Hallo ForrigeUke!&lt;/h3&gt; // Original &lt;h3&gt;&lt;font&gt;Hello LastWeek!&lt;/font&gt;&lt;/h3&gt; // Oversatt</pre>
Å endre DOM-en utenfra er et problem i React, siden React bruker “<a href="https://legacy.reactjs.org/docs/faq-internals.html">Virtual DOM</a>”. Dette innebærer at React holder rede på referanser på alle elementer og oppdaterer bare de som endrer seg. Når utvidelser endrer elementer i DOM-en uten å si ifra til React, blir det kluss.
Det er i hvert fall tre feil som kan skje som følge av DOM-endringen:
<ul>
<li>Når Google Translate dytter inn et nytt element, vet ikke React om dette elementet. Dermed vil ikke state-endringer for det forrige elementet komme med i den nye UI-en</li>
<li>Ettersom font-elementet legger seg oppå elementer, kan elementer som knapper få mindre klikkflate</li>
<li>Siden Reacts referanse til en tekstnode blir fjernet, kan siden kræsje når React ønsker å endre rekkefølge, som ved betinget visning</li>
</ul>
Det fins overraskende nok ikke en god løsning på alle problemene oversettelses-utvidelsen kan bringe med seg:
<ul>
<li>En løsning for sidekræsj er å wrappe tekst i et span-element, så selv om teksten fjernes, bevares referansen til span-elementet. Denne løsningen fikser ikke de andre to problemene</li>
<li>En annen løsning er å blokkere bruk av oversettelse-utvidelse, men det stenger ute brukere som ikke kan språket</li>
<li>En tredje løsning er å implementere oversettelser i applikasjonen selv, men dette er ressurskrevende</li>
</ul>
Det er heller ikke enighet i hvem som har ansvaret for å sørge for at utvidelser ikke brekker applikasjoner. En <a href="https://issues.chromium.org/issues/41407169#comment10">person som jobbet med oversettelser</a> mente at DOM-en ikke kun er noe applikasjonen skal kunne endre, så applikasjonsutviklere må tilrettelegge for andre utenfor. Dette passer ikke biblioteker som React inn i.
Hols mener at det ikke er verdt å ofre ytelsesforbedringen Virtual DOM gir for å tillate at eksterne skal tukle med applikasjonen. Det er utvidelses-utviklere som gjør noe eksternt fra applikasjonen, så de må også sørge for at de ikke lager noe som knekker dem.
Ta et dypere dykk i problemene og diskusjonen her:
<a href="https://martijnhols.nl/gists/everything-about-google-translate-crashing-react">Everything about Google Translate crashing React (and other web apps) by Martijn Hols</a>
<h3>Typesikkerhet i React Query med Zod</h3>
Når du skal type et kall i frontend, er en naiv løsning å lage en type for hva du forventer fra backend:
<pre>interface FetchedData { id: number; name: string; } async function fetchData(): Promise&lt;FetchedData&gt; { const response = await fetch('&lt;https://api.example.com/data&gt;'); return response.json(); }</pre>
Men om noen endrer et felt i backend, er det ikke noe automatikk i at typen i frontend endres, som kan føre til feil. For dette fins det flere løsninger, med varierende krav og innsats.
En løsning er å dele typer mellom frontend og backend, men det krever at TypeScript brukes på begge sider av stacken og at koden er i et monorepo.
En annen løsning ved ulike teknologier, er å bruke et verktøy som lager typer for deg, som <a href="https://swagger.io/tools/swagger-codegen/">swagger-codegen</a>.
Disse løsningene kan kreve litt setup, så Noah Falk foreslår heller å bruke <a href="https://zod.dev/">valideringsbiblioteket Zod</a>.
Et Zod-skjema ligner på en TypeScript-type:
<pre>import { useQuery } from 'react-query'; import { z } from 'zod'; const FetchedDataSchema = z.object({ id: z.number(), name: z.string(), }); type FetchedData = z.infer&lt;typeof FetchedDataSchema&gt;;</pre>
Fordelen med å bruke Zod sammen med TypeScript er at du kan validere dataene i runtime. Det gjør at om du ikke får de ventede dataene fra backend, kan du kaste en feil.
Her er et eksempel med Zod sammen med <a href="https://tanstack.com/query/latest">TanStack Query</a>. Her henter vi data med en fetch, og om dataene ikke stemmer overens med skjemaet, vil Zod kaste en feil som vi får tilgang til i error:
<pre>async function fetchData(): Promise&lt;FetchedData&gt; { const response = await fetch('&lt;https://api.example.com/data&gt;'); const data = await response.json(); return FetchedDataSchema.parse(data); } function DataFetchingComponent() { const { data, isLoading, error } = useQuery('data', fetchData); if (isLoading) { return &lt;div&gt;Loading...&lt;/div&gt;; } if (error) { return &lt;div&gt;Error&lt;/div&gt;; } return ( &lt;div&gt; {`ID: ${data.id}, Name: ${data.name}`} &lt;/div&gt; ); }</pre>
Før kodebasen din florerer av Zod-skjemaer, skal du vite at du bare bør bruke det når du trenger det. Du trenger ikke å kaste et skjema på en funksjon hvor du sender med en hardkodet verdi, for da vet du allerede hvilken verdi du får. Zod er heller beregnet på data du er usikker på, som fra et backend-kall du ikke har helt kontroll på eller et skjemafelt som brukeren skriver inn.
Ta en titt på resten av artikkelen her:
<a href="https://noahflk.com/blog/typesafe-rest-api">Making a REST API typesafe with React Query and Zod - Noah Falk</a>
<h3>Nå er det lettere å lage PDF-er i React</h3>
Mange bedrifter ønsker å vise en PDF til kundene sine, som en kvittering eller en annen bestillingsbekreftelse. Lenge har <a href="https://pptr.dev/">Puppeteer</a> vært et populært valg for dette, men Colby Fayock presenterer to mye enklere løsninger — inkludert en spesifikk for React.
<a href="https://ekoopmans.github.io/html2pdf.js/">html2pdf</a> er et bibliotek som er latterlig lett å bruke. Med bare to kodelinjer kan du laste ned en PDF:
<pre>&lt;div id="kvittering"&gt; Kvitteringsinnhold &lt;/div&gt; const html2pdf = await require('html2pdf.js'); html2pdf(document.getElementById('kvittering'));</pre>
Selv om det er enkelt å bruke, har det dessverre en stor begrensning: det omformer UI-et til et bilde, som så blir lagt i en PDF. Siden det er et bilde, blir ikke tekstinnholdet søkbart, og dermed heller ikke tilgjengelig for skjermlesere.
Heldigvis fins et annet alternativ: <a href="https://react-pdf.org/">react-pdf</a>. Det krever litt mer enn to linjer, men til gjengjeld får du en søkbar tekst. Mens html2pdf lager et bilde av det eksisterende templatet, må du selv bygge PDF-en med react-pdf. Dette gjør du med visse grunnelementer, som Document, Page og Text.
Fra videoen og artikkelen forteller Fayock om hvordan du kan style PDF-en med StyleSheet, som ligner hvordan du styler i React Native. Men om denne syntaksen er uvant for deg, er det en i <a href="https://www.youtube.com/watch?v=4V5HbqYJCVI">kommentarfeltet</a> som tipser om biblioteket <a href="https://www.npmjs.com/package/react-pdf-tailwind">react-pdf-tailwind</a>, som lar deg style PDF-en med Tailwind:
<pre>import { Page, Document, Text } from "@react-pdf/renderer"; import { createTw } from "react-pdf-tailwind"; const tw = createTw({ theme: { fontFamily: { sans: ["Comic Sans"], }, extend: { colors: { custom: "#bada55", }, }, }, }); function MyPdf() { return ( &lt;Document&gt; &lt;Page&gt; &lt;Text style={tw("p-20 bg-gray-100")}&gt;Hello&lt;/Text&gt; &lt;Text style={tw("p-20 bg-red-100")}&gt;Forrige&lt;/Text&gt; &lt;Text style={tw("p-20 bg-blue-100")}&gt;Uke&lt;/Text&gt; &lt;/Page&gt; &lt;/Document&gt; ); }</pre>
En måte å få ut filen på, er å lage et endepunkt med Next for å hente ut filen:
<pre>// app/pdf/route.tsx export async function GET() { const stream = await renderToStream(&lt;MyPdf /&gt;); // Liten hack for TS return new NextResponse(stream as unknown as ReadableStream); }</pre>
Da kan også du få en slik lekker PDF:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*pk9hdlnxtoSDnIpRhgClhA.png"><figcaption>Skjermbilde av PDF som viser Hello Forrige Uke med farger</figcaption></figure>En begrensning med react-pdf er at du ikke bare kan dytte innholdet ditt inn i en PDF-generator, men heller må gjenskape templaten. Det var en annen person i <a href="https://www.youtube.com/watch?v=4V5HbqYJCVI">kommentarfeltet</a> som foreslo å bruke <a href="https://www.npmjs.com/package/react-pdf-html">react-pdf-html</a>, som lover å transformere direkte fra React til PDF. Dette fikk jeg dessverre ikke til å fungere, så om du klarer det, rop ut!
<a href="https://spacejelly.dev/posts/generate-a-pdf-from-html-in-javascript">Generate a PDF in React on Space Jelly</a>
Det var alt for denne gang. Ha en finfin uke!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=4e52dd24c2ed" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/forrigeuke-uke-34-%C3%A5r-2024-4e52dd24c2ed">&lt;ForrigeUke uke=”34” år=”2024” /&gt;</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

&lt;ForrigeUke uke=”34” år=”2024” /&gt;

Dette var uka for <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1eugc42/justincase/#lightbox">å være på den sikre siden</a>, <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1evqgkb/writingcodedocumentationiseasy/#lightbox">hjelpsomme readmes</a> og <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1etzb7b/whencodeworksanditshouldnt/#lightbox">uventet suksess</a> — og 224 andre ting som skjedde i frontend-verdenen!
<blockquote>&lt;ForrigeUke /&gt; er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.</blockquote>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*qdvF-2AbkbnldSrn"><figcaption>Photo by <a href="https://unsplash.com/@iamromankraft?utm_source=medium&amp;utm_medium=referral">Roman Kraft</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Ikke vær redd for å overkomplisere</h3>
For to år siden skapte CSS-guruen Kevin Powell oppstyr med en <a href="https://www.youtube.com/shorts/SGlpOnIgk1w">video</a> der han kondenserte fire kodelinjer til to. Han ble kritisert for å overkomplisere enkel, leselig kode og spre dårlige praksiser. På årets <a href="https://cssday.nl/2024">CSS Day</a>-konferanse tok han opp temaet igjen, og opptaket ble postet forrige uke.
Rabalderet startet med denne kodesnutten, som sentrerer et element med en maksimal bredde på 600px og gir det litt padding:
<pre>.wrapper { width: 100%; max-width: 600px; padding: 0 1em; margin: 0 auto; }</pre>
Dette minimerte Powell til to linjer med bruk av den da nye <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/min">min</a>-funksjonen:
<pre>.wrapper { width: min(100% - 2rem, 600px); margin-inline: auto; }</pre>
Hvilken syns du er enklest å forstå?
Etter å ha blitt kalt en “CSS noob” for å ha gjort enkel kode mer komplisert, vurderte han å fjerne videoen. Likevel valgte han å beholde den, siden den åpner for en viktig diskusjon: Hvor går grensen mellom overkomplisering og det som bare er uvant?
Nye funksjoner kan virke uvante, og noen ganger trenger du mer avansert kode. Likevel kan du gjøre tiltak for å gjøre koden mer forståelig for andre.
Et nyttig triks i CSS er å bruke CSS-variabler for å tydeliggjøre hvordan koden kan endres. Her er et lengre eksempel som viser nytten:
<pre>.columns { /* user setting */ --min-column-size: 200px; --column-count: 4; --gap: 2rem; /* calculations */ --breakpoint: calc(var(--min-column-size) * var(--column-count) + (var(--gap) * (var(--column-count) - 1)) ); --column-size: calc((100% / var(--column-count)) - var(--gap)); display: grid; gap: var(--gap); grid-template-columns: repeat( auto-fit, minmax( min(max(var(--column-size), (100% - var(--breakpoint)) * -999 ), 100%), 1fr) ); }</pre>
Å tilby utviklere enkle måter å endre noe på er også mulig i andre teknologier, som å eksponere relevante parametere i en funksjon eller navngi mystiske verdier.
Så hvor går grensen mellom “god overkomplisering” og “[sett-inn-gitt-teknologi] noob”? Kevin Powell argumenterer for at du skal tillate deg selv å overkomplisere for å eksperimentere med nye måter å gjøre ting på, men stadig ha et øye til lesbarhet.
Om vi alle hadde vært redd for endring, hadde vi vel alle vært stuck på <a href="https://react.dev/reference/react/Component">klassekomponenter</a>?
Se foredraget hans her:
<a href="https://medium.com/media/5da33d13c0e3f2cf3a08da22acaa6d0e/href">https://medium.com/media/5da33d13c0e3f2cf3a08da22acaa6d0e/href</a><h3>Refaktorering med sunn fornuft</h3>
Kode blir sjelden uforståelig fordi én person overkompliserer noe. Heller er det flere personer over lang tid som har gjort små endringer for å fikse en bug eller lagt til ny funksjonalitet.
Dette gjelder CSS så vel som andre teknologier, og for å hjelpe oss i React har Alex Kondov skrevet en rekke tips for å refaktorere koden. Dette er sårt trengt, ettersom jeg videreutvikler funksjonalitet fra et hackaton.
Her er 5 av de mange tipsene han kommer med:
<ul>
<li>start med en blackbox-test, så du vet at komponenten gjør de samme kallene og spytter ut det samme som før</li>
<li>bytt ut kompleks datahentings-kode med mer leselige API-er fra biblioteker som <a href="https://tanstack.com/query/latest/docs/framework/react/installation">react-query</a>
</li>
<li>mange useStates i en komponent er tegn på at komponenten gjør for mye, så del den opp i flere komponenter</li>
<li>fjern unødvendige states. Hvis “showLoadingIndicator” alltid vises samtidig med “isLoading”, kan du heller bare beholde den siste</li>
<li>om du betinget viser store klumper med JSX, putt klumpene i egne komponenter eller lag mer granulære betingelser</li>
</ul>
Se flere tips med kodeeksempler her:
<a href="https://alexkondov.com/refactoring-a-messy-react-component">Common Sense Refactoring of a Messy React Component</a>
<h3>101 tips til bedre React-kode</h3>
For å unngå uforståelig kode over tid, bør vi følge gode kodepraksiser fra start. Heldigvis har Ndeye Fatou Diop samlet 101 tips for bedre React-kode, fra named exports til anbefalte biblioteker.
Det var også flere refaktoreringstips her, som å bruke <a href="https://github.com/reactjs/react-codemod">codemod</a>, som automagisk refaktorerer koden. Dette kan være veldig nyttig når du migrerer over til å bruke React-kompilatoren, så du med <a href="https://codemod.com/registry/react-19-remove-memoization">én kommando</a> fjerner alle nå overflødige memoiseringsfunksjoner.
Før du blir overveldet av 101 tips, anbefaler jeg deg å åpne “table of content” i artikkelen, og titte på kategoriene du er mest interessert i. For eksempel var det flere gode tips for state-håndtering, noe som hjelper deg å holde en komponent leselig.
Se lenke for flere tips:
<a href="https://dev.to/_ndeyefatoudiop/101-react-tips-tricks-for-beginners-to-experts-4m11">101 React Tips &amp; Tricks For Beginners To Experts ✨</a>
Det var alt for denne gang. Sees neste uke!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=0280d9a21f4d" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/forrigeuke-uke-33-%C3%A5r-2024-0280d9a21f4d">&lt;ForrigeUke uke=”33” år=”2024” /&gt;</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

&lt;ForrigeUke uke=”33” år=”2024” /&gt;

Dette var uka for <a href="https://www.amitmerchant.com/javascript-snippet-that-sets-all-lighthouse-scores-to-hundred/">perfekt lighthouse-score</a>, 500 måter å <a href="https://www.phpied.com/files/location-location/location-location.html">laste inn siden</a> på og <a href="https://www.youtube.com/shorts/qIbcssXs_Mk">tvilsomme features</a> — og 197 andre ting som skjedde i frontend-verdenen!
<blockquote>&lt;ForrigeUke /&gt; er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.</blockquote>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*FdBJj_ZWLyomLIg8"><figcaption>Photo by <a href="https://unsplash.com/@nathjennings_?utm_source=medium&amp;utm_medium=referral">Nathan Jennings</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Overgang til React 18</h3>
Det er <a href="https://react.dev/blog/2024/04/25/react-19">3 måneder siden React 19</a> ble sluppet, og det er lett å la seg rive med av nye, gøye funksjoner som server-actions og useOptimistic — selv om det enda er i beta. Men det er flere av oss som fortsatt sitter på eldre React-versjoner.
Bare nå på fredag jublet teamet mitt da vi endelig pusha PR-en som fikk oss over på React 18. Da var det bare å dra frem popkornet og lese seg opp på <a href="https://react.dev/blog/2022/03/29/react-v18">release notes fra 2 år tilbake</a>.
En betydelig endring i React 18 er konseptet “concurrent”, som handler om at rendringen blir brutt opp i flere biter, så du kan prioritere hvilke deler som rendres først. Dette gir en mer responsiv opplevelse for brukeren. Noe av dette foregår automagisk, mens andre ting kontrollerer du med nye hooks, som useTransition.
Dette var en av motivasjonene for at New York Times nå migrerte over til React 18. Med millioner av besøkende på nettsiden, er dette en gjeng som er over gjennomsnittet opptatt av SEO og ytelse. De håpte også automatisk batching av state-oppdateringer og server-komponenter kunne øke ytelsen.
Men som ved de fleste migreringer, oppstod det noen uventede utfordringer. React 18 er strengere ved hydrering enn tidligere versjoner, noe som skapte trøbbel for de tusenvis av grafene og kartene de har på sidene.
Ta en titt på hvordan de løste hydreringsproblemet:
<a href="https://open.nytimes.com/enhancing-the-new-york-times-web-performance-with-react-18-d6f91a7c5af8">Enhancing The New York Times Web Performance with React 18</a>
<h3>Wordpress forbereder seg til React 19</h3>
Migrasjoner er i vinden, for selv til Wordpress (!) har det kommet en migrasjonsguide — mange plugins og temaer er nemlig bygd i React. Fra Wordpress versjon 6.6 brukes React 18.3, og denne versjonen vil advare deg om kode som ikke lenger blir støttet i React 19.
I tillegg til å være en fin migrasjonsguide, er det også et artig blikk på fortiden. Som fersk React-utvikler husker jeg enda hvordan jeg argumenterte for å beholde propTypes i stedet for å bytte til TypeScript. Det eldret ikke veldig godt — for nå skal propTypes fjernes i React 19, sammen med en del andre ting:
<a href="https://kinsta.com/blog/react-19-wordpress/">Preparing for React 19: a guide for WordPress 6.6 users</a>
<h3>Hvorfor bryr vi oss om ytelse?</h3>
Med så mye blod, svette og tårer brukt på migrasjoner, er det viktig å ta et godt steg tilbake, se på det store bildet og reflektere over hvorfor vi legger ned så mye tid i dette: Bedre SEO-score.
Neida. Eller, delvis riktig hvert fall. Googles score er jo et resultat av metrikker som påvirker brukeren, som treg innlastning eller innhold som flytter på seg. Dårlige sider er dårlig for brukerne våre, og skaper friksjon i en allerede stressende hverdag.
Det finnes mange måter å måle ytelse på, og nå har SpeedCurve laget en grundig oversikt. Her kan du lese om hvordan du kan skape en kultur som bryr seg om ytelse, og hvordan du kan forbedre de 3 viktigste metrikkene for bedre Google-score. Etter jeg kjørte forrige ukes Lighthouse-test, er jeg særlig motivert til å forbedre Largest Contentful Paint.
Ta en titt:
<a href="https://www.speedcurve.com/web-performance-guide/">Web Performance Guide | SpeedCurve</a>
Det var alt for denne gang. Ha en super uke!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a02d27bcdbe5" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/forrigeuke-uke-27-%C3%A5r-2024-a02d27bcdbe5">&lt;ForrigeUke uke=”27” år=”2024” /&gt;</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

&lt;ForrigeUke uke=”27” år=”2024” /&gt;

<h3>Slik lager du en tilbakemeldingsknapp med GitHub issues</h3>
For ikke lenge siden var jeg med på å lage et designsystem. For oss var det essensielt å få tilbakemelding om bugs og ønskede funksjonaliteter, så vi ønsket å senke terskelen til å sende innspill. Da tok vi i bruk en genial, liten implementasjon vi oppdaga i NAVs designsystem. Der, på hver side, var det en tilbakemeldingsknapp som sendte deg til GitHub issues …
<figure><img alt="" src="https://cdn-images-1.medium.com/max/794/1*KpxIz-GPfJe1_bOAh-kQ3g.png"><figcaption>Her et eget eksempel på “Send innspill”-knapp</figcaption></figure>… sammen med kontekst fra komponentsiden du var på:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gLcOkEDgSw55QWxWwyaZqQ.png"><figcaption>Ved trykk på tilbakemeldingsknappen havner du inn på GitHub issues, med kontekst fra siden du var på.</figcaption></figure>I denne bloggposten deler jeg med deg hvordan du kan implementere en slik tilbakemeldingsknapp, og også hvordan du kan utvide den.
Før jeg forklarer hvordan knappen fungerer, utfordrer jeg deg til å finne det ut selv, med lenken under (du må være innlogget i GitHub):
<a href="https://github.com/haalmarc/innspill/issues/new?title=Button">SEND INNSPILL</a>
… hint: Ta en titt på URL-en.
<h3>Hvordan det fungerer</h3>
Trikset hviler på at GitHub lar deg sende med kontekst i URL-parameterne.
URL-en du nettopp trykka på lenket til å lage ny oppgave, og med title-parameteret kan du definere oppgavetittel:
<pre>https://github.com/haalmarc/innspill/issues/new?title=Button</pre>
Du kan bruke title-parameteret til å sende med kontekst for oppgaven, for eksempel hvilken side brukeren er på idet hen sender innspill.
Her er et eksempel med JSX:
<pre>&lt;a href={`${GITHUB_REPO}/{nameOfPage}`}&gt;Send innspill&lt;/a&gt;</pre>
I mange tilfeller er title-parameteret tilstrekkelig, men det er også andre parametere du kan inkludere, som labels:
<pre>[repo]/issues/new?title=Button&amp;labels=enhancement</pre>
Test ut lenken her: <a href="https://github.com/haalmarc/innspill/issues/new?title=Button&amp;labels=enhancement">SEND INNSPILL</a>.
Titler og merkelapper er nyttige, men for en enda mer fancy tilbakemeldingsprosess, må vi ty til templater.
<h3>GitHub-template</h3>
Med GitHub-templater, kan du skreddersy hvordan GitHub-oppgavene blir utformet. Bare ta en titt på denne, hvor vi har definert beskrivelse og eget inputfelt:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9rg05MqN1g7c6HB96DTILQ.png"><figcaption>Med templater kan vi legge inn skjemafelter</figcaption></figure>Du kan teste selv med denne lenken: <a href="https://github.com/haalmarc/innspill/issues/new?title=Button&amp;labels=enhancement&amp;template=feedback.yml">SEND INNSPILL</a>.
For å ta i bruk templater, bruker vi parameteren template, hvor vi peker på en fil vi har lagd:
<pre>[repo]/issues/new?title=Button&amp;labels=enhancement&amp;template=feedback.yml</pre>
Vi må også sørge for at templat-filen eksisterer i mappa .github/ISSUE_TEMPLATE.
Slik ser min minimale feedback.yml ut:
<pre>name: Innspill til komponent description: Send inn innspill til komponenten title: "[Innspill til komponent]: " body: - type: markdown attributes: value: | Takk for bidraget! - type: textarea attributes: label: Innspill description: Beskriv funksjonaliten du ønsker eller feilen du har oppdaget.</pre>
Når jeg oppretter GitHub-oppgaven med denne templaten, får jeg ut markdown utifra body-en:
<pre>### Innspill Her er tekst fra textarea</pre>
Her har jeg vist et templat med textarea, men du kan også legge inn assignees, valideringer og dropdowns. Bare sjekk ut GitHubs dokumentasjon: <a href="https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms">https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms</a>
<h3>Konklusjon</h3>
Å senke terskelen for tilbakemeldinger er et viktig steg for å forbedre et produkt. Her har jeg vist hvordan det kan gjøres i kontekst av et designsystem, men jeg er sikker på at det er overførbart til andre settinger også. Prøv det ut!
Takk til NAVs åpne designsystem. Sjekk ut et eksempel på tilbakemelding fra NAVs designsystem her: <a href="https://aksel.nav.no/komponenter/core/combobox">https://aksel.nav.no/komponenter/core/combobox</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=7bd7a9bafe21" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/slik-lager-du-en-tilbakemeldingsknapp-for-github-issues-7bd7a9bafe21">Slik lager du en tilbakemeldingsknapp for GitHub issues</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Slik lager du en tilbakemeldingsknapp for GitHub issues

Webhooks er en metode for å utføre funksjoner når en spesifikk hendelse skjer i en ekstern tjeneste. Denne hendelsen kan være alt fra en slackmelding til en betalingsoppdatering i Stripe. Nylig var jeg med på å lage en sykkelkonkurranse, så her deler jeg om hvordan vi endte opp med å bruke webhooks med Strava.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*Ane8vINLoAseNX9a"><figcaption>Photo by <a href="https://unsplash.com/@willy_teee?utm_source=medium&amp;utm_medium=referral">Will Truettner</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Bakgrunn</h3>
Jeg var nylig med på å lage en sykkelkonkurranse, hvor vi hentet aktiviteter fra Strava og summerte distansen deltagerne syklet.
Her er et skjermbilde fra konkurransen:
<figure><img alt="Skjermbilde av sykkelkonkurranse. Viser at jeg har syklet halvparten av første etappe." src="https://cdn-images-1.medium.com/max/1024/1*grb_xLqporvfzINGGyKIRg.jpeg"><figcaption>Skjermbilde av sykkelkonkurranse. Viser at jeg har syklet halvparten av første etappe.</figcaption></figure>Et stort spørsmål var: “når skal vi summere opp aktivitetene?”.
En første tanke var å summere idet brukeren besøker konkurransesiden. Men da hadde de kanskje ikke syklet siden sist de var innpå siden, og vi får unødvendige kall til Strava. Dette var et problem, siden vi hadde en begrensning i antall forespørsler til Strava per dag. I tillegg var det ikke brukervennlig å summere idet deltageren besøkte siden, på grunn av eventuell lastetid.
For å unngå lenger ventetid idet brukeren går inn, kunne vi i bakgrunnen heller hentet data på forhånd ved visse intervaller, såkalt polling. Så om vi polla hvert 5. minutt for nye data, ville brukeren i verste fall ikke vente så lenge med å se ny progresjon. Denne tilnærmingen hadde derimot ulempen at det kunne bli mange unødvendige kall til Strava. Vi kunne minsket antall kall ved å oppjustere tidsintervallet, som til 1 time, men dette blir igjen ikke brukervennlig. Etter en svett sykkeltur vil jo deltageren vite status med en gang!
Så … Finnes det en måte å vite om deltagerens aktivitet med engang hen har parkert sykkelen?
<h3>Webhooks i praksis</h3>
Det er nettopp dette webhooks er til for; utføre arbeid når en hendelse skjer. Vi kan bruke webhooks til å lytte på nye aktiviteter i Strava.
For å få til lytting på Strava-aktiviteter registrerer vi en lytter fra konkurranseapplikasjonen og til Strava. Så vil Strava fortelle appen vår når en deltager har utført en aktivitet, så vi kan oppdatere deltagerinfo.
<h3>Registrere en webhook</h3>
Registrering av webhooks gjøres vanligvis gjennom en “challenge”. Det innebærer at den eksterne tjenesten sender en forespørsel til deg, og du må svare med riktig melding.
Nedenfor beskriver jeg hvordan du kan sette opp webhooks med en enkel express-server.
Vi må først lage et endepunkt som kan motta challengen:
<pre>app.get("/webhook", (req, res) =&gt; { const queryParams = req.query; if (queryParams["hub.verify_token"] === STRAVA_WEBHOOK_VALIDATION_SECRET &amp;&amp; queryParams["hub.mode"] === "subscribe") { return res.status(200).json({ 'hub.challenge': queryParams["hub.challenge"] }); } return res.status(401).send("Unauthorized"); });</pre>
Her tar vi imot en forespørsel og returnerer visse verdier Strava-challengen forventer for å registrere webhooken.
For å få Strava til å kontakte endepunktet i appen vår, må vi sende en engangs forespørsel til Strava.
Dette kan vi gjøre i Postman eller med curl i terminalen:
<pre>curl -X POST &lt;https://www.strava.com/api/v3/push_subscriptions&gt; \\ -F client_id=5 \\ -F client_secret=7b2946535949ae70f015d696d8ac602830ece412 \\ -F callback_url=http://eksempel-express-server.com/webhook \\ -F verify_token=STRAVA</pre>
Etter challengen er vellykket, vil Strava sende POST-forespørsler til oss hver gang det skjer endringer til Strava-appen vi har registrert.
Vi kan for eksempel lese av deltagerinfo, og oppdatere info hos den aktuelle deltageren:
<pre>app.post("/webhook", async (req, res) =&gt; { const webhookEvent = req.body; await updateCompetitionUser({ athleteId: webhookEvent.ownerId }); return res.status(200).send("OK"); });</pre>
<h3>Filtrere på hendelser</h3>
Det er flere ting som kan trigge et webhook-event, men det er ikke alle eventene vi bryr oss om — eller vi ønsker å gjøre ulike ting avhengig av hva som har skjedd. Dette kan vi lese av på webhook-eventet.
I vårt tilfelle bryr vi oss bare om oppdateringer på aktivitene, så vi kan filtrerere på object_type, som enten er “activity” eller “athlete”:
<pre>app.post("/webhook", async (req, res) =&gt; { const webhookEvent = req.body; if (webhookEvent.object_type === "activity") { 	await updateCompetitionUser({ athleteId: webhookEvent.ownerId }); } return res.status(200).send("OK"); });</pre>
<h3>Kombinere polling og webhooks</h3>
Jeg startet denne bloggposten med å sette polling og webhooks mot hverandre, men de er ikke gjensidig utelukkende. Siden vi ønsket å unngå å treffe Stravas rate-limit, oppdaterte vi ikke deltagernes progresjon direkte, men mellomlagret deltagernes id i en kø-tabell:
<pre>app.post("/webhook", async (req, res) =&gt; { const webhookEvent = req.body; if (webhookEvent.object_type === "activity") { 	await enqueueAthleteId({ athleteId: webhookEvent.ownerId }); } return res.status(200).send("OK"); });</pre>
Så polla vi fra tabellen hvert 5. minutt. Dette gjorde vi med en cron-jobb som kalte et endepunkt og oppdaterte progresjonen for deltagerne i kø-tabellen:
<pre>app.post("/dequeueAthleteIds", async (req, res) =&gt; { const athleteIds = await getAthleteIdsFromQueue(); athleteIds.forEach(async (athleteId) =&gt; { await updateCompetitionUser({ athleteId }); }); return res.status(200).send("OK"); });</pre>
På denne måten unngikk vi at samme deltager ble oppdatert oftere enn hvert 5. minutt, og med webhooks oppdaterte vi kun deltagerne som hadde utført en aktivitet. Begge deler minsket antall forespørsler til Strava. Deltageren måtte i verste fall vente 5 minutter, og det syns vi var en helt grei tradeoff.
For litt bedre brukervennlighet, viste vi også info til deltageren når aktiviteten var i køen, så brukeren fikk bekreftelse på at noe foregikk:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*w4lg1T4m6LVvQ88mRb3yug.png"><figcaption>Vi viste en melding til brukeren om vi hadde registrert aktivitet, men enda ikke oppdatert deltagerens progresjon.</figcaption></figure><h3>Avsluttende ord</h3>
Jeg håper denne posten har hjulpet deg med å forstå litt mer om hva webhooks er. Ved å kjenne til webhooks har du enda et verktøy til å lage hendelsesorienterte applikasjoner, både for å spare trafikk og ikke minst en bedre brukeropplevelse.
For mer detaljer om oppsett av webhooks med Strava, se til deres dokumentasjon: <a href="https://developers.strava.com/docs/webhooks/">https://developers.strava.com/docs/webhooks/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5e0374f803e0" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/hooked-p%C3%A5-strava-slik-bruker-du-webhooks-5e0374f803e0">Hooked på Strava: Slik bruker du webhooks</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hooked på Strava: Slik bruker du webhooks

De fleste applikasjoner krever både henting og oppdatering av data. Tidligere har jeg brukt TanStacks useQuery for enkel lesing av data, men jeg syntes dens motstykke, useMutation, virket vanskelig og komplisert. Derfor har jeg holdt meg til en enkel fetch for mine oppdateringskall. Inntil nå.
Det krever nemlig stor nøyaktighet å få alt riktig med en enkel fetch. Særlig i kontekst av React er det mange utfordringer du må håndtere, og dette fikk jeg erfare med evige loops og opphopning i feil-loggene. Du må selv håndtere loading-state, error-state og race conditions, og det kan være både vanskelig og kreve mye kode å få til.
Dette ga meg motivasjon til å ta fatt på useMutation på ny. Det tar hensyn til mange av bekymringene jeg hadde, og gir i tillegg noen nyttige funksjoner som støtter robust datahåndtering. I denne posten vil jeg lose deg gjennom et nyttig mønster for mutasjoner, samtidig som jeg gjør deg oppmerksom på noen fallgruver du bør kjenne til.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*BRQ80JhYv8agu-ZR"><figcaption>Photo by <a href="https://unsplash.com/@intricateexplorer?utm_source=medium&amp;utm_medium=referral">Intricate Explorer</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Query vs mutering</h3>
Før vi graver dypere i hva useMutation gjør, hva er egentlig forskjellen på en query og en mutering?
En query brukes for å lese data og gjør ingen endringer på serveren. En mutering, derimot, oppdaterer data og gjør en endring på serveren. Dermed vil en funksjon som sjekker om en bruker er innlogget, være en query. En funksjon som logger inn en person ved å lagre et token, vil derimot være en mutering. <a href="https://x.com/tannerlinsley/status/1324384797939003393">Eller som Tanner sier</a>: useQuery er for Read, mens useMutation er for Create, Update og Delete.
<h3>Hvorfor ikke bare bruke fetch?</h3>
I likhet med useQuery, så er det ikke faktisk useMutation som gjør forespørselen. Vi trenger fortsatt fetch eller axios til å gjøre selve forespørselen. Her med et fetch-eksempel som sender med brukerinfo for å logge inn:
<pre>async function logIn(loginInfo: Login): Promise&lt;void&gt; { const response = await fetch('/api/login', { method: 'POST', body: JSON.stringify(loginInfo), }); if (!response.ok) { throw new Error('An error occured'); } await response.json(); }</pre>
Så mates fetch-forespørselen inn i useMutation, og vi får automagisk en rekke fordeler, som å kunne se tilstanden til forespørselen gjennom isLoading og error:
<pre>const { isLoading, error, mutate } = useMutation({ mutationFn: logIn });</pre>
Det er mutate-funksjonen vi bruker til å gjennomføre muteringen:
<pre>function onSubmit() { mutate( { email, password } ); };</pre>
Dette er useMutation i sin enkleste form, men det følger også en rekke andre funksjoner. Med useMutation kan du lett gjøre callbacks, altså funksjoner etter forespørselen er sendt. Dermed har vi også kontroll på hva som skjer etter muteringene, som å navigere til en side etter innlogging:
<pre>const { isLoading, error, mutate } = useMutation({ mutationFn: logIn, onSuccess: () =&gt; navigate("/home"), onError: (error) =&gt; console.error(error) });</pre>
useMutation krever mindre kode, er mer leselig og har innebygd funksjonalitet som tar seg av bekymringer du slipper å tenke på. Derfor er det verdt å bruke dette verktøyet for å lage en mer robust applikasjon.
<h3>Hvordan henger useMutation sammen med useQuery?</h3>
Vi har allerede sett noen likheter mellom useQuery og useMutation, hvor begge gir deg tilgang til forespørselens tilstand. Queries og muteringer er også knyttet sammen på en annen måte: når en oppdatering skjer, må query få vite om det.
Forestill deg følgende scenario:
<ul>
<li>Bruker navigerer til LoginPage, og innloggingsstatus hentes. Bruker er ikke innlogget.</li>
<li>Brukeren klikker på “Logg inn”, så en oppdatering skjer i backend om innloggingsstatus</li>
</ul>
… og her er spørsmålet. Hvordan vet applikasjonen om brukeren er logget inn eller ikke?
<a href="https://blogg.bekk.no/jeg-har-misforst%C3%A5tt-tanstack-querys-cachetime-og-det-har-nok-du-ogs%C3%A5-f6594bc1b5dd">Som jeg skrev om i forrige post</a>, vil ikke useQuery uten videre gjøre et nytt kall til innloggingsstatus, om dataene enda er ferske.
Det vi trenger å gjøre, er å si ifra til query at dataene ikke lenger er valide. Her får vi se en av de nyttige funksjonene til useMutation i aksjon, og det er onSuccess-callbacken:
<pre>const { isLoading, error, mutate } = useMutation({ mutationFn: logIn, onSuccess: async () =&gt; { await queryClient.invalidateQueries({ queryKey: [isLoggedInQueryKey], }); }, });</pre>
Om innloggingen er vellykket, ber vi også om å invalidere dataene om innloggingsstatus. Dette vil utløse et nytt query for å oppdatere dataene. Dette fungerer ofte, men har også en fallgruve du bør være bevisst på.
Koden over mangler ett ord som kan føre til en uventet oppførsel. Det mangler en return.
I eksempelet over gjelder isLoading kun for muteringen, ikke for den nye hentingen av innloggingsstatus. Dette kan føre til at gammel data vises etter muteringen er gjort, så blir dataene refreshet, og ny data vises i UI.
Det vi heller ofte ønsker er at ny data vises i UI med en gang etter muteringen er ferdig. Det kan vi få til ved å returnere promise-et vi får fra invalidateQueries, så isLoading inkluderer prosessen med å gjenvalidere dataene:
<pre>onSuccess: async () =&gt; { return await queryClient.invalidateQueries({ queryKey: [isLoggedInQueryKey], }); }</pre>
Denne kodeendringen sørger for at query-dataene er i sync med muteringen.
<h3>Når ønsker du at callbacks skal skje?</h3>
Vi har allerede sett at onSuccess og onError lar deg kjøre kode etter muteringen har skjedd, men det er noen kodesnutter som kan føre til uventede feil.
La oss se på første kodesnutt igjen, her med navigering ved suksess:
<pre>const { isLoading, error, mutate } = useMutation({ mutationFn: logIn, onSuccess: () =&gt; navigate("/home") });</pre>
Se på dette vanlige scenarioet:
<ul>
<li>Fra logg-inn-siden trykker brukeren på “Logg inn”, som skal navigere hen til HomePage.</li>
<li>Før muteringen er ferdig, så trykker brukeren seg bort til en annen side AboutPage</li>
</ul>
Her er spørsmålet: etter muteringen er ferdig, hvilken underside havner brukeren på?
Med koden over, kan brukeren først komme til AboutPage, men så plutselig bli dratt til HomePage idet onSuccess-funksjonen fullfører.
Årsaken er at kode i onSuccess- parameteret vil skje uansett ved suksess, også om komponenten demounter. Å navigere en person bort, selv om hen ikke lenger er på siden, kan være uønsket oppførsel. Derfor har mutate et annet sted du kan putte callbacks som du ikke nødvendigvis trenger at skal skje.
mutate har to parametere: variables og options. variables er der du sender payload, mens options lar deg definere ulike ting, inkludert en annen onSuccess, som ikke vil kjøre om komponenten demounter:
<pre>const LoginPage = () =&gt; { const { mutate } = useMutation({ mutationFn: logIn, }); function onSubmit() { mutate( { email, password }, // &lt;-- variables { onSuccess: () =&gt; navigate('/home'), } // &lt;-- options ); }</pre>
Ting som du ønsker skal skje uansett, som invalidering av cache, plasserer du i useMutation sin onSuccess. Mens effekter som er relevant for siden du er på, som en toast eller navigering, putter du på mutate sine options. Dermed er det følgende mønsteret du bør kjenne til:
<pre>export const LoginPage = () =&gt; { const { isLoading, error, mutate } = useMutation({ mutationFn: logIn, onSuccess: async () =&gt; { // &lt;-- skjer uansett return await queryClient.invalidateQueries({ queryKey: [isLoggedInQueryKey], }); } }); function onSubmit() { mutate( { email, password }, { onSuccess: () =&gt; navigate('/home'), // &lt;-- skjer ikke ved demount } ); }</pre>
<h3>Konklusjon</h3>
Vi har nå sett hvordan du kan bruke Tanstack Query til å håndtere muteringer med useMutation. Dette abstraksjonslaget gjør koden mer leselig og gir deg bedre kontroll over dataflyten i applikasjonen din.
Her har jeg vist grunnleggende funksjonalitet, men useMutation har også mer avanserte funksjoner du kan leke deg med, som optimistiske oppdateringer og en egen mutation state.
For å forstå hva TanStack Query prøver å forenkle, har uidotdev en fin video om problemene useQuery og useMutation prøver å løse: <a href="https://www.youtube.com/watch?v=OrliU0e09io&amp;list=WL&amp;index=3&amp;ab_channel=uidotdev">https://www.youtube.com/watch?v=OrliU0e09io&amp;list=WL&amp;index=3&amp;ab_channel=uidotdev</a>. For videre fordypning i useMutation, ta en titt på TkDodos post om mestring av useMutation, som mye av denne posten er basert på: <a href="https://tkdodo.eu/blog/mastering-mutations-in-react-query">https://tkdodo.eu/blog/mastering-mutations-in-react-query</a>.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5669575731e2" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/robust-mutering-i-react-unng%C3%A5-fallgruver-i-usemutation-5669575731e2">Robust mutering i React: unngå fallgruver i useMutation</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Robust mutering i React: unngå fallgruver i useMutation

TanStack Query forenkler datahenting i react, men med det følger en drøss med både innstillinger og begreper. To av de mest vanlige begrepene, “staleTime” og “cacheTime”, er også de som har skapt mest forvirring. Sistnevnte fikk et velkomment navnebytte til “gcTime” i siste versjon av TanStack Query, og etter denne posten vil du forstå hvorfor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*TJ9iNwML9YdkMn0i"><figcaption>Photo by <a href="https://unsplash.com/@sammywilliams?utm_source=medium&amp;utm_medium=referral">Sander Sammy</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Svipptur innom staleTime</h3>
Før vi dykker inn i hvordan cacheTime fungerer, la oss klargjøre hva staleTime innebærer. staleTime angir hvor lang tid det tar før data markeres som gammel (stale). Når en query har gammel data, vil nye datahentinger kunne skje.
Det er viktig å forstå at selv med en staleTime på 0, betyr det ikke at det automatisk utføres et nytt nettverkskall med en gang. Nye nettverkskall utføres kun under spesifikke betingelser for å unngå konstante oppdateringer. Disse betingelsene inkluderer:
<ul>
<li>En ny instans av query mounter,</li>
<li>Du bytter tilbake til nettleservinduet,</li>
<li>Nettforbindelsen gjenopprettes, eller</li>
<li>Det er definert et intervall for oppdatering (refetchInterval).</li>
</ul>
staleTime angir altså hvor lang tid det tar før cachet data skal oppfattes som gammel. Hvordan relaterer staleTime seg til cacheTime?
<h3>Navnet cacheTime er misvisende</h3>
La meg teste deg med en liten quiz. Om en useQuery har staleTime på 2 minutter og cacheTime på 5 minutter, når er det cacheTime starter å telle ned?
<pre>const { data } = useQuery({ queryKey: ['currentUser'], cacheTime: 5 * 60 * 1000, staleTime: 2 * 60 * 1000, queryFn: () =&gt; get&lt;string&gt;(url).then((response) =&gt; response.data), });</pre>
Jeg gir deg litt tid til å tenke…
…
…
…
Jeg trodde først det foregikk slik:
<ul>
<li>query mounter og henter data</li>
<li>data markeres som gammel (stale) etter 2 minutter</li>
<li>dataen caches i 5 minutter, og slettes etterpå</li>
</ul>
Her illustrert med et bilde. Finner du noen feil?
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Neo42fvzZVkPzG2YjPZVTg.png"><figcaption>Her illustrert at staleTime og cacheTime teller ned samtidig. Grønn er starttid, rød er sluttid.</figcaption></figure>Om du ikke fant noen feil, har du hatt samme misoppfattelse som meg.
cacheTime er IKKE tiden cachen lagres. cacheTime har gitt så mange misforståelser at det har blitt navngitt til “<a href="https://tanstack.com/query/latest/docs/framework/react/guides/migrating-to-v5">gcTime” fra versjon 5</a>. Dette er en forkortelse for “garbage-collector-time”, som bedre beskriver hva cacheTime/gcTime er: tiden før gammel cache slettes.
En annen måte å se det på, er at cacheTime ikke starter parallelt med staleTime, men heller sekvensielt etter staleTime er ferdig. Det er også verdt å merke seg at oppryddings-timeren ikke starter før query ikke er i bruk.
Her er et mer korrekt bilde:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ZPdX1_AkUwW2S6tT6C0Gxg.png"><figcaption>Her illustrert at cacheTime først begynner etter staleTime er ferdig og query ikke er i bruk. Grønn er starttid, rød er sluttid.</figcaption></figure><h3>Praktisk eksempel på syklusen</h3>
Nå som vi har blitt litt klokere på hva forskjellen mellom staleTime og cacheTime er, la oss ta en titt på et praktisk eksempel.
La oss anta at vi bruker standardverdiene: en cacheTime på 5 min og staleTime på 0. Vi har sidene AboutPage, CompetitionPage og HomePage.
Vi besøker AboutPage, hvor en useQuery med querykey currentUser mounter.
<pre>const { data } = useQuery({ queryKey: ['currentUser'], queryFn: () =&gt; get&lt;string&gt;(url).then((response) =&gt; response.data), });</pre>
Siden dette er første query med nøkkel currentUser, gjør queryen et nettverkskall. Den hentede dataen blir cachet til nøkkel currentUser. Og siden staleTime er 0, vil dataene markeres som gammel med en gang.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*La4bbUOz41qWSYmdmOnUCg.png"><figcaption>Ved query sjekkes cache først, ellers gjøres nettverkskall. Ubrukte queries slettes etter gcTime</figcaption></figure>Videre, når vi navigerer til CompetitionPage, mounter vi på nytt med en querykey currentUser. Siden vi allerede har en nøkkel på currentUser, henter vi umiddelbart cachen fra tidligere. Siden dette er en ny instans av spørringen, utføres et nytt nettverkskall, men dette skjer i bakgrunnen siden det allerede er cache-data.
Når vi så besøker HomePage, som ikke bruker currentUser, vil en ny mekanisme skje. Siden staleTime for lengst er utgått og query ikke er i bruk vil cacheTime begynne å tikke ned. Etter 5 minutter vil den cachede dataen for currentUser bli slettet.
<h3>Konklusjon</h3>
Denne posten handlet om å få et fundament om hvordan staleTime og cacheTime påvirker datahenting i TanStack Query. Det fins mye mer du kan finjustere enn jeg har dekt her, som hvordan initiell data påvirker staleTime og cache, eller hvordan du kan bruke en funksjon for å tidligere sette dataene til stale.
For videre lesing, er <a href="https://tanstack.com/query/latest/docs/framework/react/overview">TanStack Query sin docs</a> et godt sted å starte. <a href="https://tkdodo.eu/blog/practical-react-query">TkDodo har også en finfin blogg</a> om ulike bruksscenarier med TanStack Query og går mer i dybden på ulike temaer.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f6594bc1b5dd" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/jeg-har-misforst%C3%A5tt-tanstack-querys-cachetime-og-det-har-nok-du-ogs%C3%A5-f6594bc1b5dd">Jeg har misforstått TanStack Query's cacheTime, og det har nok du også</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jeg har misforstått TanStack Query's cacheTime, og det har nok du også

<h3>Nye enheter i CSS løser gammel skjermstørrelse-problematikk — Bør du bruke svh, dvh og lvh over vh?</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*iDrh-oRTUOFCH7Y0"><figcaption>Photo by <a href="https://unsplash.com/@sernarial?utm_source=medium&amp;utm_medium=referral">patricia serna</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Når du utformer en nettside, særlig dens hero-seksjon, står du overfor et vanlig dilemma: Hvordan sikre at innholdet strekkes til hele skjermhøyden på alle enheter?
Du har kanskje prøvd ut 100vh (viewport height) for å fylle skjermen. Dette fungerer supert på desktop, men som du sikkert har oppdaga, så er det ikke rett frem på mobil — adressefeltet forstyrrer en perfekt layout.
Kanskje de nye, kule CSS-størrelsene svh, lvh og dvh kan løse problemet?
<h3>svh, dvh og lvh</h3>
svh (small viewport height) gir en størrelse som er det minste versjonen av skjermen, altså med adressefelt. Dermed er denne perfekt til en hero-seksjon, hvor du kan forvente at en person kommer inn fra en annen side, og fortsatt har adressefeltet åpent.
Motsatsen til svh, er lvh (large viewport height). Den antar at adressefeltet ikke er synlig, og vil dermed ta størst mulig plass. I praksis er dette helt likt vh.
dvh kan se ut til å være det beste fra to verdener: den sjekker om adressefeltet er vist eller ikke, og vil dermed få størrelsen til svh eller lvh. Dette høres jo gull ut, men har også en nedside. Siden den beregner størrelse idet du slipper scrollen, kan du få uønskelige layout-shifts ved scrolling. En annen ting er at dvh beregner størrelse, og kan derfor kreve mer ytelse.
<h3>Så hva skal du velge?</h3>
Hva er konklusjonen — skal du alltid gå for svh? Ved hero-seksjoner, elementer som er på toppen av visningen, kan det gi mening å bruke svh, siden adressefeltet mest sannsynlig fortsatt er åpent.
Men i min erfaring er ikke dette nødvendigvis rett for andre elementer. For eksempel ville jeg lage en fullskjerm-modal, og med 100svh så alt bra ut mens adressefeltet var der. Men da jeg scrollet oppover, var ikke lenger adressefeltet der, og det dukket opp et uønsket mellomrom.
Jeg prøvde igjen med 100vh, og aksepterte overflow ved synlig adressefelt. Men så oppdaget jeg at 100vh ikke nødvendigvis oppfører seg på forventet måte i Safari iOS, se for eksempel <a href="https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-mobile-webkit/">Matt Smiths artikkel her</a>. Jeg ble ikke overbevist da jeg så at noen av løsningene fikk det til å fungere på Safari, men introduserte feil på Chrome. Jeg var heller ikke ivrig etter å beregne adressefelt med JavaScript, så jeg så etter andre løsninger.
<h3>dvh gjenbesøkt</h3>
Selv med potensielle ytelse- og layoutshifts, ble jeg da oppfordret til å teste dvh. Til min lettelse så min fullskjerm-modal bra ut på ulike nettlesere, med eller uten adressefelt. Og de fryktede layoutshiftene var lite merkbart av to grunner: bakgrunnen er mindre synlig på grunn av modal-backdrop. Og siden modalen er minst fullskjerm, er det ikke nødvendigvis scrollbar, og dermed ikke noe som kan trigge layoutshifts.
Ytelse var også en bekymring, men i min testing oppdaget jeg ikke noen svakheter. Kanskje dette har årsak i at ofte er det bare én modal som er synlig. Hadde jeg brukt dvh på flere elementer på samme side, kunne det kanskje ha ført til problemer. Det må mer testing til for å finne ut av dette.
Alle disse enhetene er forøvrig godt støttet i ulike nettlesere, se <a href="https://caniuse.com/viewport-unit-variants">caniuse</a>. Du kan også legge til fallback for sikkerhetsskyld:
<pre>height: 100vh; // For backwards compatibility height: 100dvh;</pre>
<h3>Avsluttende ord</h3>
Med nye web-størrelser kommer flere muligheter og flere tradeoffs å ta stilling til. Det er dessverre vanskelig å si at én størrelse alltid er rett, og det trengs testing i ulike scenarier, elementer og enheter for å sikre at oppførselen er som forventet.
Om du vil se mer av disse enhetene i action, har Kevin Powell en fin liten oppsummering av disse enhetene i hans <a href="https://www.youtube.com/watch?v=ru3U8MHbFFI&amp;ab_channel=KevinPowell">YouTube-video</a>.
Hva er din erfaring med disse nye enhetene — har du brukt dvh?
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=cc33f0a71917" width="1" height="1" alt=""><hr>
<a href="https://blogg.bekk.no/nye-enheter-i-css-l%C3%B8ser-gammel-skjermst%C3%B8rrelse-problematikk-b%C3%B8r-du-bruke-svh-dvh-og-lvh-over-vh-cc33f0a71917">Nye enheter i CSS løser gammel skjermstørrelse-problematikk — Bør du bruke svh, dvh og lvh over vh?</a> was originally published in <a href="https://blogg.bekk.no/">Bekk</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nye enheter i CSS løser gammel skjermstørrelse-problematikk — Bør du bruke svh, dvh og lvh over vh?

React server components vinner popularitet for deres ytelsesforbedringer, og det er avgjørende for komponentbiblioteker å holde tritt for å forbli aktuelle.
Men her står vi overfor et paradoks: til tross for viktigheten, er det lite veiledning å finne. Selv i Reacts egen dokumentasjon, er omtalen av <a href="https://react.dev/reference/react/use-client#caveats">hvordan biblioteker kan støtte serverkomponenter</a> diskret plassert som et listet punkt under en vilkårlig seksjon. I denne guiden vil jeg lose deg gjennom prosessen i å transformere et eksisterende komponentbibliotek til å også støtte klient- og serverkomponenter.
<h3>KRÆSJ!</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*7gDXcdOpdxyTG1eTsQH4HQ.png"><figcaption>Denne feilmeldingen sier at vi bruker klientkode i en komponent som ikke er markert som klientkomponent.</figcaption></figure>Jeg ble møtt av denne feilmeldingen da jeg skulle importere en Heading fra komponentbiblioteket mitt inn på hjemmesiden min.
<pre>// Home.tsx import { Heading } from "design-react"; export function Page() { &lt;Heading&gt;Home&lt;/Heading&gt; };</pre>
Dette syns jeg var overraskende. Heading-komponenten var jo en enkel komponent uten noe klientkode, så det burde slettes ikke være noe klaging på klientkode som kjører på serveren.
Hva har gått galt?
<h3>Hva er egentlig problemet?</h3>
Resten av komponentbiblioteket ser slik ut: en enkel Heading-komponent, som brukt over. Og en Button som bruker useState, altså en klientkomponent. Derfor har jeg markert Button-filen med “use client”-direktivet, for å sikre at komponenten behandles som en klientkomponent.
<pre>// design-react // Heading.tsx export function Heading() {} // Button.tsx "use client"; export function Button() {} // index.ts export * from Heading; export * from Button;</pre>
Det ser da bra ut, det?
Heading-komponenten trenger ikke “use client”-direktivet, siden det er en serverkomponent. Og om jeg bruker Button, bør det behandles som en klientkomponent, og ikke forårsake noen ubehagelig feilmelding.
Selv med disse tiltakene, er det to årsaker til at feilen fortsatt oppstår:
Den første årsaken er at klientkode kjører på serveren. Det er kanskje overraskende, ettersom på hjemmesiden importerer vi kun serverkomponenten Heading. Den overraskende realiteten er at Heading er i samme chunk som Button, og hele chunken vil prøve å bli kjørt.
Normalt sett hadde ikke det vært noe problem at også Button kjører, siden Button er markert å kjøre på klienten.
Men så kommer vi til andre årsak til feilen, som er hvordan bundlere håndterer koden. De flytter ofte import-setninger til toppen, som kan skyve “use client”-direktivet nedover i filen. Dette direktivet må være øverst for at komponenten skal anerkjennes som klient-spesifikk. Feilplassering fører til at både klient- og serverkomponenter kjøres på serveren, noe som fører til kræsj.
<h3>Løsningen</h3>
Vi har dermed to årsaker til feilen:
<ol>
<li>én chunk fører til at klient- og serverkomponenter kjøres på samme sted, og</li>
<li>bundleren flytter på “use client”-direktivet, som fører til feil kategorisering av type komponent.</li>
</ol>
Løsningen til dette er å splitte opp klient- og serverkomponenter i hver sin chunk. Og å flytte “use client”-direktivet til toppen av filen.
<h3>Splitte opp chunken</h3>
Ved å splitte opp bundelen er vi sikre på at riktig chunk kjører i riktig miljø. Så vi går fra å ha én index.ts hvor vi importerer alle filer, til å splitte opp importeringen i clientComponents.ts og serverComponents.ts.
<pre>// clientComponents.ts export * from Button; // serverComponents.ts export * from Heading;</pre>
Vi må også si ifra til bundleren at vi nå går fra å ha én entry til å ha to. Jeg brukte Vite/Rollup som bundler, men tilsvarende config finnes også i andre bundlere:
<pre>// vite.config.ts export default defineConfig({ build: { lib: { entry: [ path.resolve(__dirname, "clientComponents.tsx"), path.resolve(__dirname, "serverComponents.tsx") ], formats: ["es"], fileName: (format, name) =&gt; { return `${name}.js`; } }, }, });</pre>
Vi må også oppdatere exports i package.json, så konsumere av pakken kan importere komponenter fra riktig entry:
<pre>// package.json "name": "design-react", "exports": { "./clientComponents": { "import": "./dist/clientComponents.js" }, "./serverComponents": { "import": "./dist/serverComponents.js" } }, "files": [ "dist" ]</pre>
Vi har nå splittet opp kompontenene i ulike chunks, men dette krever en justering for å støtte riktig eksportering av typer.
<h3>Sidespor om TypeScript</h3>
TypeScript genererer en egen typefil for hver chunk: clientComponents.d.ts og serverComponents.d.ts. Ettersom package.json kun støtter å referere til én typefil, er det nødvendig å importere alle komponentene vi bruker til én enkelt fil, her index.ts.
<pre>// index.ts export * from "./clientComponents"; export * from "./serverComponents";</pre>
Dette genererer en typefil index.d.ts som inneholder alle typene våre, og som vi kan referere til i package.json:
<pre>// package.json "types": "./dist/index.d.ts"</pre>
Vi har splittet opp chunkene og justert typene. Som konsumer av pakken, kan jeg nå importere fra rett filsti for å unngå å bli overfalt av en feilmelding:
<pre>// Home.tsx import { Heading } from "design-react/serverComponents";</pre>
MEN vi har bare løst halvparten av problemet. Bruker du en knapp fra clientComponents vil siden kræsje. Vi trenger fortsatt å fikse “use client”-direktivet.
<h3>Legg direktivet i toppen av filen</h3>
For å legge til “use client”-direktivet i toppen av en fil kan vi bruke et verktøy som er tilgjengelig i mange bundlere: banner.
Banner er ofte brukt til å skrive info om lisens for koden, men vil i vårt tilfelle brukes til å legge “use client”-direktivet på toppen av chunken. Faktisk er det dette <a href="https://github.com/chakra-ui/chakra-ui/blob/main/packages/components/tsup.config.ts">komponentbiblioteket Chakra UI bruker</a> for å markere sine komponenter som klientkomponenter.
Vi trenger da å oppdatere bundler-configen. Vi legger til “use client”-direktivet kun for clientComponents-chunken:
<pre>// vite.config.ts export default defineConfig({ build: { rollupOptions: { output: { banner: (chunkInfo) =&gt; { if (chunkInfo.name === "clientComponents") { return "'use client';"; } return ""; } } } }, });</pre>
Nå kan vi også bruke Button-komponenten uten verken et ekstra “use client”-direktiv eller at siden kræsjer.
<pre>// Home.tsx import { Heading } from "design-react/serverComponents"; import { Button } from "design-react/clientComponents"; export function Page() { &lt;&gt; &lt;Heading&gt;Home&lt;/Heading&gt; &lt;Button&gt;Boop&lt;/Button&gt; &lt;/&gt; };</pre>
<h3>Konklusjon</h3>
Vi har nå løst to hovedutfordringer for å støtte React Server Components i et bibliotek. Først oppdaget vi hvordan vi kan dele opp komponenter i separate chunks for klient og server, så vi kjører riktig kode i riktig miljø. For det andre, lærte vi hvordan bruken av “banner”-verktøyet i bundlere kan sikre at “use client”-direktivet forblir øverst i filen, som er kritisk for at det oppfører seg som forventet. Ved å følge disse trinnene, kan også du ta i bruk React Server Components for bedre ytelse.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=e2465ec92a22" width="1" height="1" alt="">

Blogg

Optimistiske oppdateringer i TanStack Query

<ForrigeUke uke=”34” år=”2024” />

<ForrigeUke uke=”33” år=”2024” />

<ForrigeUke uke=”27” år=”2024” />

Slik lager du en tilbakemeldingsknapp for GitHub issues

Hooked på Strava: Slik bruker du webhooks

Robust mutering i React: unngå fallgruver i useMutation

Jeg har misforstått TanStack Query's cacheTime, og det har nok du også

Nye enheter i CSS løser gammel skjermstørrelse-problematikk — Bør du bruke svh, dvh og lvh over vh?

Slik lager du et bibliotek som støtter React Server Components

Blogg

Optimistiske oppdateringer i TanStack Query

&lt;ForrigeUke uke=”34” år=”2024” /&gt;

&lt;ForrigeUke uke=”33” år=”2024” /&gt;

&lt;ForrigeUke uke=”27” år=”2024” /&gt;

Slik lager du en tilbakemeldingsknapp for GitHub issues

Hooked på Strava: Slik bruker du webhooks

Robust mutering i React: unngå fallgruver i useMutation

Jeg har misforstått TanStack Query's cacheTime, og det har nok du også

Nye enheter i CSS løser gammel skjermstørrelse-problematikk — Bør du bruke svh, dvh og lvh over vh?

Slik lager du et bibliotek som støtter React Server Components

<ForrigeUke uke=”34” år=”2024” />

<ForrigeUke uke=”33” år=”2024” />

<ForrigeUke uke=”27” år=”2024” />