Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

refactor(nav): unify section-id vocabulary + make off-route detection explicit

Aperta
  • Qualcosa non va?
#160 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
next.js, typescript
Ambito
frontend

Direzione di ricerca

Read lib/scroll.ts, components/site/Chrome.tsx, and components/site/MobileMenu.tsx, then trace how section IDs and route checks are used in both navigation paths. Decide how to centralize the section ID types and distinguish a route mismatch from a missing target. Done when both proposals are handled explicitly and the navigation behavior is covered by tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement future med-priority revisit

Follow-up from the PR #159 review (fix #157). Two related, non-blocking improvements deferred out of that bugfix's scope.

1. Unify the section-id vocabulary

"intro" and the section-id set are currently declared in three unrelated places with no compile-time link:

  • lib/scroll.ts — HOME_SECTION_ID = "intro"
  • components/site/Chrome.tsx — SECTION_IDS = ["intro", "compare", "method", "faq", "contact"]
  • components/site/MobileMenu.tsx — type SectionId = "intro" | "compare" | ...

Renaming the hero section id today means editing three files in lockstep with no type error to catch a miss.

Proposal: export a single SectionId union + SECTION_IDS tuple from lib/ (e.g. lib/scroll.ts or a sibling), import it in both components, and define HOME_SECTION_ID as a member of it. HomeNavTarget's section.id could then narrow to Exclude<SectionId, typeof HOME_SECTION_ID>. Touches the active-section observer typing in Chrome.tsx, so it's a deliberate refactor rather than a one-liner.

2. Make the off-route discriminator explicit

Both nav codepaths decide "am I off-route?" by element absence:

  • components/site/Chrome.tsx:70 — if (document.getElementById(HOME_SECTION_ID) === null) return;
  • components/site/MobileMenu.tsx cleanup — if (anchor && !targetEl) window.location.assign(...)

Correct today because every nav target is a synchronously-rendered home section and the Hero always mounts on /. But the check can't distinguish "wrong route" from "right route, target not mounted": a future lazy/Suspense-mounted target tapped on the home page would be misread as off-route and silently hard-reload (and the desktop return path could become a no-op dead-click if the Hero ever failed to mount).

Proposal: key the off-route branch on actual route mismatch (e.g. via usePathname(), already used in Chrome.tsx) rather than element absence, and/or extract a small testable isOnHomeRoute() / resolveLocalTarget() helper so the off-route-vs-missing distinction is explicit and unit-testable.

Both surfaced by the multi-agent review on #159; neither is a live bug.

Lingua principale
TypeScript
Stelle
3
Fork
0
Merge medio
12h 52m
PR unite (30g)
69

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di decdn/website

Tutte le issue di decdn/website

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.