Når et prosjekt vokser, blir det farlig å la hver knapp lage sin egen fetch-logikk og sin egen ruting. Fetch-klienten og side-rutingen bør skilles fra hverandre.

Fetch-klient og side-ruting
Fetch-klient og side-ruting visualiserer hovedpoenget i artikkelen.

Fetch-klienten bør håndtere transport

En fetch-klient bør vite hvordan forespørsler sendes, hvordan JSON tolkes, hvordan feil normaliseres, og hvordan felles headers eller CSRF-token håndteres.

Ruting bør håndtere sted

Side-rutingen bør vite hvilken URL brukeren står på, hvilken visning som skal oppdateres, og hvordan tilbakeknapp og delbare lenker skal fungere.

Blanding gir skjør kode

Hvis hver side både bygger URL, sender request, tolker feil og oppdaterer historikk, får prosjektet mange små varianter av samme problem. Det gjør feilretting tyngre.

History API krever serverforståelse

Når JavaScript oppdaterer URL-en, bør serveren også kunne vise samme URL direkte. Ellers fungerer ikke deling, reload og crawling godt nok.

WEBoracle-vurdering

WEBoracle bør ha en enkel felles fetch-hjelper og en separat rutelogikk. Scripts, articles, tutorials og forum kan da gjenbruke samme mønster uten at hver modul finner opp sin egen AJAX-variant.

Konklusjon

Et voksende prosjekt trenger tydelige grenser. Fetch-klienten henter og normaliserer svar. Rutingen bestemmer sted og visning. Når dette skilles, blir hybrid PHP/AJAX enklere å vedlikeholde.

Kilder og videre lesning

  1. MDN Web Docs: Using the Fetch API
  2. MDN Web Docs: History API
  3. MDN Web Docs: Response