RFC: async defaultValues

[bluebill1049]

Context

The current status of setting defaultValues from async data source is using reset:

useEffect(() => {
  reset({
     firstName: 'test',
  })
}, [reset]);

honestly, this is probably not a pretty and clean approach... a few weeks before we had a feature request regarding async defaultValues: #2335

Proposal Solutions

Option A

defaultValues accept Promise, and the promise will get resolved, although I do have concern over the confusion about which prop supports both object and Promise.

What's happening here:

• promise will get resolved
• reset API will get invoked to reset the form and hence provide reset options

const { formState: { isLoading } } = useForm({
  defaultValues: async () => {
    return {
      values: { firstName: 'test' },
      resetOptions: {
        keepDirtyValues: true,
      }
    }
  }
})

---

Option B

• Reactive values for form values update
• Supplied with reset option to refine form values update behaviour

const { data: values } = useQuery/useSWR()

useForm({ 
  values
  resetOptions: {
    keepDirtyValues: true,
  } 
})

happy to discuss more options on the table too.

Update 27/10/2022: going to update and support both values and async defaultValues

POC

PR: #9052

cc @leapful @Moshyfawn

[JeromeDeLeon]

With async defaultValues, we are expecting it to do any asynchronous task right? So what if you rely on something else to trigger the defaultValues fetching? Like props? How would would I do that? Still I would need to rely to this reset + useEffect convention. Correct me if I'm wrong with all my understanding because that's how I see it. It really feels to me that I would still need to comeback to that approach.

[pmaier983]

I think this is a great idea. During my day job we work with large data sets, and we have specific queries to get available data for dropdown fields. If this was implemented it would pave the way to have a loading indicator and then some dropdown field all built without a Controller.

The Async Promise seems like the best way forward (to me).

[bluebill1049]

Thanks @JeromeDeLeon I think you can pass arguments into that Promise callback.

useForm({
  defaultValues: async (args) => {
    if (args.test) { return { data: 'test' }; }
  }
})

happy for alternative solutions as well.

I think i see what do you mean now... yes defaultValue will be executed once at the first invoke.

[JeromeDeLeon]

Got it so its's not just about the API or anything. That makes sense at least to that part 😃

[adhrinae]

Do we need to provide another state like isDefaultValueLoading? Because for the first time users cannot see default values until that promise is resolved.

[bluebill1049]

Do we need to provide another state like isDefaultValueLoading? Because for the first time users cannot see default values until that promise is resolved.

Good point probably will leave the user to define that state. isLoading.

useState(false)

[JeromeDeLeon]

You mean let the user define useState every time they will use async defaulValues? I think we should leverage that for users. just my opinion instead of letting the users define it every time

[keiya01]

useForm({
  defaultValues: async (args) => {
    if (args.test) { return { data: 'test' }; }
  }
})

I think async function is invoked every render. By rendering, a lot of extra process is occurred.
This is wrong ...
Therefore I think we should provide other function that can invoke in useEffect().

[JeromeDeLeon]

unless we wrap it with useRef, am I right @kotarella1110 ?

[kotarella1110]

Do we need to provide another state like isDefaultValueLoading? Because for the first time users cannot see default values until that promise is resolved.

Good point probably will leave the user to define that state. isLoading.

useState(false)

Is it possible to do the following?

useForm({
  defaultValues: async () => {
    const result = await fetch("xxxxx").then(res => res.json());
    return result;
  }
})

[JeromeDeLeon]

That's my question earlier, because what if you rely on something like fetchById?

[kellyrmilligan]

or like react-query

[bluebill1049]

You can still display your form, and wait for the promise to resolved and inject to all the inputs. if you need to show a loading spinner. you can just do a useState.

[bluebill1049]

useForm({
  defaultValues: async () => {
    updateLoading(false)
    const result = await fetch("xxxxx").then(res => res.json());
    updateLoading(true)
    return result;
  }
})

that works?

[bluebill1049]

I guess callback is just one solution, open to better options.

[keiya01]

Does this case work ?

useForm({
  defaultValues: {
    test: async (args) => 'test'
  }
})

[bluebill1049]

Thank you @vvo very much for always sharing solutions here. ❤️

[antoinerousseau]

I'm using custom fields and a form provider. Had to add this to my Form for it to properly reset/populate when default values would change (data loading, or going from editing an object to creating a new one: same form but empty).

useEffect(() => {
  form.reset({ ...defaultValues } as DefaultValues<T>)
}, [defaultValues]) // eslint-disable-line react-hooks/exhaustive-deps

[dlqqq]

The proposed solution to this has a gotcha: if you update the default value object, you are resetting the entire form to the default values. Obviously, you don't want to do this while a user is potentially entering data. Thus, any async default values should be resolved prior to initial render of the form, with a loading catch block like:

if (query.loading) {
  return <Loading />
}

return <Form />

This kind of sucks since, intuitively, changing the default values of a form should not reset the entire form state. However, after reading through the RFC comments, I honestly can't think of a better solution either.

[zeddz92]

If you already set the defaultValue for each input like this

<input {...register("lastName")} defaultValue={user?.lastName}/>

You can just call reset() on useEffect and it will detect the changes

  useEffect(() => {
    if (user) {
      reset();
    }
  }, [user]);

[MilkiasTonji]

@zeddz92
Thank you very much!. This saved my day

[ScreamZ]

What's the best way to achieve this in 2022 ?

First I thought the best way is to not mount (and call useForm) as long data are not fetched.

[tiavina-mika]

I'm facing the same issue with useForm.

here is my code

...
 const currentUser = useSelector(getUserUserSelector);
...
 // LOAD DATA ON PAGE LOAD
 useEffect(() => {
    dispatch(getCurrentUser());
 }, [dispatch])
 
 ...
 const form = useForm<any>({
    defaultValues: {
      birthday: dayjs().subtract(18, 'year').toDate(),
      sex: 'Male',
      firstName: currentUser.firstName,
      lastName: currentUser.lastName,
    },
    resolver: zodResolver(signUpInfoSchema),
 });

At first currentUser is undefined, then it will be loaded with async data,
but the useForm ``defaultValues always get the first undefined data

[tiavina-mika]

here is my solution with useForm:

const loading = useSelector(getAppLoadingSelector);
const currentUser = useSelector(getUserUserSelector);

// LOAD DATA ON PAGE LOAD
useEffect(() => {
  dispatch(getCurrentUser());
}, [dispatch]);

const form = useForm<any>({
 // no need to define the default values here,
 // we define it in a useEffect (below)
  resolver: zodResolver(signUpInfoSchema),
});

// LOAD FORM DEFAULT VALUES
useEffect(() => {
  const defaultValues = getProfileInitialValues(currentUser);
  form.reset(defaultValues);
}, [currentUser, form]);

if (loading) return null;

/**
 * form initial values
 * @returns
 */
export const getProfileInitialValues = (user: User): SignupInfosInitialFormValues => {
  return {
    birthday: dayjs().subtract(18, 'year').toDate(),
    sex: SexEnum.MALE,
    firstName: user?.firstName,
    lastName: user?.lastName,
  };
};

[cbdeveloper]

Any updates on this?

I'm not a big fan of the useEffect + reset approach.

My current solution is to add a mid-level wrapper (to make sure async data is present).

And call the useForm hook one level down, where I'm sure async data is already present (because of the wrapper).

[mymactive]

React 18 releases a new function "Suspense".
And more, Next.js release a new document includes a new strategy for handling async data like Data Fetching Fundamentals.
I guess that a paradigm shift would occur for async data in React.
I also am interested in a new React RFC "use".
We should be better think async defaultValues after async data handling is sold in React.

Sorry, no concrete idea.
I'm a big fan of RHF.
Thanks for developing.

[bluebill1049]

Update the proposal and PR: #9261 have a look at it and let us know your thoughts

[bluebill1049]

Beta: #9381

[soonbenjy]

Hello !
Thanks for this new async defaultValues feature :)

Did you consider handling error state during async fetch ?
isLoading boolean has been added inside formState, but nothing about a potential isError if fetch failed.

If you have an idea on how can we handle it, I would be pleased 🙏

[bluebill1049]

we can consider that for the latter, but it's probably easier to to try and catch that and use this feature when it's coming out: #9691

[terragady]

How to handle errors during async function? When I do async and try to catch the error then type of defaultValues is screaming that Type 'void' is not assignable to type 'FormSchema'.ts(2322)
It works fine if I throw new Error but I want to handle error with errorLog function and then navigate to error page.

[yann-lauwers]

Thanks for this, it will be very helpful in the future!

Just wondering why should I return an object that matches my schema when using async defaultValues ?
Returning an object without async doesn't throw an error even if my defaultValues object doesn't match the zod resolver.
Returning the same object with async on the default values throws and error.

[yann-lauwers]

Is it normal the type AsyncDefaultValues<TFieldValues> is a Promise<TFieldValues>; instead of a Promise<DefaultValues<TFieldValues>>;.

As far as I can see in the types, default values either take DefaultValues<TFieldValues> either AsyncDefaultValues<TFieldValues>
defaultValues: DefaultValues | AsyncDefaultValues;

Thx for you help guys

[bryanltobing]

I was thinking the same; it should be Promise<DefaultValues<TFieldValues>> since defaultValues is optional from the start.