<ForrigeUke uke="19" år="2025" />

Ny måte å skjule komponenter i React og MCP endrer hva vi forventer i AI-interaksjoner — i denne ukas ForrigeUke.

Dette var uka for speeddating med AI og trikkefaktor — og 1502 ting som skjedde i frontendverdenen!

Den nye måten å skjule komponenter

Hvordan kan du i React raskt bytte mellom ulike grensesnitt, som for eksempel ulike faner med ulike grafer?

Historisk har vi hatt to måter å gjøre dette: 1) en logisk if-setning, som kan se slik ut:

function GraphSwitcherTernary({ activeGraph }) {
  return (
    <>
      {activeGraph === 1 ? <Graph name="Graph 1" /> : null}
      {activeGraph === 2 ? <Graph name="Graph 2" /> : null}
      {activeGraph === 3 ? <Graph name="Graph 3" /> : null}
    </>
  );
}

Eller 2) CSS-regelen display: none, som kan se slik ut:

function GraphSwitcherCSS({ activeGraph }) {
  return (
    <>
      <div style={{ display: activeGraph === 1 ? 'block' : 'none' }}>
        <Graph name="Graph 1" />
      </div>
      <div style={{ display: activeGraph === 2 ? 'block' : 'none' }}>
        <Graph name="Graph 2" />
      </div>
      <div style={{ display: activeGraph === 3 ? 'block' : 'none' }}>
        <Graph name="Graph 3" />
      </div>
    </>
  );
}

Disse alternativene har hver sine fordeler og ulemper. Med if-setning skjer en full unmount/mount mellom logikk-endring. Da får du en full re-render og tilbakestilling av tilstand når du viser komponenten igjen, som kan føre til det tar noe tid før alt vises igjen.

Med CSS kan du få komponentene til å skjules, men datahåndteringen foregår fortsatt i bakgrunnen. Dermed vil komponentene kunne vises raskt med rett betingelse. Nedsiden er at bakgrunns-kjøringen kan hope seg opp med mange komponenter, og føre til dårlig ytelse i appen.

Nå har React prøvd å løse dette problemet med en ny, eksperimentell komponent kalt "Activity". Dette er en slags mellomting fra alternativene over. Komponentene vil skjules i bakgrunnen, men ikke fullt unmountes. For å bevare tilstand legges komponentene i en såkalt "lavprioritets-kø", så de får fortsatt oppdateringer i bakgrunnen. Så når rett betingelse inntreffer for å vise dem, vil de raskt vises. Dette gir høyere ytelse og bedre brukeropplevelse. Det kan se slik ut:

function GraphSwitcherActivity({ activeGraph }) {
  return (
    <>
      <Activity mode={activeGraph === 1 ? 'visible' : 'hidden'}>
        <Graph name="Graph 1" />
      </Activity>
      <Activity mode={activeGraph === 2 ? 'visible' : 'hidden'}>
        <Graph name="Graph 2" />
      </Activity>
      <Activity mode={activeGraph === 3 ? 'visible' : 'hidden'}>
        <Graph name="Graph 3" />
      </Activity>
    </>
  );
}

Med denne tilførselen av komponent, tenker jeg du nå kan glemme å bruke CSS-alternativet. Om du trenger å "holde en komponent varm", som med snappy grafer, er “Activity”-komponenten et godt alternativ. Mens for lette komponenter, som om du skal betinget vise en enkel knapp, går det fint å fortsette med gode gamle if-setningen.

For mer informasjon, har Jack Herrington sett nærmere på ytelsen på alternativene i følgende video: https://youtu.be/gRKVL5w-2Lc?si=h1NiTWfg51tUB30B

Fremtiden til AI-interaksjon er mer enn tekst

Model context protocol (MCP) er i vinden og det endrer hvordan vi snakker med applikasjoner. Bare den siste måneden har Supabase, Sanity og GitHub fått MCP-støtte. Forrige uke fikk shadcn også støtte for MCP, noe som kan gjøre det enda enklere for oss å ta i bruk ferdige komponenter.

React-legenden Kent C. Dodds tror MCP kommer til å endre hvordan vi snakker med AI. Men før vi går inn på hva han tror, hva er egentlig MCP?

Hva er MCP?

Det finnes mange kilder som forsøker å forklare hva MCP er, men den mest nyttige jeg kom over var IBMs sammenligning mellom API-er og MCP: https://www.youtube.com/watch?v=7j1t3UZA1TY&ab_channel=IBMTechnology

Kort sagt er API-er et grensesnitt ment å bli brukt av utviklere. Et API tilbyr informasjon og funksjonalitet uten at du trenger å vite detaljene til de underliggende tjenestene. AI-tjenester kan snakke med vanlige API-er. Men mer effektivt er det å legge et ekstra abstraksjonslag rundt API-et, som gjør at LLM-er enda lettere kan forstå API-et. Det er altså dét MCP er — et standardisert lag rundt API-er for at LLM-er lettere skal forstå innholdet.

Ofte brukes MCP-støttede tjenester av AI-agenter, altså AI-programmer som jobber uten at du trenger å gi nye instruksjoner for hver handling agenten skal gjøre. En kul egenskap ved MCP er at med MCP tilgjengliggjør du et dokument som sier hva tjenesten tilbyr, som gjør at AI-agenter selv kan finne ut av hvilke tjenester den trenger å bruke, såkalt “self discovery”.

Det fins mer brukervennlige grensesnitt enn tekst

MCP endrer hvordan vi bygger apper. I 2024 demonstrerte utvikler Evan Bacon hvordan han i React native kunne spørre en AI-chat om en liste av filmer, og istedenfor å få en topp-10-liste av filmer i tekst, fikk han en mini "IMDB"-app rett inn i chaten. Dette var mulig for det ble streamet inn React serverkomponenter. For å få til demonstrasjonen måtte Bacon skrive mye kode som hensyntok de ulike spesifikasjonene av tjenestene Bacon benyttet seg av. Men med entréen av MCP tror Kent C. Dodds at dette kommer til å endre seg.

Siden MCP gjør tjenester mer tilgjengelig for LLM-er, kan vi forvente mer av AI-chater. Vi kommer ikke lenger til å forvente bare tekst, men noe som er enda mer brukervennlig. Hvilken form dette kommer i, kan avhenge av brukerens spesifikke scenario. Som at du spør om en stoppeklokke, og får en start- og stopp-knapp. Eller du spør om veibeskrivelse, og får en 3D-figur av bygningen du navigerer i.

Ta en titt på Dodds tanker her: https://www.epicai.pro/the-future-of-ai-interaction-beyond-just-text-w22ps

👋 Det var alt for denne gang. Ha en riktig fin uke!