You cannot v-model a `reactive()` value directly about formkit

[justin-schroeder]

Hi @tosling 👋

Thanks for the quality report! It turns out what you're trying to do is not a supported feature of Vue 3 itself — that is — directly v-modeling a reactive() object. You can model on a property of a reactive object (yourReactiveObject.formValues), but not the object itself since that would causes whole-sale replacement of the actual object. That’s why a ref works, because it is actually operating on ref.value instead of the ref itself.

Perhaps, if there is any action to take here, we could throw an helpful exception for users who make the same mistake (Ive done it myself a few times).

[justin-schroeder]

Closing this issue as it won't be resolved at the FormKit level and we now have some warnings in the docs to help users avoid it.

[tosling]

Hi @justin-schroeder,

thanks for the super fast reply.

I think I need to dive a little deeper into FormKit's code, to fully understand the limitations or maybe find a nice solution.

In theory:

• I would expect, that FormKit (our <FormKit type="form">) somehow propagates the v-model value down to the children nodes (<FormKit type="input"> in our case).
• Then in the child node, you assign the value via ref.value.
• Wouldn't it be possible, to check if we have a Ref or a Proxy (created by reactive()) and if it's the Proxy, then access the property directly?

[justin-schroeder]

You would think so, right? Perhaps there is some way to kinda "fake" our way there to help improve the dx on that — but fundamentally it's not really how the v-model contract works. Effectively v-model takes the emitted value and directly assigns it to the value vModelValue = $emitttedValue. This is fine when the vModelValue is a ref, because the template compiler knows to assign it to vModelValue.value instead of the root object, but reactive is not wrapped to it attempts to perform a wholesale replacement of the vModelValue itself, (which is often a const anyway).

Coming from the options api, this would be like trying to v-model the entire $data object, instead of a single property within it. Here’s a simple example of this at play in pure vue.

So ways to work around it? We could do what you’re saying and detect if we are working with a reactive vs a ref object — and then essentially not emit the update:modelValue event, and instead directly manipulate the modelValue — but prop manipulation is generally frowned upon and will emit warnings from Vue.

So, I'm definitely open to suggestions on how to improve this, because fundamentally I agree with you that making it magically work with reactive() would be a much better DX, but at the moment I feel like our hands are tied — plus it's pretty easy to just use a ref() or a property of the reactive object.

Still — open to ideas, I'll leave this open for now. 👍

[tosling]

Thanks for the excellent explantation @justin-schroeder 👍 Very valuable information.

This should at least help others facing similar situation. - and I agree, ref()s work pretty smoothly with FormKit, although there is the necessity of .value here and there.

Will keep thinking about a magic solution. ;)

[fenilli]

This should at least help others facing similar situation. - and I agree, ref()s work pretty smoothly with FormKit, although there is the necessity of .value here and there.

I think that is why vue is going to implement sugar syntax for this using Reactivity Transforms. vuejs/rfcs#369

indeed using .value everywhere is quite ugly.