Specifying a defaultValue in GET forms that also have lastResult

[transparent-citizen]

If you return both defaultValue and lastResult from a loader to a GET form, lastResult will overwrite defaultValue.

Reproduction: StackBlitz

[transparent-citizen]

Does it even make sense for GET forms to have a defaultValue?

Navigating to a GET form is equivalent to submitting it. The form might have errors, for which you're expected to specify lastResult. But since there could be errors in the initial submission, even the initial submission might need lastResult. And since lastResult is also used to set the form value, what's the point of defaultValue in a GET form?

[transparent-citizen]

Even if you use lastResult just to pass errors to a GET form without providing new field values, the values are overwritten with empty strings: StackBlitz

[edmundhung]

That's expected. It is part of the progressive enhancement behavior where Conform will persist your previously submitted form value even if the document reloaded.

As I explained in #1099 (comment), Conform is modeled mainly for POST form. So some behaviors might not make sense here.

What do you think the behavior should be? I am too used to the current design, so if you have any suggestions, let me know.

[transparent-citizen]

defaultValue and lastResult make sense in the mental model of non-idempotent HTTP methods like POST or PUT, because they model two distinct form states:

• the initial state before the user submits, and
• the state after the user submits.

With GET forms, the initial state is completely identical to the state after submission, so providing them both is meaningless.

This could be a type error:

useForm({
  method: "GET", // hypothetical
  defaultValue,
  lastResult
}) // ❌

while these would be okay:

useForm({
  method: "GET", // hypothetical
  defaultValue,
}) // ✅

useForm({
  method: "GET", // hypothetical
  lastResult,
}) // ✅

What do you think the behavior should be?

I was expecting that providing lastResult that doesn't contain a targetValue would only apply form errors and field errors, but keep the form values unchanged. To me, setting targetValue in report expresses that the form should be updated to a new value. That's why seeing it update without me specifying a targetValue was a surprise.