`getFieldValue` doesn't quite work as per docs

[stevesims]

Describe the bug and the expected behavior

The new "future" getFieldValue function is very useful and helpful, but the example in the documentation when coupled with useFormData doesn't quite work.

Specifically, the datatype of the formData that's passed into the selector function can be null. The example will produce a type error, and will crash on a first-run.

A simplistic coding fix using the current getFieldValue when combined with useFormData is to just detect the null, by doing something like:

  const address = useFormData(form.id, (formData) => {
    if (!formData) {
      return null;
    }
    return getFieldValue(formData, fields.address.name, { type: 'object' });
  });

It would be much nicer tho to be able to use things as per the example in the docs, and not need this check.

A nice added bonus would be to allow the options object to specify a default value to return when the field value cannot be read. Again, one can potentially work around this, but the code becomes slightly inelegant, especially if one wishes to tighten up typing. For example with the current release one needs to do something like:

  const addresses = useFormData(form.id, (formData) => {
    if (!formData) {
      return [] as Addresses[];
    }
    return (getFieldValue(formData, 'path.to.addresses', { type: 'object', array: true, optional: true }) || []) as Addresses[];
  });

It feels like it should be possible to do something a bit more elegant, maybe something a bit like:

  const addresses: Addresses[] = useFormData(
    form.id,
    (formData) => getFieldValue(
      formData,
      'path.to.addresses',
      { type: 'object', array: true, optional: true, defaultValue: [] },
    ),
  );

(altho perhaps one would need to use as Addresses[] instead?)

Conform version

v1.15.1

Steps to Reproduce the Bug or Issue

As per description above, following the example in the docs will produce an error. The code there reads:

  const address = useFormData(form.id, (formData) =>
    getFieldValue(formData, fields.address.name, { type: 'object' }),
  );

What browsers are you seeing the problem on?

No response

Screenshots or Videos

No response

Additional context

No response

[stevesims]

It feels like the fix for the issue should be fairly simple - just add in | null onto the type for the first arg on getFieldValue and just return null if the formData arg passed in is null...

Adding support for specifying a defaultValue is only about making things a little bit nicer to use, but this is all rather subjective.

[edmundhung]

Sorry for the trouble. I should have double check that. Personally I also find the formData being able to be null annoying, it's kind of an edge case to deal with situations where the form is not available (i.e. it can't find the form element from the DOM)

A better solution might be to assume it is available by default and throw if it's isn't, with an option to re-enable the current behavior:

// By default, assume form element is available, throw if not
useFormData(formRef, formData => ...)
//                   ^? FormData

// Opt-in to accept optional form element
useFormData(formRef, formData => ..., { optional: true })
//                   ^? FormData | null

What do you think?

[edmundhung]

My previous suggestion doesn't work as it would then throw an error during SSR.

An alternative would be to make useFormData returns undefined when the form element is not available and the selector will run only when it is there. But that means the result might be undefined. (#1142)

[stevesims]

hey @edmundhung sorry it's taken me a while to get back to you - been having a very busy time at work

as you pointed out, your previous idea would have thrown in SSR - and I think it'd probably also throw on first-render too...

the direction you've taken of having useFormData only call the selector when there is form data available seems very sensible to me. this is, essentially, solving the underlying problem, rather the symptom I had identified

it's a much nicer and more elegant solution than the more convoluted ideas I had suggested above 😀