Auto-focus answer input in typing practice mode

[mucsi96]

Summary

Auto-focus the answer input field when each card is displayed in typing practice mode, eliminating the need for users to click before typing their answer.

Changes

• Added viewChild reference to the answer input field in LearnSimpleCardComponent
• Implemented an effect that automatically focuses the answer input whenever a new card is loaded
• Updated the template to expose the input element via template reference variable #answerInput

Implementation Details

The focus behavior is triggered by an effect that watches for card changes. When a new card is displayed (detected by accessing this.card()?.value()), the effect automatically calls focus() on the answer input element. This provides a seamless typing experience where users can immediately start typing without an extra click.

https://claude.ai/code/session_01GQQE5BSowYj6kkiSygSWhv

[claude]

Review

Small, well-scoped change. The auto-focus behavior is implemented idiomatically using Angular signals (viewChild + effect), matching the existing clearTypedAnswerOnCardChange pattern in the same component, and the new e2e test follows the repo's Playwright conventions (role-based selectors, no assertion messages).

Code quality

• focusAnswerInput effect (learn-simple-card.component.ts:96-99) is clean and consistent with the sibling clearTypedAnswerOnCardChange effect right above it.
• Good test design: using page.keyboard.type(...) instead of answerInput.fill(...) actually proves the field is focused without a click — .fill() would have focused the element itself and masked a regression.

Minor observations (non-blocking)

1. Implicit reactive dependency: the effect only explicitly reads this.card()?.value(), but it also re-fires when the input re-enters the DOM after isRevealed() flips back to false, because that's what causes answerInput() (the viewChild signal) to go from undefined to defined. That's correct, but the connection to isRevealed isn't obvious from reading the effect body alone — a future reader might not realize why this reruns on reveal/un-reveal transitions, not just on card change. Worth a short comment if you want to save the next reader some head-scratching.
2. Focus stealing after button activation: after the user clicks "Correct"/"Wrong" to advance, focus immediately jumps to the new answer input, away from the button that was just activated. For mouse users this is the intended seamless-typing UX, but for keyboard/screen-reader users it's an unannounced context change right after activating a control. Probably fine given this is an opt-in "typing practice" mode, but worth a conscious call rather than an oversight.
3. Test coverage duplicates a fair amount of createSource/createCard boilerplate from the neighboring "lets the user type the answer" test, but that matches the existing convention in this spec file, so not a new issue.

Bugs / security / performance

Nothing found. No backend changes, no risk of null-deref (?. used correctly throughout), focus() is cheap and side-effect-free w.r.t. other signals, so no risk of effect loops.

Overall: looks good to merge once the accessibility trade-off in point 2 is a conscious decision rather than an oversight.