[Feature Request]: A meta field which indicates a user-induced vs. program-induced value change

[electrocnic]

I made a stackblitz form and experimented a lot and discovered a bug in my own application because I wrongly assumed that isDirty would be false and isPristine would be true if the user never touches the field but I only set the value of the field programmatically via form.setFieldValue(...).

I was wrong, even setting the value like this will render the field dirty.

I wanted to use the isDirty meta flag to be able to tell if it is a user-induced change or by my scripted logic.

The only workarounds which I can use in the meantime would be to either use react states and track user input with them, or to manually overwrite the meta flags after I set them programmatically.
However, I figured that it would be technically correct to have them in dirty state, so a new field could be very helpful.

https://stackblitz.com/edit/tanstack-form-elnvtbsp?file=src%2Findex.tsx

Also, the documentation does not talk about this difference at all, it only claims that "user changes" are dirty.
https://tanstack.com/form/latest/docs/framework/react/guides/basic-concepts

I would appreciate adding this fact to the documentation, that programmatic field value changes also render the field dirty.

[LeCarbonator]

After reading this, one thing that immediately came to mind was an option flag you can use in setFieldValue:

form.setFieldValue('teamName', 'abcdefghi', { dontUpdateMeta: true });

However, after testing it in your stackblitz, it doesn't actually appear to work properly. Maybe it's a bug? From the naming, it sounds like it should prevent the case you are experiencing.

[LeCarbonator]

It turns out you are on an outdated version. It doesn't work on v1.3.3, but it works as written above for v1.11.2.

[electrocnic]

yes thank you! This is indeed a possible solution.

I still wonder if it would be wise to have a separate field and mark fields dirty which are set by setFieldValue.

[LeCarbonator]

I'm not so sure about that. Most examples listed for setFieldValue are in context of field listeners, where it makes sense to touch fields that are dependent on the one you're changing.

With the option to disable it being available, I don't see a reason to implement a different value to track it