[ds-boyce]

Classic React Native…

[github-actions]

Old size	New size	Diff
7.76 MB	7.76 MB	78 B (0.00%)

---

[mozzius]

@claude pls review

[claude]

Claude finished @mozzius's task in 40s —— View job

---

Code Review

• Read PR diff and surrounding code
• Analyze the fix for correctness
• Post review

---

Nice, focused fix. The root cause is the classic React Native footgun: a value-controlled TextInput on the old architecture re-renders on every keystroke and resets the caret to the end. Switching to defaultValue (uncontrolled) is exactly what this codebase prefers (see CLAUDE.md "Controlled vs Uncontrolled Inputs"), and the key={inputKey} remount handles the fact that the native bottom sheet keeps its children mounted between opens so an uncontrolled input wouldn't otherwise re-seed. The doc comment on the inputKey prop is clear and explains the why well. 👍

A few small observations, none blocking:

1. value now serves a narrower role - worth keeping in mind
After this change, value no longer drives the input contents; it's only used for the nameTooLong validation and is fed by onChangeText={setNewGroupName}. That's correct, but the prop name value reads as if it's the input's value. Not worth churn now, but if you wanted to be extra clear you could rename it to something like currentValue to signal it's the live validation value rather than the seed. Optional.

2. All open paths are covered
Both onPress handlers (the Pressable title at index.tsx:495 and the SettingsButton at :545) now route through openEditNamePrompt, and that's the only place editNamePrompt.open() is invoked, so the key bump + reseed happens on every open. Good - no stale-value path left behind.

3. Error reset relies on the next remount
In the onError handler (index.tsx:379) you setNewGroupName(groupName). Since the input is now uncontrolled, that state reset won't visually revert the field on its own - but the prompt is already closed at that point and the next open bumps inputKey, so the field reseeds correctly. Just confirming the behavior is intentional and fine.

4. Web is unaffected
On web the dialog unmounts its children on close, so the key bump is harmless/redundant there - no downside.

Overall this looks correct and minimal. LGTM.
· d/chat-edit-name

[linear-code]

APP-2391