Why next form.initialize calls are ignored?

[artemik]

Hi. As per the Form docs, form.initialize(...) can only be called once, next calls are ignored:

When called form.initialize handler sets initialValues and values to the same value and marks form as initialized. It can be used only once, next form.initialize calls are ignored.

Why is it so? It caused me several hours investigations.

The issue is that TanStack Query by default provides cached data in response if present (which is a good behavior), then in the background fetches the fresh data and provides it once ready, triggering re-render. With Mantine, it seems logical to do useEffect on query data changes to call form.initialize(...). But with the current Mantine form.initialize(...) behavior when you open a page with a cached data present (for example, come back to the page), you're first given the cached data, which form.initialize(...) accepts with no issue, but then the second form.initialize(...) call with fresh data is ignored.

Even though Mantine docs do mention it in the "Example with TanStack Query (react-query):", such behavior basically makes it impractical to use? So really it means the current example in the docs is there, but shouldn't be used by anyone in production. (unless somebody disables query caching, which is rare I believe)

The workaround is instead of form.initialize(newValues) do:

form.setInitialValues(newValues);
form.setValues(newValues);

Why does form.initialize have such behavior that is basically not optimized for the common use case with TanStack Query?

[rtivital]

If it behaves differently then you might lose user input. Example scenario:

• Form is initialized with values
• User starts editing the form and changes several fields
• Some event invalidates query cache and it refetches
• Form is initialized the second time, all user input is lost

[artemik]

I doubt your example would solve the issue - when query.data && query.isFetching is true, it means the data is there (from the cache), but query is also fetching new data in background. So such code would have the same issue - once new data is finally fetched by rtk, the form will not be updated, because query.data && query.isFetching would be false and form.initialize won't even be called the 2nd time.

In the current design, I then don't understand the use cases and difference between form.initialize(...) and form.setInitialValues(...), because:

• if you want to set initial data regardless of async calls (i.e. you have data ready from the beginning) - you use initialValues on useForm(...)
• if you want to set initial data on async call result (either on promise result, or on rtk query.data useEffect trigger, regardless of how many times the new data arrived), but without affecting user input - you use form.setInitialValues(...)

So consequently, you'd think that if you want to set initial data on async call result and also force the form to reset to the new initial state, regardless of user input - you'd use form.initialize(...), because it's literally in its name - initialize vs setInitialValues... But actually right now you cant, because the call might be ignored if it's not the first one which may be hard to predict. And very likely this issue isn't specific to RTK caching, because I suppose other state management libraries also trigger data updates here and there.

Even the check for form.isTouched() == false, which I suggested for form.initialize(...) above, is debateful, because while losing user input is not comfortable, it's also not comfortable letting user edit an entity that already looks differently on backend and user might not want his changes anymore?

What's currently the idea behind form.initialize(...)? Like I mentioned, if the worry is user input, isn't it just a matter of using form.setInitialValues(...) instead, while keeping form.initialize just as a one liner for both form.setInitialValues form.setValue?

[artemik]

Hi @rtivital, any thoughts?

[artemik]

Hi @rtivital do you have more feedback?

[rtivital]

Not really, in my applications I simply display a loading overlay until the data has loaded, and the form is read for the user.

[artemik]

@rtivital So what's the use case of form.initialize(...) vs form.setInitialValues(...)? When would a user specifically use one and not another?