New in Vue 3: Emits with Alex Riviere

EPISODE 55

[INTRO]

[00:00:00] T: This episode is brought to you by Ionic. For more, visit ionicframework.com/vue.

[EPISODE]

[00:00:16] BH: All right. Let’s do this. Hello, everyone. Welcome to Enjoy the Vue. I’m Ben. Today on our panel, we have Ari.

[00:00:24] AC: Hello.

[00:00:25] BH: Tessa.

[00:00:26] T: Hello.

[00:00:27] BH: And returning special guest panelist, Alex Riviere.

[00:00:30] AR: Hello.

[00:00:33] BH: Today, we're here to talk about something that's coming to – when I say coming, I mean, it's in Vue 3 already. I keep repeating, Vue 3 is released. We're here to talk about the emits component option. Before we get started, I guess, Alex, I'm going to throw this to you. What is this concept of emitting in Vue? Because it's not a Vue 3 thing. We'll talk about what’s Vue 3 specific, but what is emit when it comes to Vue?

[00:00:56] AR: My understanding is that emitting in Vue is the way that you pass data from a child component to its parent. It allows you to create your own events and you can use it wherever you want to, in a component to emit some data backup to its parent. You can call your events whatever you want to. We have some various types of namespace events that are native events that we are catching. Overall, that is what emitting is, is that you can pass some data from a child to its parent by catching an event and receiving the new updated data.

[00:01:40] BH: Very nice. What do you think, Ari? Does that jive with your definition? Or what do you think when it comes to events?

[00:01:46] AC: I do think it's important note that the documentation very specifically says kebab case only. We can't just name things willy-nilly, Alex.

[00:01:56] AR: I prefer “screaming snake case.”

[00:02:01] T: Oh, no. The worst of all worlds.

[00:02:02] BH: That’s the first I’ve heard of. Screaming snake case. I like it. We’re making another thing in 2021. Stack trends.

[00:02:11] AC: Yes. Overall, I agree. Though, I would also like to note that you don't always have to pass data with it. Sometimes just the fact that it happened is all the parent needs to know.

[00:02:20] BH: What about you, Tessa? What's been your experience with emits and the mental model of it?

[00:02:25] T: Yeah. I think it's probably the same as Alex and Ari. The only thing I really have to add there is the reason that the docs have that recommendation is because DOM events are not case sensitive. If there's a point, I believe where your event passes through a part of your app that is not in the Vue ecosystem. Then if you're checking for it based on kebab case, it may no longer match, something like that.

[00:02:57] BH: Yeah. Sounds about right. Yeah, I think to Ari, Alex and Tessa's point, I think for me, when it comes to emit, it is that idea of just really notifying. Basically, the child or the component just tells the parent that something has happened, whether a payload accompanies it or not, is completely optional. Typically, it does accompany it. It's one of those things where I think, people will come from other frameworks, particularly like React, for example. They'll think it's weird. Because what is this emit thing? Why not just pass a callback function as a prop, which is more common in React?

For me, I think when I started thinking about this, it's – I don't know about you all, but to me, this is actually the way the web was built normally. It's like, you listen for a click, and then the click event tells you what to do. In that regard, this is actually the way that things have been done. I don't know if anyone disagrees, agrees?

[00:03:44] BH: Yeah. I mean, I learned AngularJS before I ever learned React. Learning to pass callbacks was a weird experience for me. Then going from React to Vue, switching to props and events was weird again, but it was weird when I first switched to callbacks to have to use that pattern. When I first switched to Vue, I tried to do the callback thing instead. I don't remember that there was any particular recommendation in the dots when I was going through the starter guide, but I just wanted to try it to see how it worked. Just over time, I realized that it felt like I was fighting against the design of Vue and upkeep would be more cumbersome, so I naturally moved away from it.

[00:04:26] BH: One of the things I know I struggled with when it came to JavaScript early on was the name of callback function. I don't know why, but the idea that the function is callback never really jived with me. Just in case we have listeners here who are probably newer to JavaScript, I guess I'll start with you, Alex. What does it mean to pass a callback function as a prop to a component?

[00:04:47] AR: There was a period, I came in to JavaScript right as ES6 had been around for a year. People were slowly moving over to promises. There's some of this history that I've missed, so I will attempt to speak intelligently about this. There was a time where before promises existed, where you could do asynchronous style programming. Have create a promise, and then once that promise has resolved, do something.

[00:05:23] T: Sorry, before promises existed, you could do promises? Can you explain that a little further? Do you mean with Bluebird, or do you mean –

[00:05:31] AR: You couldn't do – before promises existed, you would do callbacks, right? Currently with promises, you're able to create a promise. Once that promise has resolved, you're able to then do something else. With callbacks, you would have a function, or a component and you would say, “Hey, here's the thing that I want you to do.” Once you're done, and you would pass it as an argument. In the case of a component, you would give it as a prop. You would say, here is a function as a prop that I want you to call, which technically, from a technical standpoint is fine.

However, if you are writing a bunch of components, and you are expecting a callback function, my experience has been, you need to check to see if that callback function exists. By doing that check, you are not leveraging the beauty of the emit function, which does that check for you. We'll call all of the things that you've already supplied. That's my 10 and a half cents.

[00:06:41] BH: What about you, Ari? What was your experience when you first learned about callback functions?

[00:06:45] AC: Goodness. I once created an asynchronous function that also had to be somewhat synchronous. I think, I had three levels of promises. I am well-versed in callbacks. I believe, it’s what some people would describe as callback hell.

I also, when I was first learning web development, I started with jQuery, which is very much dependent on the built-in DOM event, which allows you to add an event listener, but also it allows you to dispatch an event from an element. For me, it was the concept was familiar, but having it in HTML was not. That took a little getting used to. Though, the one thing that I have always struggled with for some reason, is if I'm calling a callback that I've already defined, I would never know if I'm just supposed to do the name of the function, or if I'm also supposed to invoke it in the callback.

[00:07:55] AR: Oh, my God. Yes. I feel that so hard. Oh, my gosh.

[00:08:00] AC: Sometimes I’ll define it in-line, so that I don't have to think about that at all.

[00:08:06] BH: I mess that up all the time. What about you, Tessa? What have been your experience with callbacks?

[00:08:11] T: Yeah. I mean, I did a bit of jQuery. I don't really remember that much about callbacks, specifically there. Although, speaking of nesting, I haven't really entered callback hell that often, but I do really enjoy deeply nesting ternaries. I don't do it in prod. I just like it.

[00:08:31] AC: All right. Are you serious?

[00:08:33] T: Yes. Well, okay. Specifically, I think it was actually for a project, where a partner and I had to implement promises from scratch. We were basically rebuilding Bluebird.js, which was, or maybe still is a popular library for promises for projects that don't have native ESX promises. We were talking about ternaries and I told her that you could nest them, and she didn't believe me. I nested 15 ternary expressions just to prove that you could. Also, it worked. We finished that. We passed whatever unit test that was, so it was great.

[00:09:15] AC: Okay. But Tessa, just because you can, does not mean you should.

[00:09:19] T: Means you absolutely should. To bring it back to Ben's question, I remember when I was learning about callbacks, it was something that was very hard for me to understand. It's still hard for me to understand and I think I'm starting to realize what it is, because, well, the idea of callbacks, right, is that with JavaScript, we have first-class functions, which I believe means something like their objects, or you can pass them as arguments or something like that. You can give another function a function.

The idea with callbacks is that you are passing a function to another function. Then at some point, when that other function runs, it'll call the passed-in function. That's a callback. The part that trips me up, I think, is the back part of callback. I was recently re-watching a node class from this online instructor, I really like. Anthony Alesea. He was talking about how, “Oh, it's called a callback, because it's like, when you call somebody and they're not there, and you leave them a message, and then they call you back.”

The whole point of calling somebody back is so that you can have some conversation, or communicate with each other. With callback functions, the function that's being called back later doesn't necessarily have to send any data back to the original function, or close over any data from the original function, like it can. The original function might not even care that it was called. It’s just passing it on to the next function to be like, you take care of this. I'm washing my hands clean of it. I think, more than the concept is just the name that I always found really confusing.

[00:10:55] AC: What if we think about it a callback in comedy, where the joke is defined early in the show. Then at some point later, they use some phrase to harken back to that joke. Let's say the joke is a function. The audience laughs the first time the joke was told. Yeah, that was the output of the function was laughter. We use a callback to then evoke laughter again, because we've already defined that thing that outputs laughter. I think I won’t relay too deep on that.

[00:11:27] T: I like it. I just don't know if now I'm beginning to wonder if it's maybe an anti-pattern to have callback functions that don't fit that metaphor of callbacks, where you're just like, “I just want this thing to happen at some point later. I don't care about it anymore.” It has no relation to the original function.

[00:11:44] AC: I mean, I would say that that probably is an anti-pattern. It should relate to it, right? Otherwise, it's just a dirty side effect.

[00:11:51] T: Maybe. It's still technically a callback, right? That's why I cited the name confusing.

[00:11:56] BH: Yeah, I'm not a huge fan of the name either. When explained the way Ari explains it, I'm actually – I wish I had the explanation when I first was learning it, because I remember just being like, “Why is it CB? What is the CB thing that's being passed the thing there?”

[00:12:07] AC: Oh, yeah. They just do in CB. Oh, that took me forever to understand that it was callback.

[00:12:13] BH: Yeah. I was like, I have [inaudible 00:12:14].

[00:12:14] AC: That’s why I'm always a proponent of spelling it out, quite literally.

[00:12:18] AR: Yeah, that was definitely a concept that I had trouble with at the beginning, was like, why am I putting a function definition here? This doesn't make any sense, whatsoever. Because that concept made zero sense to me. Why would I be putting a function as a parameter?

[00:12:39] AC: Maybe the best way to get used to it is just using set timeouts? I’m done serious here.

[00:12:46] BH: That’s there, right? Because every 300 milliseconds, you’ve called it.

[00:12:49] AC: You’re taking away all of the other noise of an event, or whatever. You're just saying in X amount of time, do this. You're saying, “Okay, hold on. I'm going to call you back.”

[00:13:01] T: Yes. I will agree with Jake Archibald’s assertion that the order of the arguments and set timeouts is incorrect.

[00:13:09] AC: Yeah. I would agree with that as well.

[00:13:12] BH: We'll need a link to that article.

[00:13:14] AC: Yeah, I had thought about it. Yeah, no. Because every single time I'm like, I want to say the amount of time that needs to pass before doing this thing. I don't want to tell you the thing you're going to do first, because you might just do it without me telling you how long to wait, because obviously, JavaScript is a person.

[00:13:32] BH: Obviously.

[00:13:34] AR: Maybe that is a better way to think about callbacks then. For instance, in the phone concept, you would have a phone conversation with someone, where they would say, “Hey, can you go and get me some information about a thing?” They'll be like, “Cool. I will get you information about a thing. Let me call you back once I've done that,” and then they hang up, right? At that point, the communication flow stopped. They're off doing something else. At some point, you're going to get a callback with that information. That is why it would be a callback.

[00:14:11] T: Right. See, I feel that makes sense if the original function is depending on getting that back. That's not always the case. Also, I'm told that nobody makes phone calls anymore. That's another problem.

[00:14:27] AC: Okay. Just replace the call with text. Will you give me an example of why you would pass in a function that was unrelated?

[00:14:37] T: Maybe it's not necessarily unrelated. It's just the original function doesn't depend on getting that information back. It's delegated the responsibility of taking care of something to the next function. It assumes that the next function is going to call it eventually.

[00:14:52] AC: I guess, I feel that yeah, I think you're right, that that very much is an anti-pattern.

[00:14:56] AR: I think, it may also be that you don't necessarily need the information directly from it, but you need that information available for something else that would happen. In the event of an API call. We do a bunch of stuff at work, where we go and one of the first things that we do is we fetch the user information. We put a pause in the application and be like, “Hey, don't fire anything else, until this one resolves,” because there's a bunch of other things that are miscellaneous, that will need this information, but we don't know what they. It could be like that, where you're saying, “Hey, don't go do this thing, until you see this information is done.”

[00:15:37] T: Yeah. Also, bringing it back to events, you can pass an event handler to the watcher that will loop through all of them whenever an event is called and trigger those handlers. Maybe there's no listener, which in that case, I would agree is an anti-pattern. To me, that's almost a separate question. How should we write code versus what is the definition of a callback? Does that word makes sense? Because I think, especially when we're teaching beginners, callbacks, at least in all the materials that I've seen, I haven't seen any commentary on what kind of function it should be.

It's mostly just, well, it is a function in this specific context. Maybe the definition needs an update. Just in terms of thoroughness for me, callback doesn't encompass all of the possible use cases for when something would be considered a callback, metaphorically speaking.

[00:16:31] AC: All metaphors eventually break down, Tessa.

[00:16:34] T: This is true. I mean, ever since I brought up the phone call thing, I'm thinking in my head about when somebody post a TikTok and then somebody else makes a reply TikTok. Anyway.

[00:16:44] AC: Should we just call them holla-backs?

[00:16:46] T: Oh, my God.

[00:16:49] BH: Yes, another 2021 trend. I like it. Now that we've talked and gotten a lot of different perspective on callbacks, of course, we're here, as we mentioned at the beginning, to talk about emits. I guess, I'll toss this one to Tessa. When it comes to Vue 3, what’s some of the new things that are coming with Vue 3 for the emits option?

[00:17:09] T: Why me? I thought, this is why we had Alex as a guest host on the show. Well, okay. I believe that now, you can specify either the events, or the event handlers in your component options, similar to how we do with props in Vue 2. The idea there is that you can see the events part of each components API right at the top of the script tag, which, depending on your preferences may also, or may not also be the top of your file.

[00:17:44] AC: Always top.

[00:17:45] BH: Always top.

[00:17:47] T: Personal projects, top. Work projects, middle. It took me a long time doing it in personal projects top to get used to it. I will say, literally a year.

[00:17:57] AC: I was really lucky, because I just started that way, because I started with Vue enterprise boilerplate for some reason. I can never say those three words without messing it up.

[00:18:08] T: I think when I took Chris's workshop, he was just considering making that change. I was like, just before –

[00:18:15] AC: You're a cool kid is what you're saying?

[00:18:20] T: Oh, yeah. That’s the first time I heard like, “Oh, I took a workshop before, it was cool.” I was a nerd before it was cool.

[00:18:29] AR: If we're talking about order of your template versus script, I think it really depends on the type of component file you're looking at.

[00:18:38] AC: No, you’re wrong. I’m just kidding.

[00:18:40] AR: If you're looking at a Vue, like a page, where all you care about is what the template layout of it is, I feel that's more important to be at the top than the script.

[00:18:54] T: Yeah, there are many times when I wish I had a template at the top, when I put script on top. It was only in my most recent project where I was doing a ton of JS-dependent CSS, that I was finally reaping – Wait, got it backwards. Anyway, I was finally reaping the rewards of putting script at the top. Up until that point, everything in my personal projects was very template heavy. It was such a slog to scroll past my script tag. Just know which one I want at the top and magically put it there. Geez.

[00:19:29] BH: That's a feature for Rahul to do for Vue, actually, I think. Because he could do magic like that. Anyways –

[00:19:36] AC: Whichever one is longer.

[00:19:40] BH: Ari, what did you think about Tessa’s, and I saw you nodding along with her, sort of what she saw as the new emits enhancements in Vue 3? Do you have anything to add, or to reinforce on those points?

[00:19:54] AC: When I first read about it, I immediately thought of Tessa, because some of you may know that Tessa has had to advocate for – play devil's advocate on the show before regarding passing in callbacks as props, instead of emitting events. I think it's very important that everybody knows that that is not Tessa's personal preference, but it is something she has had to accommodate. We’ll just put it that way.

The argument she gave was having a clear API. If it's in the props, then it's clear that there's an expectation, or at least a possibility of needing to address this particular thing. I really like that it does address that particular argument while still supporting the prop emit relationship, to simulate to a binding. I personally am a big fan of that, because especially if you haven't looked at a component in a really long time. Even though you wrote it yourself, like it was a week ago. Come on, guys. I'm supposed to remember what I did last week. Being able to very quickly see what the relational expectations are between a parent and a child component, I think is super useful, which is why I think script should always be on top.

[00:21:12] T: Yeah, I thought that's the part you're nodding along to DVH.

[00:21:17] BH: What about you, Alex? What were some of your reactions when you first saw the new emits?

[BREAK]

[00:21:22] AR: Hey, Tessa. Your new PB and J topping selector website is really blowing up. I wish it came in a mobile app version, so I didn't have to bring my desktop to my kitchen every single time I'm hungry.

[00:21:37] T: Tell me about it. I don't know the first thing about mobile. I'm a Vue developer through and through. Oh, well.

[00:21:45] AR: Are you telling me you haven't heard of Ionic?

[00:21:49] T: Ionic?

[00:21:52] AR: It's a mobile app development platform that empowers web developers to easily make native mobile and progressive web apps, all in Vue.

[00:22:02] T: That sounds too good to be true. How do I know if I can trust it?

[00:22:07] AR: Well, Ionic is the technology behind about 10% of the world's mobile apps, including ones from Home Depot and Target. It's also open source, so anyone can contribute.

[00:22:18] T: Well, that sounds pretty cool. What if I need help?

[00:22:21] AR: Well, Ionic’s got you covered there too, with their premium tools and services.

[00:22:26] T: Gosh. That sounds almost as smooth as my favorite brand of peanut butter. I'm no good at design. Don't Apple and Google have really stringent standards on mobile user experience design?

[00:22:41] AR: Well, that's the best part. The Ionic view library comes with over 100 native components and utilities, including animations and icons. You don't need to design anything to get started. Capacitor will take all your JavaScript and package it into a stunning mobile experience for you.

[00:23:00] T: Wow, that's awesome. How do we get started, Alex?

[00:23:03] AR: At ionicframework.com/vue.

[00:23:08] T: Nice. I can't wait to make everyone jelly of my new PB and J mobile app.

[EPISODE CONTINUED]

[00:23:23] AR: I saw it and I got super excited about. At work, we've been doing a lot with using JS doc comments to describe how a component works, what's available in it and what events it emits. That doesn't do anything for the editor. It doesn't actually translate in any way useful for the editor at this time. I use JetBrains. There we go. The thing is though, is that if there is an emits option, then it's a lot easier for editors to infer, “Hey, here are the events that you have available to you.”

For developer experience, I feel that's going to be extremely beneficial and extremely useful. Just from a team level, it's going to be easier to say, “Hey, document the props. If you ever emit an event, document the event that you're emitting.” I'm super stoked about it. I also like that you can do validation in there and be like, are you emitting this event correctly? That's really nice, being able to do a custom validation and say, “Hey, is this event emitting properly or not?”

[00:24:43] T: Yeah, especially going back to the pro callback camp. I'm not going to pretend that I understand this argument. Another pro for the callback pattern is it is apparently easier to track errors and also avoid type errors or something using callbacks. Again, I don't really get it. If that is an experience that other people share, then I think having the validation right at the top of the – well, top if you have scripts at the top, but top of the options just really explicitly spelled out, I think, is really nice.

Also, lately, I've been doing a lot of in-component documentation, where I’ll write at the top, like a short summary of the inputs and outputs of a component and what the intention is, and like an example of where it's being used. I always have to do a special go more in depth for events, because you have to go to the template to see what's going on. It'll be nice to have everything listed in a single place.

[00:25:47] AC: You are a much better teammate than I am.

[00:25:51] T: I'm trying to be an example.

[00:25:55] AC: I mean, that is really going above and beyond. You're making me feel bad about myself, Tessa. Could you stop?

[00:26:00] T: Honestly, that's the only reason I do it. I’m like, working away at work and I’m like, “I hope Ari feels this in her heart and she feels guilty.”

[00:26:07] AC: Yup. Well, you in this time, Tessa.

[00:26:11] BH: I think we've been talking about some of the testaments me of the pros of why people argue for props, sorry, functions as passing out as props. For me, I always found that our goal with a lot of times with components is to find ways to make them a reusable, but then really, the whole point of component is to scope them to their appropriate concerns. I think it's very interesting when people argue for that, because it means that the parent has to be very prescriptive to the child about how to do something.

In the event you want that to be genericized, or whatever, now you need to not – you have two places that now care about how that thing is going to handle it. Whereas a lot of times, we just want to know that something happened in the child. The parents, they can do whatever they want to do with that information that something has happened, just like you would expect in a browser to be like, the user double-clicked. Now that the double-click has happened, this is what I'm going to do, which is different from the single-click option. This is I think why the event model is actually native to how we develop for the web. I know that a lot of – for those who have come from the old vanguard of callbacks, it might feel more comfortable originally to think of things in callback ways. I would definitely be proposing that you try to – if you rethink of events not as a Vue thing, because it's not, it's really how we've been doing the web this entire time. I think there might be less resistance to the mental model there.

[00:27:32] T: I mean, really, I feel it's not even an old Vanguard. It's not that events is abusing, so much is it is that callbacks is very much I think a react thing. It’s like, Angular also has two-way binding. I haven’t use Angular in a couple years, but I don't remember this being a big thing when I was working with Angular either. I could be wrong though. Someone will probably let me know. Let me, let me. Wow, that was a –

[00:27:59] BH: That’s a callback.

[00:27:59] T: That was an old callback. Yeah.

[00:28:00] BH: That’s a callback right there. We love you, Chris.

[00:28:07] AC: We miss you. I guess for me, part of how I wrap my head around the idea of callbacks was in my head, I understand that there's a very strong relationship, but just the different moniker between an event handler and a callback. Ultimately, we achieve the same thing. They do something at a given point. That point is not right now. Sometimes I feel like, when people start arguing about that, I'm like, you're really talking about the same thing. That's me.

[00:28:40] T: Well, that's what I hear a lot actually, is they're really basically the same. Why not just use callbacks, since everybody knows callbacks?

[00:28:47] BH: No.

[00:28:49] AC: You're handling an event.

[00:28:52] T: Another argument that one of my teammates made that makes sense to me is theoretically, because for me, the thing confusing about callbacks is I feel like, I never know how the parent is messing with data that the child may have. She's saying, well, it's just happening in a different place, but it's still the same thing. Because if you're emitting data up and then the parent is mutating it and then passing it back down, it's the same. On the one hand, I can see their point. Then on the other hand, it's like, if the thing that's being mutated is being passed down as a prop, then that expectation is very explicit. It's a prop, so you know that the parent has full control of the data.

If on the other hand with the callback, the parent is mutating stuff that's in the child's data function that I'm using in computed properties and stuff, I feel that's very different. Because once it's in the data option, I expect that to be the domain of the child. If the parent is messing with the child's data, then I'm not very happy about it. With emitting, yeah, it's a little bit more typing, but it's also a lot more explicit. That's what I appreciate about it.

[00:29:55] AC: Yeah. I think it's a much cleaner separation of concerns.

[00:30:00] BH: Yeah. I think for me, I understand what your co-worker may have been saying for that. It's just that it's weird, because when we think of a project, think of it like you hand something to the child to say, “Okay. Now go do something with this.” Whereas, with the callback function, you're like, “Hey, here's this something to come back to me with, so that I can do something.” It’s like, why? That's so circular.

Just the child would tell you like, I don't know, call it if you're in the kitchen and the ingredients are prepped, ingredients are ready. Anyways, actually throw away that kitchen argument. I have something in my head differently.

[00:30:32] T: Also, the tooling supports debugging with events, because you can see if the event has been emitted or not.

[00:30:38] BH: Yes. That's a great point.

[00:30:41] T: I also like how much easier it is to see if the chain is broken. Because if you let's say, pass a callback through a series of components, but you also provide a default option as a prop every single step of the way, very hard to track it down, I think. I've heard it’s not.

[00:30:56] AC: There’s a lot of cringing going on.

[00:30:59] T: With events, you know that the problem has to either be in the component that's emitting the event, or the component that's listening for the admission. There's only two places you can check.

[00:31:10] BH: That might be the best argument.

[00:31:11] T: Yeah. You can see in the dev tools if it's been emitted. If it's not, you know it’s in a child. If it has been, you know it’s in the listener.

[00:31:20] AC: I have definitely had to resort to that many times. A lot of the times, it was ever being emitted. I was like, “Well, that explains it.”

[00:31:28] T: See, my main thing is I misspell the event every time.

[00:31:32] AC: I know. Definitely done that.

[00:31:35] BH: Yeah. When it comes to debating between two methodologies, I think whichever one can help me debug a problem faster, basically, usually wins hands down. I will reconfigure my brain if it will help me figure out problems faster.

[00:31:46] AC: Well, I think with that, Tessa, there's no more arguing about this ever, because you just won.

[00:31:51] BH: Yeah. Done. Slam dunk.

[00:31:53] AR: It’s so uber.

[00:31:54] T: I wanted an argument, where everybody agrees with me. Who could’ve seen it coming?

[00:31:59] AC: Actually, technically, you wanted an argument against yourself, because we always forced you to play devil's advocate for the other side. You beat yourself, Tessa.

[00:32:09] T: Oh, my God. Well, that's what I set out to do every day. Mission accomplished.

[00:32:12] AC: It’s a good thing it’s the last day of 2020.

[00:32:14] T: Oh, that’s right. It is.

[00:32:16] AC: I know. Thank goodness.

[00:32:18] AR: I'm going to interject in here and say, there is a place for passing a function as a prop.

[00:32:27] BH: Ooh. Alex coming in. All right. What's your hot take, Alex?

[00:32:31] AR: All right. Hot take. Vuetify has a perfect example of this. Validation function.

[00:32:40] T: That’s true.

[00:32:41] AR: Passing in a validation function as a prop to an input, so that you can make a generic input that will run newly updated value through it and you return true or false as to whether or not it is a valid argument.

[00:33:01] AC: Or you could just use Vuelidate and do it all in the parent.

[00:33:09] BH: I’m trying to think if I can come up with anything against that.

[00:33:12] AR: Since emit does not return a value, you can't actually run validations through emit. You have to pass in a function, or you have to do it in the parent, as Ari has mentioned. However, if a component has built-in error message handling, then it may be easier to pass in a validation function.

[00:33:35] T: I feel like, I've mostly done that with props in my experience, but I wouldn't be opposed to – If I saw it with callbacks, like if it was for a reusable library to me, I guess that makes sense. Because usually, you wouldn't personally want to mess with the library internals. I don't really like having rules for – I’m a 100% of the time, this is going to be correct, because it's not realistic. It's more in terms of when we're just making components day to day, everything I do, 95% of them with callbacks, or 95% of them with emits.

[00:34:05] AC: I mean, and I'm a 100% correct all the time.

[00:34:08] T: That’s true. That’s true. [Inaudible 00:34:10].

[00:34:11] BH: A 100% just put it on top.

[00:34:13] T: I think we should stop recording and just cut this episode immediately after Alex is like, “Wait, I have a counter example,” and just edit there. That’s your hot take, Alex. Then end of episode.

[00:34:24] AR: Here we go.

[00:34:26] AC: Next week on –

[00:34:31] BH: We've talked a lot about the new fun things about emit. Just for a refresher for those who might be newer to Vue, Alex, this will be the quiz question for you. In Vue 2, how is emit evoked? Versus what are some of the changes that have come with Vue 3 when it's being evoked particularly in the composition API?

[00:34:51] AR: All right. In Vue 2, you can evoke emit by using this.$emit. You pass it a string and a thing, string.

[00:35:09] T: String and a thing. I love it.

[00:35:11] AR: It's the event payload.

[00:35:12] BH: Optional.

[00:35:13] AR: It’s optional. That is how you emit. You use this.$emit. I think there's a way to do it, where you can get the global Vue object and you can also do Vue. something around. That gets complicated. Don't do that kids. That's not a good idea. Unless, you really know what you're doing. Which I don't apparently, so it's fine.

Then in Vue 3, if you're using the standard way of doing things, the traditional options API, you can still use this .$emit. But if you were using the composition API in your setup function, you get two arguments: you have props and context. Within that context object, you have three things. You have attributes, you have slots, and you have an emit function. This emit function allows you to emit events up to the parent. Within your setup function, you can call that emit function and it will, when triggered, emit an event up to the parent.

[00:36:20] BH: Well done. Well done. I'll pass the next pop quiz question to Ari. How can you tell when a component is emitting an event? When the child components in a parent, what signifies it differently from props, to say that, hey, when this event happens, do this thing?

[00:36:37] AC: What? You asked me.

[00:36:39] T: When did this become a game show? What do we win?

[00:36:43] AR: It’s always a game show. Welcome to Enjoy the Vue.

[00:36:49] BH: Welcome to the bonus round.

[00:36:51] T: Oh, no. The Benus round.

[00:36:54] BH: We know that when we – Ari, in a parent component, how do you listen for an event on a child component?

[00:37:04] AC: That would be through the V on directive, Bean.

[00:37:08] BH: Oh, very good. Very good.

[00:37:12] AC: You can also use the shorthand of the app symbol instead, which is what I personally prefer, because for some reason, my brain totally understand that.

[00:37:22] T: Yeah. Honestly, I always forget V on is a thing. I was like, “V on listeners? What?”

[00:37:26] AC: A thing. Duh.

[00:37:29] BH: For those, I'm picturing it at home, basically as we said, when you emit the thing, so the first argument which is required is your event name. If you have a button that say, enlarges the text in the parent, then you would say, it will be emit-text, for example. Then on your component that's being called in the parent, you would have the app symbol, and then enlarge-text. Then whatever function you're going to call it in the parent to then enlarge in the syntax. That would be the syntax around that.

[00:37:57] AC: There are some nuances here, though, that maybe we should talk about, but we're running out of time.

[00:38:02] T: I mean, my big one is always you can't put a console log directly in a template, because that was totally going to be my answer for do you know how do it works? Console log it. You also, to make that temporary console log function that you can pass into the template.

[00:38:17] BH: Fair enough. I guess, Ari, there’s a specific nuance, it might be worth just mentioning, because we can – if you want to just –

[00:38:23] AC: Well, things that always end up tripping me up is when you are passing a payload, how exactly that happens and how much you need to actually specify in the template, which is nothing. Because, yeah. This was the whole thing earlier, where I was talking about do you invoke the function? Do you just have the function name? Yeah. If you just pass it the function name, it will automatically pass the payload argument to the function, I believe. Okay, please correct me if I'm wrong. If you actually want the event, you do have to specify the event with $event, right?

[00:39:00] BH: I think that's only if you don't pass a payload. Then by default, it'll pass the default event object. The moment you add a payload, then that's when you need to [inaudible 00:39:08] define it.

[00:39:10] AC: Yeah. See? That’s a nuance that I feel like we needed to talk about.

[00:39:17] BH: Yes. We'll include the links to the docs. Because this one's a little bit hard to explain, I think, over audio. To Ari’s point, basically, when emitting an event, if you want the actual native event that's passed, so where it's all your attributes and stuff that you would normally get from the browser, I think normally, you have the defined as $event when you're passing a payload as well. Versus and if you don't have a payload, meaning a custom thing you want to send up to the parent, then it should pass natively. Hopefully, you can check that out in the docs. If you have additional questions, you can ask Ari at @gloomyloomy.

[00:39:49] T: Whoa. To clarify though, when you say passing a native event, you mean the event object, right?

[00:39:55] BH: Correct.

[00:39:56] T: Okay.

[00:39:56] AC: That has event.target.

[00:39:58] BH: Yeah. Or event.parent. I recently did a whole thing traversing a node doing that.

[00:40:05] AC: I have done that. It never ended well for me.

[00:40:08] BH: Then I was like, actually, just select a different element. This is stupid. I just added stuff to HTML. I'm not traversing stuff. Cool.

[00:40:16] T: One thing that’s not clear to me looking at the dots for Vue 3 is with the options API, do you have to specify the events in the emits option? What's different?

[00:40:30] BH: No. That's a great question. Unlike props, where I think if you don't define it at all, then I think it's just not going to know what to receive.

[00:40:38] AR: It goes on the adders object at that point.

[00:40:40] BH: Yeah. Emit technically, there's nothing requiring you in the compiler that will stop your build. If you randomly emit events in your component and don't define them in the options. They're not tightly coupled at the moment. That's not to say that, for those who are thinking like, “What if I want an opinion on those sorts of things?” I would say, this will probably make the style guide at some point, too. If you're defining a custom event in your component, it should be in the midsection. They should be one to one.

I imagine either whether it's through Vitter, or Rahul’s new Vue DX plugin. I imagine, we'll probably start adding some rules, to let you know that you have custom events being emitted that are not documented in your emits options. These are things that we will probably be starting to recommend in the style guide, I think as Vue 3 begins to grow, and people test out things.

[00:41:26] T: Okay. Yeah, because right now as it is, it's very confusing. It just is, like you can define them there. Ari, don't look. One of the examples is in camel case. Then below, it just talks about validation. It almost seems it's really just for validation, so it's a little bit confusing.

[00:41:41] AC: I can’t believe camel case. How did that get past you, Bean?

[00:41:44] BH: I know. I spent all my time reading everything and I missed that one thing. Gosh. That was a great question, though. We will make sure to – Or honestly, Tessa, you could issue a PR, or Ari.

[00:41:58] T: Oh, my God. Yeah. I mean, my first PR role, we took like what? Three months, right? Just kidding. I'll set in a PR.

[00:42:06] BH: All right. Well, I think with that, it's time to wrap up this episode and move on to this week's picks. Tessa, would you like to kick us off?

[00:42:16] T: Okay. My first pick is from Tony and Chelsea Northrup. They posted a new ask us anything video last night. I just thought it was a really fun and cute, lighthearted watch. Chelsea’s sweater is gorgeous. Tony talked about his favorite dinosaur, which I thought was hilarious for some reason. Then they had this interesting, interesting thing where they talked about how people took Tony seriously for dressing up as a doctor on Halloween. People wouldn't believe that he wasn't a doctor, even though he kept on telling them it was a costume. Yeah, there's a lot of interesting points made throughout that video.

Also, recently, I've been listening to Mediocre, which is a book by Ijeoma Oluo. I thought it was mostly going to be about present-day America. Basically, I kept seeing excerpts and reviews pop up on my social media feeds. I was like, “Fine, I'll read it now, instead of later.” Actually, most of the books so far, I'm about halfway through, has been about history. I learned a lot about Buffalo Bill, who is a prominent character, I didn't really understand in some play. I had to be in as a kid. It talks about white supremacy and how it gets internalized into society.

It's really interesting. Also, for the audiobook, depending on your vendor, you may not be able to listen to a preview. Her voice is very smooth and relaxing, which is great, but also a problem, because then I get too relaxed so that I fall asleep, but it's great. Then my third pick for the week is Fire Emblem Three Houses. Apparently, there was a cindered shadows DLC that I didn't realize and it comes as part of their expansion pass package. It's a whole new set of missions and characters. The best part is, if you clear it, a lot of the parts of the main game that can be tiresome, like returning lost items, or having tea with characters, this all sounds very weird if you haven't played the game. Even if you have played the game, it's very weird. It gets a little bit less frustrating. That is a very nice bonus. Those are my picks

[00:44:18] AC: I can attest that she has been playing it a lot, because she keeps popping up. Well, I've been playing a lot. That’s big.

[00:44:26] T: Oh, no. Exposed. Oh, that was one more argument for callbacks that popped into my head when we were talking, is if you use callbacks instead, you reduce emissions and that's good or something. It’s very eco-friendly.

[00:44:46] BH: All right. On that punny note, Alex, you're up.

[00:44:50] AR: I only have one pick this week. I have a family friend who works at a local food bank. They have been very overwhelmed this year. It's still 2020 as of this recording, and a lot of food banks have just been overwhelmed with people who need assistance. I'm suggesting as my pick, go help your local food bank, give, donate food, donate money. They help out your local community. I'm dropping in a link for Feeding America and they will help you find one that is close to you.

[00:45:30] T: I think also, if I may add on on that note, one of my friends mentioned that you can also donate to your neighborhood mutual aids to help out with groceries in your local area. I'll drop a link to that as well.

[00:45:43] BH: All right, great. Then Ari, what do you have for us this week?

[00:45:47] AC: I have a Netflix series. Actually, I don't know if it's an original series or not, but you can find it on Netflix called Manhunt Deadly Games. It is about the bombing of the Atlanta games in Centennial Park, which happened and I want to say ’96. Yeah, ’96. I didn't remember a whole lot about it, even though I was 10. Oh, God. I was 10.

I didn't look up a lot of stuff, because I didn't want to spoil things for myself, so I'm not going to spoil things for y'all. It's about everything surrounding that. There's some very interesting things that happened surrounding that. Yeah. It's addicting. You're going to end up enjoying it. Just trust me. Don't start it late at night.

[00:46:35] BH: I'm surprised. I thought your pick was going to be Bridgerton.

[00:46:38] AC: Okay, don't get me started on that.

[00:46:41] T: I want to hear all about this.

[00:46:42] AC: As a middle-aged white woman, I am trying not to give in to being such a middle-aged white woman. I am trying to resist that so wholeheartedly, because I'm a huge Grey's Anatomy fan. I can't throw one more towel in, dammit.

[00:46:55] T: Oh, my gosh. For some reason in my mind – middle-aged always started at 40. I'm like, “Middle-age?”

[00:47:02] AC: I mean, compared to 20-year-olds, I'm super old. I’m 34, in case anyone wondered. You probably could have done the math on 10 and ’96.

[00:47:16] T: No, you over estimate, at least for me. [00:47:18] BH: No, I figured with your love of the crown and figured Bridgerton is just right up your alley.

[00:47:23] AC: I know. Okay. This is going to sound very weird, but my entire life goal, the overarching theme of my life is I don't want to be basic. I just feel like watching Bridgerton just puts me square in basic territory.

[00:47:37] T: Does it?

[00:47:38] AC: I will probably watch it anyway, though. Darn it.

[00:47:41] T: Wait. My question, when Bridgerton came out, because I know that Shonda had that thing with ABC, did Grey's Anatomy end?

[00:47:49] AC: No. Grey's Anatomy is still on.

[00:47:51] T: Oh, okay. I thought she severed ties with ABC.

[00:47:54] AC: This is news to me. I mean, there's still episodes coming out. I don’t know.

[00:47:59] T: Yeah. I thought that's why she was on Netflix. I could be wrong. Let me know. You know where.

[00:48:05] BH: All right. Well, then y'all can look forward to I imagine whenever Ari succumbs to the Bridgerton temptation.

[00:48:11] AC: I will never admit to it, though. Just saying.

[00:48:16] BH: All right. Well, that said, I think the last one is me. I have to picks for y'all. First of which is when I believe I've actually mentioned before, but I recently re-watched Street Food Asia. Particularly the first episode, which is on Bangkok, Thailand around a street food vendor named Jay Fai. She basically sells cheap food on the side of the corner on the street, but she's a one-star Michelin awarded chef.

This series basically goes through different stories of people who come from non-traditional backgrounds, when you think of high-quality food and those things. She has a really miraculous story, regarding just not only her upbringing, but then just the amount of obstacles she encountered over life in order to get to where she is today. Incredibly inspiring. If you love Thai food and just watching delicious food being made, absolutely worth watching. It looks like, Ari remind me, I may have picked actually our first episode. Talk about a callback, given that they started the show this year. On the last day of the year, we are calling back.

All right. With that, my second pick is for those who are into the second brains that are cost in productivity nerdom, I've been exploring Obsidian markdown editor. It's basically, what's interesting about it is compared to other things like Rome notion and other things, Obsidian just uses your native file system, AKA, like you own all the markdown files. Then it finds ways to stitch them together through internal linking, do basically graph linking and showing how notes relate to one another.

They did a really, really good job. Basically, it's free for users to basically try out. If anyone wants to talk about second brain, that stuff, definitely recommend checking out Obsidian. They did a wonderful job with that. That is all of my picks for this week.

With that, thank you, everybody, for listening today. Until next time, enjoy the Vue.

[END]