Fix PageTitleInput reset on wiki site change

[Wintus]

Summary

Fixes PageTitleInput state not resetting when users switch wiki sites (e.g., en.wikipedia.org → ja.wikipedia.org).

Problem

When the wiki selector changed, PageTitleInput retained stale state:

1. pageTitle (useState) — didn't re-initialize (React reused component instance)
2. debouncedTitle (useDebouncedValue) — carried over from old wiki
3. ErrorBoundary — stuck errors persisted if title text hadn't changed (resetKeys was [debouncedTitle] only)

TanStack Query already handled re-fetching correctly via queryKey: ['pageId', wikiUrl.href, pageTitle] — no changes needed there.

Solution

Added key={wikiUrl.href} to <PageTitleInput> in SearchForm.tsx.

This is React's documented pattern for "resetting all state when a prop changes." When the key changes, React unmounts the old instance and mounts a fresh one, resetting all internal state to initial values.

Why This Approach

Option A (chosen): key={wikiUrl.href}

• Fixes all three issues with zero code changes inside PageTitleInput
• React-recommended pattern
• Clear, declarative intent

Option B (rejected): Add wikiUrl.href to ErrorBoundary resetKeys

• Would fix error boundary (issue 3) only
• Still need useEffect or similar for issues 1 & 2
• React docs discourage this pattern in favor of key

Testing

• Added regression test: "resets page title input when wiki site changes"
• Test passes with key={wikiUrl.href} ✓
• Test fails without the key (regression guard confirmed) ✗
• All 71 tests pass

Test Plan

• Automated tests pass
• Manual verification: Type a title, switch wiki site, confirm input resets
• Verify error states clear when switching wikis

Co-Authored-By: Claude

[claude]

Pull Request Review

Summary

This PR fixes a bug where PageTitleInput state wasn't resetting when users switched between wiki sites. The solution uses React's key prop pattern to force component remounting—clean, idiomatic, and well-tested.

---

✅ Strengths

1. Correct Solution Pattern

Using key={wikiUrl.href} is the React-recommended approach for resetting component state when a prop changes. This is superior to alternatives like adding useEffect hooks (imperative, more complex), manually managing reset logic (error-prone), or just adding to ErrorBoundary resetKeys (only partial fix).

2. Excellent Test Coverage

The new test at line 332-360 is well-structured with clear arrange-act-assert pattern, tests the actual user-facing behavior (input value resets), has good inline comments explaining the expected behavior, and verifies the bug is fixed without over-specifying implementation details.

3. Comprehensive Problem Analysis

The PR description clearly documents all three issues being fixed (useState, useDebouncedValue, ErrorBoundary), why this approach was chosen over alternatives, and how TanStack Query's queryKey already handled the re-fetch correctly.

4. Code Consistency

The pattern is already used elsewhere in the codebase at SearchForm.tsx:65 and WikiSelector.tsx:23.

5. TDD Approach

The commit message indicates the test was written to verify the fix and can catch regressions—excellent practice aligned with the project's TDD requirements.

---

💡 Minor Observations

1. Duplicate Test Name (Lines 407, 422)

There are two tests with identical names in SearchForm.tsx. While the implementations differ, having duplicate test names can make debugging harder when a test fails. Consider renaming the second test to something like "updates radio button defaultChecked on searchState change".

2. Test Pattern Consistency

The test at line 308-330 already tests wiki selector changes using the same fireEvent pattern. The new test is valuable and distinct, but consider extracting shared logic if more similar tests are added in the future.

---

🔍 Code Quality Assessment

• Correctness: ✅ Excellent - Fixes all three stated issues with one elegant line
• Best Practices: ✅ Excellent - Uses React's documented pattern for state reset
• Test Coverage: ✅ Excellent - Regression test included, all tests pass
• Performance: ✅ Good - Component remount has minimal cost; only happens on wiki change
• Security: ✅ N/A - No security concerns
• Maintainability: ✅ Excellent - Simple, declarative, easy to understand

---

Recommendation

APPROVE ✅

This is a high-quality fix that solves the stated problem elegantly, uses React best practices, includes proper test coverage, and follows the project's functional programming style and TDD workflow. The duplicate test name is a minor nit that can be addressed in a follow-up if desired, but it doesn't block this PR.

The fix demonstrates good understanding of React's reconciliation algorithm. By changing the key prop when wikiUrl.href changes, React treats it as a different component instance, unmounting the old PageTitleInput (cleaning up all state, timers, error boundaries) and mounting a fresh one with initial props. This requires zero changes inside PageTitleInput itself—a testament to good component design and separation of concerns.

Nice work! 🎉