Un singur ascultător în loc de câte o componentă client pentru fiecare buton

Iată o secvență care se repetă în aproape orice bază de cod. Un product manager îți cere să urmărești clicurile pe un buton. Butonul este o componentă frumoasă, statică, randată pe server. Așa că adaugi un handler onClick. Pentru a avea un handler onClick, componenta trebuie acum să ruleze în browser — așa că adaugi "use client" (sau apelezi la un hook, ori la un wrapper). Componenta se hidratează. Livrează JavaScript. Și a făcut toate astea nu ca să facă ceva pe client, ci ca să șoptească o singură linie către instrumentul tău de analiză.

Acum înmulțește asta cu fiecare buton, card, link și tab urmărit dintr-un site mare. O felie considerabilă din bundle-ul tău de JavaScript există exclusiv ca să raporteze clicuri. Acest articol este despre alternativă — cea care stă în browser încă din anii 1990 și nu are nevoie de niciun framework: delegarea evenimentelor. Un ascultător mic supraveghează întreaga pagină; componentele tale redevin pur HTML.

Handlerul pe care îl adaugi fără să te gândești

Reflexul pare inofensiv. Ai un link, vrei să știi când e apăsat, așa că îi atașezi un handler:

"use client"; // ← the moment analytics arrives, so does this line

import { track } from "@/lib/analytics";

export function CtaButton({ href, label, place }: Props) {
  return (
    <a
      href={href}
      onClick={() =>
        track("cta_clicked", { place, label })
      }
    >
      {label}
    </a>
  );
}

O linie de urmărire, și componenta întreagă și-a schimbat categoria. Nu mai este marcaj static pe care serverul îl poate transmite și uita — este o insulă interactivă pe care clientul trebuie să o descarce, să o analizeze și să o hidrateze înainte ca acel onClick să existe. Framework-ul nu poate deduce că handlerul este doar telemetrie de tip „trimite și uită”; din câte știe el, această componentă trebuie să fie vie pe client.

Reflexul acela aduce costuri care se cumulează la nivelul unei baze de cod:

• Fiecare componentă urmărită devine o graniță de hidratare — JavaScript descărcat, analizat și executat pentru ceva care nu schimbă niciodată interfața.
• Logica de urmărire este împrăștiată prin sute de componente, fiecare importând SDK-ul de analiză, așa că SDK-ul ajunge în multe bundle-uri.
• Biblioteca de analiză se încarcă pe calea critică, concurând cu randarea pe care utilizatorul o așteaptă cu adevărat.
• „Ce evenimente declanșăm și de unde?” devine un proiect de arheologie — răspunsul este răspândit prin întregul arbore de componente.

De ce ni se pare corect

Merită să fim sinceri în privința motivului pentru care facem asta. Colocarea este un instinct cu adevărat bun: clicul și lucrul pe care vrei să-l înregistrezi despre clic trăiesc în același loc, așa că plasarea apelului de urmărire chiar acolo se citește bine și este ușor de raționat. Framework-urile o întăresc — o prop onClick este modul evident și documentat de a reacționa la un clic, și se întâmplă să tragă hidratarea după sine.

Dar colocarea intenției de a urmări nu cere colocarea codului care urmărește. Poți păstra declarația lângă element — „acest buton este un clic pe un CTA” — în timp ce ascultarea propriu-zisă are loc cu totul în altă parte. Browserul a putut întotdeauna să facă asta; pur și simplu am încetat să apelăm la el odată ce componentele au făcut ca handlerele per element să pară gratuite.

Evenimentele urcă — asta e tot trucul

Când apeși pe un element, browserul nu declanșează doar un eveniment pe acel element. Evenimentul urcă în arborele DOM — de la element, la părintele său, la părintele acestuia, tot drumul până la document. Aceasta este propagarea (bubbling), și înseamnă că un singur ascultător aflat în vârf poate observa clicurile pe tot ce se află dedesubt. Nu ai nevoie de un ascultător per buton; ai nevoie de un singur ascultător care supraveghează documentul și stabilește, la fiecare clic, ce a fost apăsat de fapt.

Instrumentul pentru asta este Element.closest(). Pornind de acolo unde a aterizat clicul — care ar putea fi o pictogramă sau un <span> imbricat în interiorul linkului tău — closest() urcă până găsește un strămoș care se potrivește unui selector. Cere-i cel mai apropiat element care poartă un marcaj de urmărire și primești înapoi exact butonul care a fost apăsat, indiferent de ce se afla direct sub cursor. Această singură primitivă înlocuiește fiecare handler per componentă.

Contractul este un atribut de date

Dacă un ascultător global urmează să gestioneze clicul, singura sarcină a componentei este să declare ce anume ar trebui urmărit — în marcaj, unde un server îl poate randa. HTML are deja mecanismul: atributele data-*. Butonul se descrie pe sine și nu livrează niciun comportament:

// No "use client". No handler. No hooks. Pure server-rendered HTML.
export function CtaButton({ href, label, place }: Props) {
  return (
    <a
      href={href}
      data-track="cta_clicked"
      data-place={place}
      data-label={label}
    >
      {label}
    </a>
  );
}

Nu există niciun "use client", niciun handler, niciun SDK importat — nimic pe care clientul să-l hidrateze. Serverul transmite HTML simplu, iar intenția de urmărire călătorește alături, sub formă de atribute. Iată ce ajunge de fapt la browser:

<!-- What the server sends. The browser needs nothing else to make it work. -->
<a href="/pricing" data-track="cta_clicked" data-place="hero" data-label="Start free">
  Start free
</a>

Un singur ascultător pentru întreaga pagină

Acum comportamentul trăiește într-un singur loc. Un singur ascultător de clic pe document citește marcajul de pe orice a fost apăsat și îl raportează. data-track-ul componentei devine numele evenimentului; restul atributelor data-* devin payload-ul — API-ul dataset ți le predă ca pe un obiect simplu:

// The entire client-side cost of analytics for the whole site.
function handleClick(e: MouseEvent) {
  // Find the nearest tracked element from wherever the click landed —
  // works even if the user clicked an icon or <span> inside the link.
  const el = (e.target as HTMLElement | null)?.closest<HTMLElement>("[data-track]");
  if (!el) return;

  const { track: event, ...data } = el.dataset;
  send(event!, data);
}

export function registerTracking() {
  document.addEventListener("click", handleClick);
}

Îl înregistrezi o singură dată, la pornirea aplicației, înainte de hidratare — astfel încât să supravegheze de la prima randare. Unde se află acel apel depinde de stack-ul tău, dar este întotdeauna un singur apel:

import { registerTracking } from "./track-delegation";

// Next.js: instrumentation-client.ts · Vite/SPA: main.ts · plain HTML: a <script>.
// One call, once, for the entire application.
registerTracking();

Încarcă SDK-ul doar la un clic real

Există aici un al doilea câștig, subtil. Ascultătorul în sine este minuscul — câteva linii, fără dependențe. Partea grea a analizei este SDK-ul, iar cu delegare nu mai ai nevoie de el în timpul încărcării paginii. Poți amâna importarea lui până când chiar are loc primul clic:

// The listener ships ~1 KB. The heavy SDK is pulled only when a real
// click happens — never during page load.
async function send(event: string, data: Record<string, string | undefined>) {
  const { track } = await import("@/lib/analytics"); // code-split, on demand
  track(event, data);
}

Acum kiloocteții furnizorului de analiză sunt complet în afara căii critice. Nimic din urmărire nu concurează cu prima randare; SDK-ul sosește leneș, la cerere, în clipa în care un utilizator interacționează prima dată — iar pentru un utilizator care pleacă fără să dea clic, nu se încarcă deloc.

Detaliile care mușcă

Delegarea clicurilor e ușor de făcut corect în proporție de 90 %, ca apoi să strici experiența utilizatorilor avansați. Un simplu clic-stânga îți revine ție să-l gestionezi, dar un Cmd/Ctrl/Shift-clic sau un clic-mijloc înseamnă că utilizatorul cere browserului să deschidă un link într-un tab nou sau să-l descarce. Dacă ascultătorul tău apelează preventDefault() necondiționat, deturnezi în tăcere acea intenție. Ieși devreme la clicurile modificate sau nonprimare și lasă href-ul nativ al ancorei să-și facă treaba:

function handleClick(e: MouseEvent) {
  // Cmd/Ctrl/Shift/Alt-click and middle-click express a native intent
  // (open in new tab, download). Let the browser handle those untouched.
  if (e.defaultPrevented || e.button !== 0 || e.metaKey || e.ctrlKey || e.shiftKey || e.altKey) {
    return;
  }
  // ...find [data-track], send event
}

A doua capcană este sincronizarea. Dacă clicul navighează în afara paginii, descărcarea acesteia poate anula o cerere de analiză aflată încă în zbor — așa că tocmai clicurile pe care vrei cel mai mult să le măsori sunt cele mai susceptibile de a fi pierdute. navigator.sendBeacon există exact pentru asta: predă un payload mic browserului spre a-l livra în fundal, supraviețuind navigării:

function send(event: string, data: Record<string, string | undefined>) {
  // A click that unloads the page can abort an in-flight fetch. sendBeacon
  // hands the request to the browser to deliver even as navigation happens.
  navigator.sendBeacon(
    "/track",
    JSON.stringify({ event, ...data }),
  );
}

Pentru linkurile interne gestionate de un router pe partea de client, nimic din toate acestea nu se aplică — nu există descărcare a paginii, deci o cerere normală este în regulă, iar ascultătorul delegat stă mulțumit alături de router. Beacon-ul contează pentru linkurile care provoacă o navigare reală, cu reîncărcare completă a paginii. A ști care dintre linkurile tale fac una sau alta este întreaga subtilitate.

Ascultătorul nu trebuie să strice niciodată linkul. Respectă clicurile modificate, folosește un beacon pentru navigări și tratează analiza ca fiind strict „cel mai bun efort” — o eroare de urmărire ar trebui să fie invizibilă pentru utilizator, niciodată un buton mort.

Dincolo de clicuri

Clicurile sunt cazul obișnuit, dar tiparul se generalizează la orice eveniment pe care un ascultător delegat îl poate observa. Un acordeon nativ <details>, de pildă, se deschide și se închide cu zero JavaScript — și tot poți măsura cât de des îl deschid oamenii, fiindcă evenimentul toggle poate fi delegat în același fel. Singura încurcătură: toggle nu urcă (nu face bubbling), așa că asculți în faza de captură:

// The same pattern, a different event. A native <details> accordion needs
// zero JavaScript to open — and one delegated listener to be measurable.
document.addEventListener("toggle", (e) => {
  const el = e.target as HTMLElement;
  if (el.matches("[data-track-open]") && (el as HTMLDetailsElement).open) {
    send(el.dataset.trackOpen!, { ...el.dataset });
  }
}, true); // capture: the toggle event does not bubble

Trimiteri de formulare, schimbări de vizibilitate, redare media — aceeași formă declarativă se aplică. Componenta enunță, în marcaj, ce merită înregistrat; o mână de ascultători globali fac înregistrarea. Suprafața interactivă a paginii tale și observabilitatea paginii tale încetează să mai fie același lucru.

De ce contează asta mai mult acum

Delegarea evenimentelor are decenii de existență, și multă vreme a fost un lucru plăcut, dar opțional — o cale de a atașa un singur ascultător unei liste în loc de o mie. În era Server Components, miza ei este mai mare. Când valoarea implicită este o componentă care se randează pe server și nu livrează niciun JavaScript, un singur onClick nu mai este o eroare de rotunjire: este linia care transformă o secțiune întreagă din HTML static într-o insulă client hidratată.

Delegarea este ceea ce îți permite să păstrezi acea valoare implicită. Analiza — istoric unul dintre cele mai frecvente motive pentru care o componentă pur prezentațională „trebuia” să fie o componentă client — încetează să mai forțeze granița. Secțiuni întregi care aveau nevoie doar să fie urmărite, nu să fie interactive, pot rămâne randate pe server și pot livra nimic. Costul de a observa interfața ta este decuplat de costul de a o hidrata.

Delegare versus câte un handler per componentă, cinstit vorbind

Costul cinstit al delegării este o cantitate mică de disciplină: contractul este acum reprezentat de atribute tipizate „ca șiruri” în loc de un apel de funcție tipizat, așa că o greșeală de tastare într-un nume de data-track eșuează în tăcere, nu la compilare. Un mic helper care construiește atributele dintr-un argument tipizat răscumpără cea mai mare parte a acelei siguranțe, iar un singur ascultător bine tipizat reprezintă o suprafață mult mai mică de ținut sub control decât handlere presărate prin sute de fișiere.

Nimic din toate acestea nu este nou

Dacă asta ți se pare familiar, așa și trebuie. Este exact felul în care au funcționat dintotdeauna managerele de tag-uri și analiza prin autocapture. Google Tag Manager, Segment, PostHog, Heap — sub capotă, atașează câțiva ascultători globali și citesc atribute (sau deduc selectori) de pe orice a fost apăsat. Aproape sigur ai livrat deja acest tipar; doar că ai lăsat un script terț să fie proprietarul lui.

Rostul de a face asta în mod deliberat este controlul și greutatea. Aproximativ treizeci de linii îți oferă aceeași mecanică de delegare fără un script de furnizor pe calea ta critică, fără un autocapture opac care declanșează evenimente pe care nu le-ai intenționat, și cu un contract bazat pe atribute de date pe care îl poți citi, tipiza și testa. Păstrezi ergonomia care a făcut autocapture-ul popular și renunți la taxă.

Concluzii

• Adăugarea unui onClick de urmărire unei componente prezentaționale o promovează în tăcere la o componentă client care livrează JavaScript.
• Nu ai nevoie de un handler per element — clicurile urcă la document, iar closest("[data-track]") recuperează exact ce a fost apăsat.
• Lasă componentele să declare urmărirea cu atribute data-* și păstrează comportamentul într-un singur ascultător global, înregistrat o dată la pornire.
• Importă leneș SDK-ul de analiză în interiorul ascultătorului, ca să rămână în afara căii critice și să nu se încarce niciodată pentru utilizatorii care nu interacționează.
• Respectă clicurile modificate sau nonprimare, folosește sendBeacon pentru navigări și menține analiza la nivel de „cel mai bun efort”, ca să nu poată strica niciodată un link.
• În era Server Components, delegarea este ceea ce oprește analiza să transforme secțiuni statice în insule hidratate.

Niciuna dintre piesele de aici nu este exotică: propagarea evenimentelor, closest(), atributele data-*, un import() leneș și sendBeacon sunt toate funcționalități de platformă banale și bine susținute. Schimbarea stă în locul unde pui comportamentul. Nu mai livra câte un handler de clic cu fiecare componentă, livrează un singur ascultător pentru întreaga pagină și lasă-ți componentele să redevină ceea ce randează cel mai bine — HTML.