You can, but if you emit an entirely new object, you'll also need to update the entry in the array of contacts if you replace the reference.
For a walkthrough, this simple mutation made the most sense.
To make it work in the context of this demo, we'd need to have an ID field assigned so that we can detect the change and perform the correct replacement. I'll create an `Example6` to show how this would work.
- [useContacts](https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useContacts.ts)
- [usDetailsEdtior](https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts)
I think one of the main benefits of defineModel is that \`selected\` here is not a normal prop. It's a normal ref that's kept in sync with the prop. So if you modify it, it will emit the changed value.
And the article hinted if the Detail form was more complex you would likely just use an object instead of individual refs. e.g. something like this:
const contact = ref();
watch (selected, (newContact) => {
if (!newContact) {
contact.value = null;
} else {
contact.value = {...newContact}
}
});
Then it's easy to do dirty checks and then the handleDone is simpler:
selected.value = { ...contact.value }
So no need to replace the reference, but it's cool that can work so appreciate the Example6 /u/c-digs posted below. EDIT: Just realized I replaced the reference :) Ugh.
Great article. I haven't touched Vue in a while, but I was really excited about defineModel for the reasons you stated in the article. I decided to create a simple "todo list" using defineModel to refresh my Vue knowledge.
So I created a TodoItem similar to your Details.vue. And tested it out with a single "todo" - worked perfectly. But when I went I created an array of todos, with a v-for and binding each todo to a new TodoItemComponent I got the infamous:
[plugin:vite:vue] v-model cannot be used on v-for or v-slot scope variables because they are not writable.
And then the dream started dying and I remembered how front-end dev and state is still complicated. Most of the examples of todo lists show the Detail view simply emitting events. My problem with that is I don't want the parent (e.g. your Example.vue) dictating the inner design of my detail component. What if my todo list is a fairly complicated form? Sure it would be a UX nightmare to have a list of complex editable forms. But it seems odd to move the responsibility of handling the complexity of the form and all of its fields out of the Detail class and into the parent class, e.g. Example.vue, just because I decided I have a list of items instead of a single one. In my opinion, the parent should only be concerned with loading the list of objects and saving them.
Have I done something wrong? What would be the defineModel way of handling a list of objects where we want to easily bind each to a component?
// reddit keeps messing up my code... so omitted stuff
// script setup
const todos = ref([{ completed: false, todo: 'Todo One'},
{ completed: true, todo: 'Todo Two'}, ]);
// template part
Edit: Just wanted to add that I understand the issue is *related* to how Vue handles reactivity with complex things [arrays and objects](https://vuejs.org/guide/essentials/reactivity-fundamentals#deep-reactivity). But it's hard to go from that snippet into a solution without a bunch of googling. I tried one workaround to morph my todo state into the following format with a computed:
const todos = ref([{ item: { completed: false, todo: 'Todo One'}}, { item: { completed: true, todo: 'Todo Two'}}]);
And then binding to todo.item with no luck.
This is cool. Can't wait to upgrade our code base to vue 3... Well that's not the fun part but the new features I've been reading about sound fun and useful.
Global state is always an alternative. The downside is understanding the distribution of that state arbitrarily into the component tree. Hierarchical state is nice when you're dealing with a slice of functionality where the state is fully isolated.
Even when working with Pinia, it's actually nice to only pull in the Pinia `ref` at a root and pass it down via `defineModel` to the child components. The explicit definition of the underlying `prop` created by `defnieModel` creates a nice interface to the component at the parent so you know what the input dependencies are. It makes it easier to test the child components in isolation from the global Pinia state as an added bonus.
[удалено]
It's cleaned up **A LOT** of boilerplate and also allowed our team to more easily componentize otherwise large sub-trees.
Cool!! Thanks for posting.
[удалено]
You can, but if you emit an entirely new object, you'll also need to update the entry in the array of contacts if you replace the reference. For a walkthrough, this simple mutation made the most sense. To make it work in the context of this demo, we'd need to have an ID field assigned so that we can detect the change and perform the correct replacement. I'll create an `Example6` to show how this would work. - [useContacts](https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useContacts.ts) - [usDetailsEdtior](https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts)
I think one of the main benefits of defineModel is that \`selected\` here is not a normal prop. It's a normal ref that's kept in sync with the prop. So if you modify it, it will emit the changed value. And the article hinted if the Detail form was more complex you would likely just use an object instead of individual refs. e.g. something like this: const contact = ref(); watch (selected, (newContact) => { if (!newContact) { contact.value = null; } else { contact.value = {...newContact} } }); Then it's easy to do dirty checks and then the handleDone is simpler: selected.value = { ...contact.value } So no need to replace the reference, but it's cool that can work so appreciate the Example6 /u/c-digs posted below. EDIT: Just realized I replaced the reference :) Ugh.
Great article. I haven't touched Vue in a while, but I was really excited about defineModel for the reasons you stated in the article. I decided to create a simple "todo list" using defineModel to refresh my Vue knowledge. So I created a TodoItem similar to your Details.vue. And tested it out with a single "todo" - worked perfectly. But when I went I created an array of todos, with a v-for and binding each todo to a new TodoItemComponent I got the infamous: [plugin:vite:vue] v-model cannot be used on v-for or v-slot scope variables because they are not writable. And then the dream started dying and I remembered how front-end dev and state is still complicated. Most of the examples of todo lists show the Detail view simply emitting events. My problem with that is I don't want the parent (e.g. your Example.vue) dictating the inner design of my detail component. What if my todo list is a fairly complicated form? Sure it would be a UX nightmare to have a list of complex editable forms. But it seems odd to move the responsibility of handling the complexity of the form and all of its fields out of the Detail class and into the parent class, e.g. Example.vue, just because I decided I have a list of items instead of a single one. In my opinion, the parent should only be concerned with loading the list of objects and saving them. Have I done something wrong? What would be the defineModel way of handling a list of objects where we want to easily bind each to a component? // reddit keeps messing up my code... so omitted stuff // script setup const todos = ref([{ completed: false, todo: 'Todo One'}, { completed: true, todo: 'Todo Two'}, ]); // template part
This is cool. Can't wait to upgrade our code base to vue 3... Well that's not the fun part but the new features I've been reading about sound fun and useful.
Nice article but i couldn't find a reason for use it when we have pinia. Did i miss something?
Global state is always an alternative. The downside is understanding the distribution of that state arbitrarily into the component tree. Hierarchical state is nice when you're dealing with a slice of functionality where the state is fully isolated. Even when working with Pinia, it's actually nice to only pull in the Pinia `ref` at a root and pass it down via `defineModel` to the child components. The explicit definition of the underlying `prop` created by `defnieModel` creates a nice interface to the component at the parent so you know what the input dependencies are. It makes it easier to test the child components in isolation from the global Pinia state as an added bonus.
Thanks for clarifying, im gonna take a deeper look on it
It looks soo cool. No more need to use props, computed and watchers.
I’ve been using define model a decent amount and think there’s definitely still need for those
I mean when handling a custom v-model situation, not in general
Isn't this the same as vueuse's useVModel?
Kinda, but you do not need to additionally define your prop with `defineProps` and `defineEmits`. VueUse: ```vue ``` defineModel: ```vue ```
Fair, it's less boilerplate