New in Vue 3: The Composition API

[EPISODE 48]

[00:00:10] BH: Hello, everyone. Welcome to Enjoy The Vue. I’m Ben Hong. Today on our panel, we have Ari.

[00:00:15] AC: Hello.

[00:00:17] BH: And Tessa.

[00:00:18] T: Hi.

[00:00:18] BH: Today, we’re here to talk about a feature that you’ve probably heard about when talking about Vue 3 and that is the composition API. To kick us off, I guess, Ari, what are some things you've heard of about the composition API?

[00:00:32] AC: My mind would go blank as soon as you ask that. What I’ve heard about it, or at least my general understanding of it is that it allows us to break down parts of a component into pieces that we can use across multiple components.

[00:00:49] BH: Great. What about you, Tessa? What are your impressions of the composition API?

[00:00:53] T: Oh, see. Now, I feel flustered, because I was prepared for the question you asked Ari, which is what have you heard. I was thinking about that.

[00:01:01] BH: What have you heard totally works too.

[00:01:03] T: Yeah. Well, the first thing I remember hearing was that it was replacing the options API.

[00:01:08] BH: Big disclaimer. That isn’t happening. Big disclaimer.

[00:01:12] T: Okay. Actually, actually, I guess, technically the first thing I heard was that hooks were coming to Vue. Then I think at the conference we were at, where Divya – I think this was VueConf in 2018 maybe, Divya was going to give a talk about hooks. If I recall correctly, I think that's where Evan talked about, “Well, we're moving from hooks to this composition idea.” I’m not sure what the difference is. That's just my vague memory from hearing about it through the crowd. Yeah, and then the next thing I remember was oh, it's not replacing the options API.

[00:01:43] AC: I also still don't really understand what hooks are in React, so there's that. Yeah, I heard the same thing. It's like, hooks. I’m like, “Whatever that means.”

[00:01:51] T: Yeah. I did a workshop on hooks and my one takeaway is “oh, I don't have to write classes. Perfect.”

[00:01:59] BH: Yeah, the way at least I think of hooks is just rather than our traditional paradigms of props, or slots, so in React, rather than a pass down method, it's a little bit like the event bus where you have this thing that things can hook into, so that you can –

[00:02:13] AC: Stop saying bad words.

[00:02:17] BH: It's a little bit the provide inject idea too, where you have this provider and then it can inject into different components, rather than it needing to be a child of something, or whatnot. It's more of a shared functionality concept, at least from what I’ve used in the React hooks ecosystem.

[00:02:32] T: Okay. Well, that's perfect, because provide an inject is another API I happen to be a complete expert on.

[00:02:37] AC: Me too. We're kidding. I just didn't know.

[00:02:41] T: Yeah. You don't have to have a direct parent-child relationship to share data across components. Is that the correct takeaway?

[00:02:48] BH: Not even just data. Just even functionality, because you could provide functions that other components might want to use. It's really like, think the mixins idea right so more of us are familiar with mixins, where you can refactor a component that will share search functionality in different places. As we know, mixins has its gachas when it comes to side effects and not really being able to track where things are coming from, just because of the way it happens to be named and the way it's imported.

Composition API is really the solution to this feature that people have been wanting, which is the ability to share features across different components in a way that's modular, but in a way that also, you can maintain and track.

[00:03:24] T: What did you mean about side effects?

[00:03:26] BH: Side effects, meaning sometimes you have either naming collisions with the mixins that you don't know what's inside your mixin, so it's a little unclear as to whether or not something inside of it might have another effect on your reactive data, especially when people are relying on it at a bigger scale and you had a lot of things touching the mixins, or what's inside of it. That's what I’ve been, as far as side effects. Just things that you just like, wait, where did that come from? It's not supposed to work like that. It's like, oh, actually when you look at it, it is. It's just not intuitive.

[00:03:53] AC: Yeah, my favorite is when I’m looking at a component and I missed the line at the top that said mixins. Then I see this prop somewhere down in there and I’m like, “What? Where is that?” Then, so I search in that file for it, but that's the only place it is. Then I delete it, and somehow everything's broken. I’m like, “But.” Then I see mix and I’m like, “Oh, crap.”

[00:04:15] BH: Yeah, that sounds about right.

[00:04:16] AC: Okay. Then why is the composition API better? How does it solve this problem?

[00:04:22] BH: Yeah. The reason why composition API is so interesting to people is because what Vue is allowing you to do right, with the options API, it was very explicit as far as where you kept things. Data goes here, computer goes here, methods goes here. It's very consistent. I think, one of the reasons why a lot of us love it, because that helped us to keep code organized in a way that made sense.

As we know, as certain components grow to a size where it doesn't always make sense to refactor to a separate component, now you find yourself when you're editing a feature, you're jumping up to the data block, but then down to the methods blocked, but then up to computed and then maybe back. Then so this is not how we would write code naturally in this particular case. It might make more sense if you're writing JavaScript to just declare your variables up top, modify a couple of things and have a single basic thing of a utility.js file that contains everything you need from the feature. That's what you would typically want from a writing experience. You're authoring a feature that jumping around can be difficult when you have multiple features colliding with each other. Does that make sense?

[00:05:17] T: I guess so. I don't think I’ve ever thought about what way to write code is natural. I feel I do a lot more jumping around when I’m coming into a new component, versus when I’m writing my own stuff.

[00:05:27] BH: Yeah. I think maybe the easier way of thinking, there's a classical example in one of the blog posts that Chris Fritz wrote, where he color codes the scope within an options API, like what is relevant to what. If you're doing a search functionality, data might have search input, the computer might be process search input and then you might have an API call in your methods. Then again, so you have these things spread out. When you conflate that with filtering and you conflate that with something else on your page that's doing and your data stores your VUX modules, you want to be able to name space them in a way that you can track.

Rather than having one big instance of stuff happening by splitting them up into individual pieces, which is why mixins were what people's original approach to mixin swatch. Break off those pieces like a search mixin and then inject it in and then you're good. Except, as we know, mixins has its downsides. Composition API aims to allow you to do that in a way that doesn't have the side effects that mixin does.

[00:06:24] T: Can you expand further on what you mean by conflate data with filtering?

[00:06:28] BH: Yeah. I meant from a functionality perspective. For a search functionality, you might be tracking what the user is typing in and you might track what the response is. Those different pieces of search that are important, like the overall search functionality. Then when you're filtering something, that might be different. That might be another form that tracks what checkboxes the user's ticking off that will impact how data is maybe computed to render on the screen.

You have these really from a functionality perspective, they're scoped in what they're doing, whether you're searching for something, whether you're filtering for something. In the options API right now, all that gets mixed up together, like broken up amongst the data, the computed, the methods and life cycle hooks. This can make it a little bit of a spaghetti code when you're trying to maintain things, because it's hard to see what touches what without running into other code that has nothing to do with the code you're trying to touch. Because that's what we like about components. If you're modifying a button, you're not modifying the list at the same time. You're just modifying the button.

In components when you have so many features that it's hard to tell what's talking to what anymore, this is really where people start to want to break things apart. This is where composition API can shine, basically.

[00:07:39] AC: For me, why the composition API would be useful really clicked, only once I had been in a project for a while and the scope of certain features had grown, you start off with a relatively simple feature. Then over time, due to business demands, you need to add another layer onto that feature. Okay, one layer, that's fine. Then when you start to have four layers in one feature, I would always start by trying to keep things in order of when the feature was added, so that I knew that things at the bottom of data went with things at the bottom of methods and the things at the bottom of computed properties. After a while, that all starts to get mixed up.

[00:08:24] T: Up, or mixed in?

[00:08:26] AC: Then I was like, “Oh, that's why. That's why you want it. Okay.” Because then, I can just take others out separately and then put them in a big pot at the end. I was trying to give a more specific example of what type of thing you would layer features onto, but I’m somehow completely drawing a blank. I feel everyone has had that experience though, where something started small and they were like, “Oh, what if we added this? What if we added this?” You're like, “Oh, God. Please stop.” My component is now a thousand lines long.

[00:08:56] T: I think Damien has an exercise like that, where he's like, make a button with text on it. Then he's like, add an icon. What if you need a loading state? What if this? What if that? It just becomes a disaster.

[00:09:10] BH: I think Ari brings up an excellent point that when composition API just hasn't quite clicked like, “Why would I need that? The options API is working for me.” That's great. That means you don't need it. I think that's really important to emphasize here is that this is not something you need to go and rewrite your app in. It's a technique that when you have this problem that you need, just like in Damien’s button example, there's a reason why a component that's props heavy becomes very difficult to maintain, because now you basically have to read documentation to use it. Why slots becomes an incredible asset and tool to solve a problem of too many props. Similarly, the composition API is not like, drop the options do composition. It's an additive thing that when you have a problem that it can solve, it's really great for that.

[00:09:50] T: What I’m hearing isn't that there's necessarily a correct, or intuitive way to write code, so much as these are two different ways to organize, or compartmentalize your components code.

[00:10:01] BH: Yeah, that's totally fair. To say that it's about intuition, yeah, everyone writes code differently. I do take that back. That is so fair. There's a different mental model and paradigm for how one might organize their code.

The other thing to keep in mind with the composition API, which I think a lot of people don't realize is that what it's really doing is as we talked about options, we have these blocks where we define data, computed, methods and life cycle hooks. I see those as guard rails. You had given us a clear path for how to do certain things. Composition API takes all that away and says, “Here are all the tools available to you. Good luck.”

That's I think, an important flip side that has to be considered here is that now when it comes to code architecture and when it comes to how things should be organized, or more or less, how things even worked, now there's a lot more of a learning curve to this, because now, Vue basically says, “Here, you can do things and treat reactive data the way you want. You can do things and organize the way you want.” Now, this means you need to know how everything works. This is probably the biggest gotcha when it comes to the composition API, because now there are the additional learning curve when it comes to getting ramped up on it.

[00:11:11] AC: Okay. Ben, as we all know, you are a member of the core team. Has there been any concern raised that you may have just handed users massive foot guns?

[00:11:22] BH: Yes, a 100%. There were lots of concerns as far as foot gun. For those who might not have heard that before, basically, the idea that you would make mistakes that we might have been able to protect from otherwise is the idea from trying to avoid foot guns.

[00:11:34] T: Wait. Sorry, I understand why we want to avoid foot guns. Can you explain what a foot gun is?

[00:11:40] AC: When you shoot yourself on the foot, it comes from that. We're handing you a gun, specifically to shoot yourself in the foot.

[00:11:48] T: Great. Where do I sign up?

[00:11:52] BH: I think to Ari's question, this is incredibly important, because like any technique in Vue, there are actually a lot of times escape hatches to how things are normally done. Because for example, you don't have to use templates in a single file component. You can use a render function. Those escape hatches always have foot guns, because with freedom, there's basically the possibility you'll make a mistake, or something – basically, something to go wrong. I think, this is actually one of the things that makes Vue powerful is because when you don't need it, it's there, it provides the safety rails to make sure everything goes fine.

In the moment, you need to hack something that's a more custom. Vue doesn't want to be so opinionated that it keeps you locked in. I think that was one of the problems people had is that they found that the options API in certain context ended up boxing them in and either choosing certain software anti patterns and those things. It end up creating basically, an unpleasant developer experience, because you want to be able to break out when you need to. In that regard, that's why it's so important to remember that the composition API is additive. Then yes, it comes with foot guns. Yes, there are going to be weird gotchas.

When you're using refs to create reactive properties that there's value, there's these things you'll have to start learning and picking up. Again, that's all the more reason why to remember that. If it's not something you need to use immediately in production, there's not necessarily a reason to rewrite it. Certainly, play around with it in your own code bases. I know, I myself are building little fun side projects, where I just use the composition API to see how it feels and what gotchas there are. Otherwise, it's not something that you need to immediately go out and learn, unless you have a problem you're trying to solve with it.

[00:13:21] T: It's interesting to hear, because from my perspective playing with Vue 3, I feel has gotten a lot more opinionated. Just using the same defaults I did with Vueu 2. Every time I write some code, the linter is like, “Well, we're not going to build the app, because we don't like the way you wrote this.” I’m like, “It's my side project. Let me do what I want. Stop blocking my trash code from building.” I digress.

[00:13:42] BH: Do you have a specific example of when that happened?

[00:13:43] T: It happened last night. I don't remember why, because it was last night. My brain resets. Yeah, going back to composition API, what would be a good way for users to start learning how it works and understanding when to use it?

[00:13:57] BH: Yeah. This is one of those things where because composition API is so new, the learning resources are a little bit more limited. Certainly, I would say check out the docs, but we're still also as we're exploring the best ways to teach this and what things people might misunderstand. It's a good place to start.

I know that Lachlan Miller, who's also on the team, recently releases a Vue.js 3 composition API course. You can find it on Udemy. We'll drop it in the show notes. I know he has a whole thing dedicated to that. That does come with typescript too, but there's starting to be more resources on this, but I have taken some of his course already and can definitely recommend it. Even if you don't have a lot of typescript experience, he walks you through it. Don't let that scare you off if you see that.

Yeah, docs and honestly, the team is still looking to always explore what the extent an impact of the composition API is. Always feel free to reach out to us and then file some issues and ask questions in the docs issue repo, so we can better understand where everyone's head's at.

[00:14:52] AC: Maintainers love it when you complain loudly.

[00:14:55] BH: Please give context. If you just go on like, “It doesn't work,” that doesn't help us.

[00:15:01] T: Yeah. I was trying to read up on the composition API last night in preparation for this episode. At least as of recording time, I found it really hard to find in the docs, because I was looking through the table of contents and it seemed it was organized in a really functional, or I guess, specific order with the things you need to get started up and then components in depth. I was really expecting it to be in components in depth and it wasn't there. Then I was like, “Okay, it'll be under reusability and composition, because it's the composition API,” and it wasn't there. I felt silly that it took me so long to find it at the bottom, but I found it a bit confusing that it was all the way in advanced guides.

[00:15:38] BH: Yeah, that's great feedback. It's a tricky thing when we were talking about the information architecture of this, because while those places you mentioned are places that would have probably been, I guess, I’d say more obvious for people to see, we've known that from the past when people read the dots, when they're included either in an essential section, or components in depth, there's this almost semi expectation that you need to know this.

We wanted to avoid the impression that the composition API was basically critical to advancing your Vue app and your Vue knowledge. That's why topics like reactivity in depth and the composition API were at least at the time it's recording, under an advanced guide section, just to make it explicitly clear to users. This is not something you have to learn. This is something that when you need it and you want to look for it, here it is. I mean, to your point, there's something to be said about maybe other ways we can still achieve the same impact without making it harder to find.

[00:16:31] T: Yeah. I guess just for me, composition is one of the biggest jargon words that I hear said a lot. I really thought the composition API would be there. Also, if I didn't know about it, it reminds me of the saying about how do when you need a flux architecture? Well, when you need it, you'll know. If you don't know, you don't really know any context for it, or have any idea of when you'll get to that point where you know you'll need to know it. If I don't know anything about reactivity and composition API and how that plays into the rest of the stuff, but I know Vue essentially is all about reactivity and there's this composition section. It's like, how do I understand when I need to use these things and how they fit into the context of you as a whole?

[00:17:09] BH: Yeah. That's totally fair. I’ll definitely will take that feedback back to the team.

[00:17:12] AC: I love those explanations. You'll understand it when you need it. Okay, chicken and egg. I’m totally guilty of having given that answer to someone, especially about flux architectures. Then I think about how, because I actually had that experience where I didn't really get something, until I needed it. That was specifically, I was on a lovely polymer project.

[00:17:37] T: Everybody savored it.

[00:17:39] AC: Yeah. That was when I realized that I needed redux. Honestly, the only reason I knew to reach for it was because when I was at a boot camp, I saw this flyer in one of the bathroom stalls about a talk for React and redux and how you know when you need redux. It said something about state management. I was like, “Wait. Is this when I need it?”

[00:17:58] T: Nice.

[00:17:59] AC: I didn’t look what it was. I was like, “Oh, this is when I need it.” Yeah.

[00:18:02] T: If you take it to its logical extreme, I feel like, it's when you don't know about when you would need that thing and you're in a position where you're like, “Nothing works. I need something else.” At that point, you're very vulnerable. Any solution somebody gives you, you'd be like, “I’ll take it.”

[00:18:15] AC: Yeah. Like redux.

[00:18:18] BH: Yeah, the tricky part on the flip side of that is that when you give people too much information upfront, then people get paralyzed, or either they try to find reasons to use that technique and that's what we also want to avoid, because again, because of as you mentioned, Tessa, there was that impression that composition API is going to walk in and replace all the options API stuff.

Things like this will take a long time to dispel and I think it'll still continue to permeate, unfortunately. We unfortunately, have to try to guard against it as much as can, because again, the options API on its own, you can do so much with it. You don't even need the composition API. I’ll make sure to take that feedback back to the team for sure.

[00:18:53] T: Yeah, I guess so. I mean, my impression was not that that idea stemmed from anything with regards to docs organization. It was more about language and the original RSC. Yeah, I don't know. I think it was in context and had warnings there. Maybe that would be helpful. Yeah, just in case anybody else is listening to this and wondering where it is, scroll down to the bottom in advance guides and you'll find it there.

[00:19:15] AC: Yeah, I sometimes worry about diving too deep into the composition API, just because whenever there's a shiny new toy, people like using shiny new toys. I also feel like, sometimes a shiny new toy is not the right thing to be playing with in the moment, at a funeral or something, or when your app becomes your own funeral, because you got too involved in the composition API when you didn't need it. I’m really afraid of it, to be quite honest.

[00:19:46] BH: Understandably so. That's why I think what I recommend people do is just create some small apps with it. Again, as more tutorials and courses come out, then I think those will help to provide a little bit more of that playground environment for people to see what exactly is happening, so we'll need some time on that.

[00:20:03] AC: We've talked pretty broadly about the composition API. What are some of the more specific features of it that we didn't have before? What is exposed by the composition API?

[00:20:14] BH: Yeah. The number one thing you'll see with the composition API, which is universal, is the setup method, which basically you can think of it a little bit like a life cycle hook, because it instantiates and runs the code at a certain point in the component life cycle. When it comes to that, you'll see that when people run the setup, again, I would say – again, it's not running at the same time, but think of it the mounted lifecycle hook. That's what people are most familiar with.

It's just like, when the component is starting up, setup will do things too as the name says, like set things up for use. As far as things that it exposes to us, helper methods – importing helper methods from you is going to be probably become a lot more common in Vue 3. That's going to be a little bit of a change. For example, one of the things a lot of us do is code splitting our components. The way we typically do this in Vue 2 was we would just write an anonymous function that returns the import of the component. This is a common pattern found in Vue router, for example, so that the component is only imported when you're actually trying to load it.

[00:21:13] AC: I feel you used a lot of big words that maybe we all are doing, but did not understand those words. You lost me at a lot of us do code splitting.

[00:21:26] BH: Okay. Maybe we do this inadvertently. For anyone who's using Chris’s enterprise boilerplate, I know this is done inside of his routes file. When I say code splitting, basically, when we think of the code bundle we're delivering to the user, if they're only loading the home page, we really don't want to deliver them the user page and then the item page. They don't need that stuff yet. Code splitting, a lot of it – this is what Vue does really well for us. A lot of times, it does it automatically for us certain things. It tries to be as performant as possible.

One of the techniques Chris taught in his workshop is the ability to code split components, which is by running an anonymous function that imports the components. Basically, tells webpack that like, hey, this thing that the user might need, split it off. They don't need it right now. They might need it later. That's why it's a function that we'll call the import. You basically go fetch the bundle that it needs.

[00:22:15] T: We've talked about a lot of different aspects of the composition API today. I’m curious how everyone would sum this up for our listeners. Is there one core thing that you want them to take away?

[00:22:26] AC: I’ll start it off. I think that it's important to remember that just because you can use a tool, it doesn't mean you should. If we want to continue to make Vue accessible to new developers, which I think that that's something that is important for us to continue to do as a community, I think we need to realize that the more accessible option will continue to be the options API. I would just say, use sparingly.

[00:22:52] BH: Yeah. Can't echo Ari’s point enough. I know there are plenty who will like a lot of the ergonomics that composition API provides. Remembering that the ability to use composition API is something that is additive and used to enhance your code and basically, try to avoid pre-optimizing, because some people will try to avoid certain things like, “Oh, what if I run into this really niche case?” When you run into it, that's the time to use it. Trying to do it in advance of the problem is the traditional pre-optimization is the root of all evil cliché in programming. What about you, Tessa?

[00:23:25] T: Yeah. I agree, especially underscoring Ari's point about just because you can use something, it doesn't mean you should. When I think about the previous team I was on, we had a ton of components, but I don't really think we had a lot of need for something like the composition API, where on my current application we have a lot of higher order components and gigantic mixins. That's a case where I feel maybe a combination of the composition API and moving some things into the store could be very helpful. That being said, there are so many components that I’ve worked on, where I don't think that I would have needed the composition API and the options API, at least to me, made for a lot more readable component. I am curious going forward, to see what example use cases the Vue team comes up with.

Right now, the composition API reminds me a little bit of when I was using React a few years ago. Sometimes you wrote a component one way. Then if you wanted some other functionality, you had to refactor it to be a completely different way. Right now, it feels a little bit to me like that, so I’m curious how the ergonomics will stay the same, or get its edges worn away going forward.

[00:24:34] BH: Yeah, it should be an interesting discussion to see how the team and the community goes forward to push the limits and boundaries on the new paradigm. Cool. With that, it is time for us to move on to this week's picks. Ari, would you like to get us started?

[00:24:49] AC: Sure. I have one pick this week. It is Marvel app, which is not what you think it is, unless you're already familiar with it. It is basically a rapid prototyping tool that is so easy to use, that non-technical people on your team can use it and contribute to making new designs, new designs, designs, complete with click-throughs for any new functionality that you want to mock up.

[00:25:17] BH: Very cool. Tessa, how about you tell them?

[00:25:20] T: Yeah, it's funny, because design reminds me of that HDTV show that's not on anymore. Designed on a Dime, where they are always like, “You can DIY this part of your house for cheap.” It looks awful, but it's always really fun to see what they came up with. It's not a metaphor for my code base, or that's confidential. It's funny, because my pick for this week is a school in California called Concept Design Academy. I’ve been taking a few classes there. It's really fun.

Also, it's nice to be in a situation where I’m getting feedback regularly and I feel confident that it's a pretty safe environment. I’m not afraid to get feedback and I get it on a regular basis. It's just really nice. Also, I think it's always fun to be in a learning environment, post when people are required to be in school, because people want to be there learning the thing. It's always just really exciting to be studying amongst classmates who are trying to achieve personal goals. Yeah. If anybody is looking to learn some technical drawing skills, I would recommend this program, although maybe not more than two classes if you are working a full-time job, and/or have not studied art before.

Ben, do you want to share any picks? Did they happen to be the Marvel app and CDA, Concept Design Academy?

[00:26:38] BH: No. You both stole my picks. Ah, how could you? All right, so my pick for this week, I guess, is the new iPhone 12 Pro, which I got recently and have had a chance to use for a little while. The screen, I do enjoy the larger screen size without being overly large, then we had to order the max size. For those interested, if they're about upgrading, I would totally recommend the iPhone 12 Pro. I have the blue one. It's a nice shade of steel blue. Yeah, that is my pick for this week.

[00:27:06] T: Of course, he has the blue one.

[00:27:07] BH: Yeah. I figured it's on brand. Super blue.

[00:27:11] AC: Okay. Quick question. Why did you choose the Pro over the regular model, or did you even have reasons?

[00:27:17] T: Right. Just because you can, doesn't mean you should. Good question, Ari.

[00:27:22] BH: I believe yeah, the specs on the cameras were better, as far as functionality. For those who don't know, I’m on the iPhone upgrade plan. I just basically, whenever they have upgrades, it's just swapping it out for the latest one. I figured I might as well get the highest end one.

[00:27:36] T: Is there an insta or something where people can see these photos?

[00:27:40] BH: I am trying to get to the point where I’m actually reviewing a hardware on the YouTube channel, so we'll see about that in the future.

All right. Well, with that, thanks everybody for listening today. Until next week, enjoy the Vue.

[END]