Profile settings form stays stale after user data loads

[epicdventurer900]

Profile form does not synchronize after the current user loads

Description

The settings profile form initializes its default values from currentUser. The user query loads asynchronously, so the form can remain empty after the user data arrives. After a profile update, the form can also continue displaying stale values until the page is reloaded.

Reproduction

1. Sign in to the application.
2. Open the user settings/profile page.
3. Observe the profile form while the current-user request completes.
4. Update the profile, then revisit the form.

Expected behavior

The profile form should populate when the current user data becomes available and reset to the saved values after a successful update.

Proposed fix

Reset the form when currentUser changes, for example with a React effect that calls form.reset() using the current user's name and email. I prepared this change in my fork, but I will wait for maintainer guidance before opening another pull request.

Related closed PR: #2476

[artur282]

The root cause is in frontend/src/components/UserSettings/UserInformation.tsx:37:

const form = useForm<FormData>({
  resolver: zodResolver(formSchema),
  defaultValues: {
    full_name: currentUser?.full_name ?? "",
    email: currentUser?.email ?? "",
  },
})

defaultValues is only read when the form is created. On first render the /users/me request has not resolved yet, so both fields fall back to ""; when the query resolves, currentUser changes and the form keeps the values it captured at mount. The stale case after an update has the same origin: the mutation's onSuccess calls toggleEditMode() (line 54-56), the user query is invalidated and currentUser changes, but the form instance — and therefore its defaults — is the one built on the first render.

Two fixes, both fine with the versions this repo pins (react-hook-form ^7.84, @hookform/resolvers ^5):

A. Reset when the user changes (what you proposed):

useEffect(() => {
  form.reset({
    full_name: currentUser?.full_name ?? "",
    email: currentUser?.email ?? "",
  })
}, [currentUser, form])

B. Let the form track the value with values, which exists precisely for asynchronous data:

const form = useForm<FormData>({
  resolver: zodResolver(formSchema),
  defaultValues: { full_name: "", email: "" },
  values: {
    full_name: currentUser?.full_name ?? "",
    email: currentUser?.email ?? "",
  },
})

The difference worth deciding on: values re-syncs whenever the object identity changes, so an unsaved edit is discarded if the user query ever refetches while the user is typing (today it does not refetch on an interval, and onSuccess closes the edit mode first, so this is mostly theoretical). Option A only fires when currentUser itself changes and leaves typing alone. A third option, if you want certainty over nuance, is to remount the form from the parent with key={currentUser?.id} — no effect, no stale state, at the cost of dropping in-progress edits on user change.

Worth noting for the PR: this repository asks that PRs only be opened when a maintainer requests one (see tiangolo.com/open-source/contributing and the PR template), which is why #2476 was closed. The change itself is small — one useEffect import plus six lines in a single file — so if a maintainer picks this up here, that is the whole patch.

[epicdventurer900]

Thanks for the detailed explanation, @artur282. That makes the root cause much clearer.

I agree that Option A (form.reset() when currentUser changes) is the better fit here. It keeps the form synchronized with the asynchronously loaded user data while avoiding unnecessary re-syncing that could potentially discard an in-progress edit.

I also appreciate the clarification about the repository’s contribution policy and the maintainer-request requirement. I’ll keep that in mind rather than opening another PR unless a maintainer asks for one.

Thanks again for taking the time to explain both the issue and the trade-offs between the approaches.