This can also be accomplished with the new `defineModel` macro. Try this: ``` Child Toggle Button Child: {{ toggle }} const toggle = defineModel("toggle", { default: false }); ``` ``` Toggle Parent Button Parent: {{ toggle }} const toggle = ref(false); ``` The nice thing about `defineModel` is that it creates a local variable and emits on change. If you make it optional with a default, and don't bind it from the parent, then it acts like a ref inside the component. I've dealt with this pattern for years, and it always annoyed me how much boilerplate it required. This macro is great!
Wasn't aware of defineExpose - nice api! 😊 In the use case presented in the video I usually use defineModel so it can optionally be controlled from the parent.
I use two-way binding watcher pattern. Essentially I emit the hidden value not the click event and update the model value (_hidden) which comes from the props. On the parent component I can have a hidden boolean ref, which I can control from the parent and and pass it to the child via v-model:hidden="hidden" prop. The child will set the value of _hidden boolean ref to the props.hidden value initially as a default, and then the _hidden boolean ref is fully managed internally but can be controlled externally by adding a watch on the prop, so if the props.hidden value changes from the parent, it will set the internal _hidden ref value to it. That way v-model sets the value of hidden on parent and the parent can control the child, and the child can control it and emit the value back up to the parent, and hence hidden is in sync on both parent and child, and can be controlled by parent and child.
There is also a way to do that with: const hidden = defineModel('hidden', { local: true }) This would make that if there is no v-model used, the ref would be a local ref value instead Probably is the same thing under the hood but is a nice shortcut.
In defineExpose example instead of `ref()` set type as `ref()` And typescript should already know that you have available `hidden` prop of that component and you won't have to do all these unnecessary type assertions in toggle function. Although I think proper typing for refs of components is: `ref` But it's not giving automatic completition, even though when you hover over the ref variable it shows that `hidden` prop is available. Idk why and I dont want to deep dive on this
v-model is nothing more than emit. Tbh it’s good for primitives, if you’ve to update an object it might cause issues. I’d say defineExpose might be handy and is quite uncommon AFAIK
Wouldn't you simplify it doing const hidden = defineModel('hidden', { type: Boolean default: false }) Then you can update the value however you want and if the parent want to pass it down they just do v-model:hidden="hidden" or ?
Using `defineModel` you can get rid of all the yucky logic in the child component: `const visible = defineModel('visible', { type: Boolean, default: false })` If the parent provides the `visible` prop then it's automatically reactive to parent changes, but if not, it just acts like a local ref.
Hey Erik, just wanted to mention, that you can also use the defineModel function and use a named v-model to Exposé the hidden value and inside the component you can just use a default value for the hidden attribute Great video to show the possibilities vue offers.
@@worldofwarplanesgameplay imo, even if project has Pinia set up it doesn't mean every single entity should be implemented via it. Small things should remain small
I think you can just implement v-model for your component instead of this. We can use :value="defaultValue" or v-model="valueDefinedInParent". Why not?
Hi I have one question. How can we create cross platform app with amplify gen 2 - Flutter for android and ios and next js for web from single amplify project. I am not able to find any solutions.
Hey, what if my child component has a form, but the submit button is on the parent component, and I want the data to come to the parent component when the form button is clicked? How can I do this? I know I can achieve this with defineExpose, but is there a better way? Because what if we have multiple components that contain forms? In order to get data from them, I would have to expose them in each component and also create multiple template refs
I've been using a pattern using the mitt library and emit events with the information needed, that way the component doesn't need any prop because you can pass them in the event emission. and the mitt library weights next to nothing.
I think defineExpose we could use so little as we can and we have to understand that "I really could to use defineExpose in this case". because it's not obvious and brings a magic, that is not always easy to unravel. But I really hard want to know: how I can destructure props with required option, because const { foo = 'someValue' } = defineProps({ foo: { type: String, required: true }) isn't reactive :)
@@ProgramWithErik but in vue 3.4 it's a stable version now, but i don't understand why we can't set require option for this. It's a good feature, but work... not a whole functionality of the props api - just a part: default value and... that's all (if we talk about JS and not TS)
@@Aruta90because it's just one way of doing it and yes, it's still experimental, RFC isn't finalized. You can only benefit from such syntax with TS. If you using JS you probably should use old syntax
I should say all approaches shown in the video are antipatterns. Golden rule of a great component architecture is incapsulation, if you need to expose something from a child to parent most probably you did something wrong, step back and ask yourself why am I trying to over engineer.
@adammenczykowski it's not a theory, it's a discipline. Those cases you referring to is no more than 1%, other 99 is just an inability of many developers to build a clean and simple architecture. Also I don't think you formulated the statement in the correct wording. Controlling the child from parent is not what's discussed here, it's the other way around, when your child component tries to know and modify something in the parent.
good ideas, to know and keep in mind, thank you 👍 but I think the first option would be more like "better not do this, it's kind of bad practice", and not "you should use it!" as it adds kind of magic and more you write such code, less readable it becomes and it's better not to have such a habit 🙂but yeah, it's just my opinion
This was kinda cool! Thanks for the idea! I usually use the emit approach and then manage the state on the parent component..following the usual flow that Vue seems to like more. But this one, even if it feels a little bit strange, looks cool! Will have to try it! Thanks Erik!
Love this kind of content Eric. I'd be interested in seeing more of these in the future. 🙂 I find myself wanting this type of feature baked-in. Makes me wish I could define these types of things directly within the prop definition. Like having a collocated function prop with a default function. ( maybe this is possible and I just haven't imagined how yet. 😅
You can use the new defineModel macro to do this. If you make the model prop optional (with a default) in the child, then it behaves like a local ref value when the parent doesn't bind to it. It's far less boilerplate with the macro.
I like this idea, and I understand how to but I think it may have been beneficial to show how to wrap that idea into a composable to make it easier to set up. If you had multiple values to share, replicating the computed and the functions and stuff multiple times would get messy. Would be a nice use for a composable to create it for us
I don't agree. Creating compostable for such a trivial task would be an overkill. I've been working in projects where devs used composables for almost everything and it turned into real composable hell
@@Andrey-il8rh while I do agree that composables can be overused, my point was that if there were multiple values that you were doing this with, a composable would be nice to have, as opposed to creating a ref, a computed, and a function to handle toggling it for each value. If you're only doing this one time, absolutely agree with you that a composable is overkill and not necessary. But if this is something you do often, it saves a lot of time and effort generating a bunch of repetitive code, and cuts down on the possibility of typos and errors writing those things over and over.
They also added defineModel which I use that in scenarios like this. where I want the prop to still be controlled by the child even if it wasn't passed in by the parent. Not sure if it's the best approach tho
