`<FormKit>` emits `@update:model-value` twice in specific scenario about formkit HOT 6 CLOSED

Well I would guess that is correct, the value is commited from the form when a new dom element is added to it to all children so they run their validations correctly.

from formkit.

How does running validations corresponds to triggering one of the input's v-model event? This feels counter-intuitive (even though you might be totally right with the above!), as to me these are two different aspects. The value of the first input changes only once, yet it appears as if changed twice based on the console output.

Due to this behavior there doesn't seem to be a straightforward way to reliably hook a watcher and run some logic when the combobox'es value actually changes.

from formkit.

The value doesn't change, but it does trigger a commit, when any value from a parent changes it spreads to its children so those values can be passed to the validation, meaning when you add a value to the form, it triggers a commit that goes to all children, you can read more about it here: https://formkit.com/essentials/architecture#value-settlement

from formkit.

@DamianGlowala — it isn’t really related to validation, but you are correct in general, there is intentionally no event like @change in FormKit. Why? Well — there are a number of reasons:

1. Knowing if something changed is expensive. Of course this doesn’t seem true at a surface level, comparing two strings is pretty cheap after all, but comparing deeply nested objects is expensive, especially if the property being manipulated is deep.
2. Change ownership. Usually what people mean when they talk about "Did this input change" is "I want to perform a side effect when the user interacts with the input". In a synced tree (like formkit) what changed the value of an input is immaterial. FormKit values can be changed by a parent node, a child, programmatically via node, with a plugin, in a hook, etc etc — the ownership of the change should not be important — the state should be important. Which brings me to the most important point:
3. Declarative. FormKit tries to encourage you to write your forms declaratively. In general, I wouldn’t recommend performing effects based on changes but rather the current state of your form. For example, a form could be hydrated with a given set of values — those values should always recreate the exact state of the form, irregardless of how a user interacted with the form. Event tracking is a slipper slope that often gets your form working in one "view" of your data, but will break when the same state is re-created by another means.

So yeah, in general events in FormKit are noisy — most of the time when people are worried about how many times their event fn is called, I get worried about how the form is structured. That being said, we’re always trying to make FormKit better so if there are valid declarative use cases that aren’t considered please let us know, or if there is some kind of state we aren’t already tracking that we should — also let us know :)

from formkit.

Also if you use the FormKit event system instead of v-model it might mitigate some noisy behaviour: https://formkit.link/0f7a4300993e422d60d1121f5275e304

from formkit.

Thank you both for thorough explanation and provided example!

It's nevertheless interesting how the node's commit event is triggered once (yay!), but the v-model twice. This is still a discrepancy I haven't fully grasped, but if this is how things need to be done - I have nothing else but to accept it without any further questions! 😄 The below { ..., __init: true } is the only thing I can noticeably spot that gets added and probably triggers the v-model more than just once (it's purely my guess without diving deeper). Potentially 'stupid' question appears in my mind: why isn't it emitted with __init when it is triggered for the first time? Is this how things definitely need to be left?

I'll think about the points you raised Justin about the declarativeness, appreciate these. There might be a room for improvement. Will report soon with any findings, or if I have none backing up this issue, I'll happily close it.

from formkit.