Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#160 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
next.js, typescript
領域
frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
3
フォーク
0
平均マージ
12時間 52分
マージ済み PR（30日）
69

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

decdn/website のほかの issue

decdn/website の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。