#useForm simpler usage of resetDirty

7 messages · Page 1 of 1 (latest)

whole pewter
#

I noticed that it is required to pass an object with the correct structure to the resetDirty function of the form instance for it to work.. I wondered why that is and if it is not easier to also allow "brute" resetting everything with just resetDirty().

In my case I want to set the form values after getting a response from a request but there are properties that are not part of the response since they are optional.
I could adjust the backend to send more predictable payloads by just adding all properties and set them to null but I think it would help me to better understand how the dirty state of the form works and why the properties are necessary..

If I wanted to solve this client side only I would have to do it like so:

form.resetDirty({ ...data, logChannelId: "" });

Since the logChannelId ist not part of data but part of my initialValues in the form.

coarse ferry
#

Not tested, but have you tried to just use the existing values and overwrite them with your new api data?

form.resetDirty({...form.values, ...data});
whole pewter
# coarse ferry Not tested, but have you tried to just use the existing values and overwrite the...

That works fine too, but I still wonder why we need to pass anything at all..
I assume internally the dirty state is handled for each property separately and it uses the properties of the passed object to set them accordingly?

I think it would be quite useful to be able to use the function with any arguments as a means of resetting all properties..
Anyways, I solved the issue in my case now by making sure the backend returns predictable payloads (no missing properties and instead nulled fields). I think that's anyways a more clean approach for my API.

coarse ferry
whole pewter
#

Then this seems to be a bug actually..
When I use

  form.setValues(data);
  form.resetDirty();

Then form.isDirty() still returns true.

I also checked the fields individually:
{commandPrefix: false, guildId: false, logChannelId: true, sendErrorsToOwner: false, all: true}

const form = useForm<TRPCOutput["common"]["getCommonSettings"]>({
    initialValues: {
      commandPrefix: "",
      guildId: "",
      logChannelId: "",
      sendErrorsToOwner: false,
    },
    validate: {
      commandPrefix: (value) => (!value || value.trim() === "" ? t("errors.requiredField") : null),
    },
    validateInputOnChange: true,
  });

commandPrefix and guildId are updated with the form.setValues(data);.
sendErrorsToOwner stays false.
logChannelId is not part of data so it never gets updated.

But when calling form.resetDirty() without any arguments I would assume it should reset all of them?
It only does so if I pass an object with all the properties..

#

{commandPrefix: true, guildId: true, logChannelId: true, sendErrorsToOwner: false, all: true} this is the log before the resetDirty gets called.
This looks like setValues() flips the bool for properties that were not part of the payload.. but resetDirty ignores them then..

hidden echo
#

I guess you have to provide values into setValues and resetDirty

there is an example of this in form.reset, that when is called, it should apply initialValues to the two of them:
https://github.com/mantinedev/mantine/blob/2fe9c4ab078ec03ddcc97613a1059e7db8b4e4ed/src/mantine-form/src/use-form.ts#L71-L73

here's a sandbox
https://codesandbox.io/s/mantine-reset-dirty-form-exp-exzb3t?file=/src/App.tsx

mantine-reset-dirty-form-exp by AarRidho using @emotion/react, @mantine/carousel, @mantine/core, @mantine/dates, @mantine/dropzone, @mantine/form, @mantine/hooks, @mantine/modals, @mantine/notifications

GitHub

React components library with native dark theme support - mantine/use-form.ts at 2fe9c4ab078ec03ddcc97613a1059e7db8b4e4ed · mantinedev/mantine