test: replace hash scroll source snapshot#532
Conversation
📝 WalkthroughWalkthroughThis PR refactors session message navigation logic by extracting hash scroll implementation from the ChangesSession Hash Scroll Core Extraction & Hook Refactoring
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request refactors the session hash scrolling logic by extracting the core functionality into a new file, use-session-hash-scroll-core.ts, decoupling it from the router implementation now handled in use-session-hash-scroll.ts. The update includes a new comprehensive test case for hash navigation. I have no feedback to provide as there were no review comments.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/app/src/pages/session/use-session-hash-scroll-core.ts`:
- Around line 97-100: The handler currently always invokes
input.onMessageNavigation in scrollToMessage even when the target was already
resolved by applyHash; change the logic to only call input.onMessageNavigation
(and input.setActiveMessage) when the message is not already the current one by
checking input.currentMessageId() !== message.id. Apply the same conditional
suppression in the analogous block referenced around lines 133-139 so both
places only fire input.onMessageNavigation when switching to a different
message.
In `@packages/app/src/pages/session/use-session-hash-scroll.test.ts`:
- Around line 124-127: The test currently asserts that navigationCalls contains
["msg_2"], but the desired behavior is that direct hash scrolling for an
already-rendered target must not trigger onMessageNavigation; update the
assertion for navigationCalls (in use-session-hash-scroll.test.ts) to expect no
navigation calls (e.g., expect(navigationCalls).toEqual([]) or
expect(navigationCalls).toHaveLength(0)) so the test fails if fallback
navigation is reintroduced; keep the other assertions (scrollPositions,
activeMessages, markedTargets) unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: b1c74790-cde7-4993-bf39-cc02fc7eee57
📒 Files selected for processing (3)
packages/app/src/pages/session/use-session-hash-scroll-core.tspackages/app/src/pages/session/use-session-hash-scroll.test.tspackages/app/src/pages/session/use-session-hash-scroll.ts
|
CodeRabbit review threads resolved without changes. Both suggestions interpret the desired behavior as zero |
Summary
useSessionHashScrollinto a small router wrapper pluscreateSessionHashScrollcore so the behavior test can run inside the full Bun unit suite without@solidjs/routermodule-cache leakage.Why
#528 tracks a Windows advisory failure caused by a test reading source text and matching an LF-only implementation snippet. Normalizing CRLF would only hide the platform symptom while keeping the test tied to source formatting.
This PR moves the tested behavior behind a router-free core and verifies the contract directly: an already-rendered hash target scrolls to the message, marks it active, marks the hash target, and does not emit duplicate fallback navigation.
Related Issue
Closes #528.
Human Review Status
Pending. A human should make the final merge decision after reviewing the final diff and verification evidence.
Review Focus
useSessionHashScrollremains only a router wrapper aroundcreateSessionHashScroll.Risk Notes
Low. This is a test-debt PR with one internal extraction. The main risk is accidental behavior drift during the move; that is covered by app full unit tests, app typecheck, the targeted behavior test, and a temporary red check for duplicate navigation.
CodeRabbit suggested changing the expected navigation callback count from one to zero. That was not applied because the single
onMessageNavigationcall is the target-message intent used byuse-session-timeline-interactionto cancel bottom-follow lock. The regression guard is about preventing a second fallback notification after direct already-rendered scrolling.How To Verify
Commands run:
Screenshots or Recordings
None. No visible UI changes.
Checklist
dev, and my PR title and commit messages use Conventional Commits in English