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!
@Joachimbj8 ай бұрын
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.
@dayanbalevski44468 ай бұрын
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.
@mrrolandlawrence8 ай бұрын
ever since defineModel came along in 3.3, ive been using that.
@dayanbalevski44468 ай бұрын
@@mrrolandlawrence Yea I completely forgot about defineModel, but all-in-all that is essentially what I do.
@henrique-work7 ай бұрын
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.
@whatsupbudbud7 ай бұрын
Yeah, defineModel ftw.
@gveresUW2 ай бұрын
Yea, the entire time I was watching the video, I was thinking, why aren't you just using defineModel???? This is the way it is supposed to work.
@MinePonex8 ай бұрын
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
@marco.arruda6 ай бұрын
I also have been using like this and it's amazing, typescript detects the exposed properties! Long life to Vue!
@AhmedSalah-xm9xu7 ай бұрын
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.
@Andrey-il8rh8 ай бұрын
Suggestion: never use click as a name for custom event. Not only it's misleading but it also interfere with native browser events
@LongJourneys8 ай бұрын
Wow I've been doing this for years already, it's kind of validating to see someone like you approve of it lol
@Andrey-il8rh8 ай бұрын
Not a single word was said about v-model and scoped slots which would be way better patterns than expose or other options shown
@aleksanderwalczuk65207 ай бұрын
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
@skybluFr7 ай бұрын
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 ?
@nikolaykolev51437 ай бұрын
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!
@pejko896 ай бұрын
I like define expose solution more. I'm mostly doing backend, but I'm using nuxt for a personal project
@JulioCampoSwork8 ай бұрын
Nice tips Erik this helps me a lot at my actual project!
@worldofwarplanesgameplay8 ай бұрын
If the drop down is going be all over, sorry I'm just going to reach for pinia to handle its state
@Andrey-il8rh8 ай бұрын
Why do you need Pinia instead of a regular composable?
@worldofwarplanesgameplay8 ай бұрын
@@Andrey-il8rh I guess I'm assuming the project is already big in scope and a state manager is already in place. ;)
@Andrey-il8rh8 ай бұрын
@@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
@mahdirashidi51047 ай бұрын
it's great way to use props and control it, how about using provide inject??
@NikeshMadhav-o3rАй бұрын
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.
@drewbird878 ай бұрын
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. 😅
@chriscdn8 ай бұрын
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.
@Like_a_lion_9798 ай бұрын
Thanks for video. How can i use defineProps the way showed in video? With destructuring and props keep being reactive.
@dferg8 ай бұрын
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
@Andrey-il8rh8 ай бұрын
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
@dferg8 ай бұрын
@@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.
@Aruta908 ай бұрын
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 :)
@ProgramWithErik8 ай бұрын
That’s a part of the experimental destructure feature I had turned on
@Aruta908 ай бұрын
@@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)
@Andrey-il8rh8 ай бұрын
@@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
@goldenarcher908 ай бұрын
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
@igor-telmenko7 ай бұрын
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?
@DanielAbernathy7 ай бұрын
This would be particularly well suited to the new `defineModel` helper since the child's value would just be a ref.
@igor-telmenko7 ай бұрын
You are right. Since Vue 3.3
@nove13988 ай бұрын
Only emits, defineExpose seems a bit too leaky perhaps although it allows a similar root behaviour.
@peteremad52288 ай бұрын
isn't destructing props make it lose it's reactivity ?
@kyngcytro8 ай бұрын
Was fixed in the latest version of vue3
@kyngcytro8 ай бұрын
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
@ProgramWithErik8 ай бұрын
I forgot to show that on camera , but that’s an experimental feature I had turned on in the vite config
@SXsoft998 ай бұрын
cant we just target the child via refs and toggle the method? the show is in the child making it ""private" just exposing the method
@ProgramWithErik8 ай бұрын
That’s what I did with defineExpose
@SXsoft998 ай бұрын
@@ProgramWithErik so same principle just a different name
@srdnlmrn7 ай бұрын
nice tips but useless in a big scale project... that is too much lines to consider 😂😂😂
@DanielAbernathy7 ай бұрын
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.
@waleedtariq1098 ай бұрын
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
@gazorbpazorbian3 ай бұрын
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.
@Kampouse6 ай бұрын
how about to way binding that or 5 component deep???
@Andrey-il8rh8 ай бұрын
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.
@aleksanderwalczuk65207 ай бұрын
No :)
@adammenczykowski7 ай бұрын
Nice theory, but in a complex real world app if you want to get a good UX sometime you need to control some aspect of a child from the parent.
@Andrey-il8rh7 ай бұрын
@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.
@ukaszzbrozek64708 ай бұрын
I would also use the last pattern. I even forgot that exposing values to the parent is possible. It is a bizarre feature.