Slik får du Disneys strekk-effekt

Dette var uka for å velge kampene dine og kostbare 10x-utviklere — og 2006 ting som skjedde i frontendverdenen!

Hvilke prinsipper gjør web-en mer levende? Bilde av Liana S på Unsplash

12 prinsipper for animasjon

I 1981 kom Disney ut med 12 prinsipper for animasjon. Målet var å gjøre animasjon mer realistisk. Den første regelen "squash & stretch" tar Josh Comeau opp i sin nyeste bloggpost.

Ta en titt på den interaktive bloggposten for å få en følelse av hva du foretrekker selv. Fast animasjon eller mer livlig med en strekk-effekt?

For å få til strekk-effekten viser Comeau en pil som skal indikere interaktivitet. Han gjør ikke pilen bare lenger, men samtidig strammer inn sidene på den.

Rent praktisk får han til effekten ved å dele animasjonen opp i to SVG-er: én SVG for skaftet på pilen som dras ut og én SVG for sidene som blir kortere:

<style>
  @media (prefers-reduced-motion: no-preference) {
    // 👇 Vi har to SVG-er med hver sin klasse
    // Vi har en overgang på plasseringsregelen "d"
    .shaft, .tip {
      transition: d 300ms;
    }
    
    // 👇 Ved hover endrer vi plassering på shaft
    .btn:hover .shaft,
    .btn:focus-visible .shaft {
      d: path("\
        M 5,12\
        h 17\
      ");
    }
    
    // 👇 Ved hover endrer vi plassering på tip
    .btn:hover .tip,
    .btn:focus-visible .tip {
      d: path("\
        M 15,7\
        l 7,5\
        l -7,5\
      ");
    }
  }
</style>

Over ser vi animasjonen kodet med CSS. Som med andre animasjoner er det en tradeoff om du velger CSS eller JavaScript. CSS er mindre støttet på tvers av nettlesere, og i dette tilfellet er det Safari-brukere som får en mindre livlig web. JavaScript gir full støtte, men er mindre optimalisert.

Sistnevnte metode gås gjennom i bloggposten, og Comeau viser også hvordan du kan legge til en fjær-effekt, for å få animasjonen enda mer naturlig.

Anbefaler forøvrig en lesing på wiki for prinsippene. Interessante regler som vi tar for gitt når vi ser ting animert — men kan merke når animasjonen er dårlig.

Vertikale kodebaser

Det er lenge siden jeg har hørt spørsmålet: “har dere egen mappe for komponenter?”. Jeg vet ikke om det har blitt standard å gå en annen vei, eller om AI bare setter opp kodebaser annerledes, men i TkDodos ferskeste bloggpost har vi en god rant om hvorfor det å putte alle komponenter i samme mappe er dumt.

Kort sagt hjelper samlokasjon på kognitiv last. Om du plasserer kode etter hva slags struktur den har istedenfor funksjon, kan du plutselig måtte lete etter kode tilhørende analyse-komponenten i types/analysis.ts, components/analysis.ts og utils/analysis.ts. Og om du jobber i en mappe, er den fylt med funksjonaliteter som ikke har noe med hverandre å gjøre.

Løsningen TkDodo preker for er heller vertikale kodebaser. Ofte kan dette oversettes til å strukturere etter funksjonalitet. En enkel inndeling er å starte med å splitte opp filer i en mappe per route. Om en route har store nok funksjonaliteter, kan en gruppere det i en mappe. Om funksjonaliteter går på tvers, blir det fort en delt mappe.

TkDodo tror at å skape forståelige kodebaser ikke bare hjelper oss mennesker, men også for å få bedre svar fra våre robotvenner. En forståelig kodebase innebærer å ha en strukturert kodebase, gode lint- og TypeScript regler og reliable, raske tester.

Å putte funksjonalitet i riktige filer hjelper på samlokasjon, men fikser ikke avhengigheter. For det trengs grenser. Og i store kodebaser tipser TkDodo om pnpm workspaces, for å avgrense store vertikaler i egne pakker. For eksempel å putte felleskomponenter i et design-system-workspace.

For å høre litt mer på ranten, sjekk ut bloggposten hans: The Vertical Codebase

Server- og komposittkomponenter 

TanStack Start introduserer nå serverkomponenter som en eksperimentell funksjonalitet. Her går TanStack Start en annen retning enn vi er vant med fra Next.js.

I Next.js er vi kjent med serverkomponenter som standardmåten å lage en komponent, så må du legge inn “use client”-direktivet om du skal ha interaktivitet. I TanStack Start derimot, vil du kalle på serverkomponenter som du kaller på annen data. Og derfor kan du til og med bruke TanStack Query for å definere serverkomponenter:

import { createServerFn } from '@tanstack/react-start'
import {
  createFromReadableStream,
  renderToReadableStream,
} from '@tanstack/react-start/rsc'

// 👇 Lag en serverfunksjon
const getGreeting = createServerFn().handler(async () => {
  // 👇 Lag en stream
  return renderToReadableStream(
    // 👇 Her er komponenten din
    <h1>Hello from the server</h1>,
  )
})

function Greeting() {
  const query = useQuery({
    queryKey: ['greeting'],
    queryFn: async () =>
      // 👇 Serverkomponenten kalles via en serverfunksjon
      createFromReadableStream(
        // 👇 Kall på funksjonen vi definerte over
        await getGreeting(),
      ),
  })

  // 👇 Serverkomponenten er data
  return <>{query.data}</>
}

Dette er uvant for meg. Jeg liker enkelheten ved serverkomponenter i Next.js. Samtidig kan det bli en del kluss med caching og annen magi som skjer under panseret. Her har TanStack Start heller gjort det eksplisitt med enkle funksjoner. Og ved å bruke TanStack Query kan vi styre cachingen med et mønster vi er vant med, som staleTime.

Du får til å bruke serverkomponenter i TanStack Start med API-et nevnt over. Men TanStack Start introduserer også noe de kaller “composite components”, hvor du kan bruke en serverkomponent som et skall, så putter du inn slots hvor klientkomponenter tar over. Bloggposten går i detalj hvordan dette ser ut.

Jeg er fortsatt usikker på når hvilken av tilnærmingene skal brukes, men dette blir forhåpentligvis klarere etter funksjonaliteten er offisielt ute.

Om du lurer på hvordan disse rendringsmetodene er i forhold til klient- og serversiderendring forklarer Jack Herrington i en rykende fersk video om 5 måter du kan få til SSR og RSC i TanStack Start, hvor han viser hvordan du får til RSC med og uten komposittkomponenter på slutten: