Opting into the Composition API with Oscar Spencer

[EPISODE]

[00:00:10] T: Hey everybody, and welcome to Enjoy the Vue. I’m Tessa, and today on our panel we have Alex.

[00:00:17] Al: Hello.

[00:00:18] T: Ari.

[00:00:19] T: Hello. And our special guest for this episode is Oscar Spencer. Hi, Oscar. 

[00:00:25] OS: Hello. Hello. How’s it going?

[00:00:27] T: How are you?

[00:00:29] OS: I’m doing quite well. Best I can be.

[00:00:32] T: That’s good. It’s been a while since we’ve had you on the show. Would you mind introducing yourself for new listeners?

[00:00:38] OS: Yeah, absolutely. As you said, my name is Oscar Spencer. I am a or at least I primarily used to be a frontend engineer. I’ve been doing Vue.js for a little over three years. I was a React developer before that. These days, I’m mostly working on web assembly things, which is a lot of fun. But I’m still a JavaScript boy at heart, so I’m here for it.

[00:00:59] T: Nice. Seems like you’re always moving to new targets.

[00:01:04] OS: Yeah. Always trying to do what I can. Just kind of keep moving along, even if the world doesn’t want to around me. 

[00:01:09] T: Oh, yeah. That’s a mood.

[00:01:11] OS: Yeah.

[00:01:13] T: Very important question for all of you. What sound does your work Slack make when you get a new message?

[00:01:23] Ar: I’ll go first. Plink, because I like it short and sweet.

[00:01:27] Al: Default, because I’m basic.

[00:01:32] Ar: A monster. 

[00:01:32] T: I was just thinking a monster. [Inaudible 00:01:35]

[00:01:36] Al: Yeah. That’s me.

[00:01:39] OS: And yeah, for me, we use Discord as our method of communication. So it’s just the discord sound. It’s the best.

[00:01:50] T: Yeah, make it your ringtone. You just work to the sound of the discord alert?

[00:01:53] OS: Yeah, exactly.

[00:01:54] T: Me too. Yeah, I actually don’t have a problem with the default sound. But this time, I changed it to like, I don’t know, it’s called magic or something. It’s like – and I was like, even if I’m not always – it’s not always a happy surprise to get a Slack message, at least Slack and make it sound like it is so. But speaking of happy, I guess it’s not really a surprise, happy things in Vue, Oscar. You are very passionate about the Composition API. Is that right?

[00:02:21] OS: Yes, absolutely. When I look at the Composition API, I see a very bright future for Vue, especially when we look at Vue 2. We said to ourselves, how could this get better? This is already such a nice, beautiful way to develop our applications. We can’t even go up from here. But then the Vue team, they really did it to us, bringing out the Composition API, and solving the problems that we didn’t realize were too bad until someone pointed out, “Oh, hey! Actually, you got a lot of boilerplate here,” or “Hey, you’re not reusing this code as much as you could.” As soon as we see that, we’re like, “Oh man, yeah. The Composition API is really where it’s at.” So absolutely, I’m a fan of the Composition API.

[00:03:02] AR: I’m just going to get right into the hard questions here. 

[00:03:07] OS: Absolutely.

[00:03:07] AR: You say, the Composition API provides a bright future. Does that bright future include the options API?

[00:03:15] OS: Absolutely. I feel like this is something that a lot of people always end up asking. They feel like, “Oh! The options API is going to go away,” and the truth is, is like, we’re going to have the options API. In fact, like when you think about the Composition API, in some senses, it’s an extension of the options API. Because we have these new options, we have a setup option, we have these other new options in the options API to setup our components, right? So yeah, I don’t think the options API is going to go anywhere, at least not for quite some time.

I could see some folks trying to get really, really pure with all their components and say, “Oh, you are not ever allowed to use the data option in your life.” It’s like, everything must be composed. If my components are not purely set up functions, I don’t want it. I can see someone going there, but I don’t think that’s what we really want to get out of the Composition API. I think the Composition API is meant to help us use the options API better, allow us to bring in lots of different code reuse. All that business logic that we have had, we maybe were using Mixins for, for example. These are really big options, objects that we’re bringing into all of our components. Instead, we’re taking, extracting it out and then nicely bringing it in piece by piece. I think that’s how we should really be thinking about the Composition API, helping us compose.

[00:04:39] Ar: Best answer that I’ve heard so far, making the options API better. Love it.

[00:04:45] OS: Yeah, absolutely.

[00:04:47] T: Ari, I have an important question for you. Do you think that the Composition API, another Vue thing we talked about a few episodes ago, is another example of someone getting nerds night?

[00:05:01] AR: Ooh! Probably technically have better nerds’ night. I’m just assuming it was a response to Hook if we’re being honest

[00:05:15] T: I think it was originally called Vue Hooks, but I could be wrong.

[00:05:19] Al: I think you’re right. Yeah. Yeah, I think in like some of the original prototypes and stuff it was called Vue Hooks. That sounds correct. I think also it’s one of the – this is another example of like, don’t show Evan cool things because he’ll get distracted pretty easily. I think you’re right about that, for sure.

[00:05:41] T: Yeah, because I remember, Divya and I were prepping for our talks for Vueconf, at Vueconf. Obviously, not only at Vueconf, but maybe it’s not obvious, because sometimes, that’s not the case, but also continuing to prep for in-house at Vueconf. And Divya was going to talk about Hooks. Then as it goes on stage, and announces that it’s no longer Hooks. It’s like the Composition API. Like, “Oh, no.” So yeah, I think it still happens. Yeah. Anyway, why does it mean such great things for the future?

[00:06:14] OS: Yeah. I think overall, there’s the old programming concept that we’ve all come to know and love, dry. Like don’t repeat yourself and, essentially, that’s everything that the Composition API is, it’s, how do we build large scalable applications? Because when you go through like your first Vue tutorial, you put together your little app, and it’s perfect and amazing. Even as you start building out your own apps, and they get more complex, it’s still nice and easy to maintain and manage. It’s not too big.

But as soon as, you know, you’ve had this application that’s been around two, three years, all of a sudden, you’ve got these components that start to grow to be absolutely massive, like huge, ginormous components. Maybe sometimes you are able to extract some of it out into smaller components. But a lot of the times, we find ourselves needing lots of different pieces of data from different little components. That’s where things get tricky, because the question then becomes how do we integrate these things together? Then, we end up using Mixins for that, right?

With the Composition API, we’re taking all these bits of business logic, all these different little bits and we’re just creating these nice, small ways. Also, just as a quick aside, just testing these things, you can take a small little bit of logic, right? You have your one little composable, that’s just simple, does one thing. You can easily test it and so you know, when you’re bringing all these things together, your application as a whole is going to continue to work. When you’re starting to look at it this way of like, “Oh, hey! I can break down my application into small manageable chunks that are easily tested.” Then, yeah, I’m building that large production grade, production scale application. I’m confident it’s actually going to work when I’m deploying it and it’s going to be everywhere. It’s not like, “Oh! I have this 5,000 line Vue file and like I’m pretty sure it’s pretty good because I look at it every day.” Not being in that situation –

[00:08:09] Ar: Next number.

[00:08:09] T: Maybe let’s just tie it to another coworker and ask them, “Does it look good?” Then you can be like double confident.

[00:08:16] OS: Right. Exactly.

[00:08:17] Ar: What if you don’t have another one.

[00:08:21] OS: Oh, no.

[00:08:23] Al: With the Slack thing, is that you save it as mycomponent.vue and then you send it. Then they send it back as mycomponent.vue so you have to save it as mycomponent-2.vue.

[00:08:35] T: No, you save it as theircomponent.vue. Come on.

[00:08:37] Al: Oh, yeah. And then you make modifications and you send it back to them, and then it’s like final and then it’s like, final final. Then it’s like, final final two and then it’s like final final three.

[00:08:48] T: No, final final two for real this time. 

[00:08:51] Al: Yeah, for real this time.

[00:08:52] T: Then you just write [inaudible 00:08:52]

[00:08:52] Ar: Because like why would we have give, though I did have a series of commit messages recently that were, yes, essentially, it works now. No, really, for real. I swear. This is the last one.

[00:09:07] Al: That’s what most of my commit messages look like most of the time, then I’d like squash – I try to figure out how to squash a lot of those so that it doesn’t show up later.

[00:09:15] T: Oh, I rebase them so no one will ever know.

[00:09:18] Ar: I still don’t understand rebasing, so I just don’t.

[00:09:22] T: I don’t either. I didn’t actually, because I feel like you always start the interactive rebase thing and then it just never lets you exit. But one team I was embedded in, somebody told me that they had a rebase flow where everybody does all their changes, and then they squash and rebase so that, if multiple people worked on it, like almost on a single pull request. Like let’s say, Ari made three commits, and I made five commits and then Ari made another two commits. I would squash Ari’s two to be one and then mine to be one, and then Ari’s first five or whatever to be one. So, it’s just one from Ari, one from me, one from, one from Ari so you don’t lose the history, but you also don’t have a lot of extra commits. 

I was like, I don’t know how to use interactive rebase. Someone on the team was like walking through it with me because I tried it several times and it didn’t work. Another team and another company had also wanted me to do the same thing, but they also didn’t know how to rebase. So you’re trying to figure it out, couldn’t figure it out. At the end of the session where we got nowhere, I found out that the team actually doesn’t have a convention of rebasing and I was like, “Why?” But somehow, from that experience, I learned how to rebase okay.

[00:10:30] OS: I think that’s absolutely amazing. Actually, just speaking of rebasing, there’s something that I enjoy so much about rebasing that you’ve suddenly given me a platform to share this with the world. When doing an interactive rebase, there’s all the different little commands you can choose from, like pick every word or whatever. My most commonly used one is fix up. And of course, you can – so fix up essentially squashes this commit into the last one. It discards its commit message. Instead of putting the whole word, you can put just the first letter. I’d laugh every single time I press F for commit and paid my respects to all these commits. You did amazing for me, like yes, and then they all are flushed away, and it’s incredible.

[00:11:18] T: Before we move on, I have quick question, because you’re talking about how Composition API makes Vue more scalable. Scalability is like a big word in the Vue world and the React world. I feel I don’t hear it that much Angular, I think, because it’s always been seen as like the enterprise solution. It sounds like, you don’t mean like Vue 3 makes it easier for you to make like really long boi components. Can you talk a bit more about scalability?

[00:11:49] OS: Yeah, absolutely. Largely, what I mean when I say scalability is the ability for your team to scale in building this application. I’m talking about being able to manage that project, because we’ve all been in these massive projects, where there’s just tons and tons of codes and tons of files. It’s hard, especially like, think about the last time you onboarded a new engineer onto your Vue app, like your peer review 2 app, Like, yeah, they can get the hang of it, but it’s going to take them a little while. They’re going to realize that, “Oh, hey! In this component, we’re doing this data stuff. Over here in this component, we’re doing similar data stuff, but it’s not exactly the same.”

When you’re looking at the Composition API, and you can actually start extracting all of these pieces out, then you realize, like, “Oh, hey! When you have that new engineer onboarding on your team, you say, “Oh hey, yeah This is our composables folder. Any bit of business logic that we have in our application, it exists in this folder, and you can find it. If you need to change anything, if you need to add anything new, it goes right here and they’re all small, little bits. And hey, when you’re building a brand-new component, it’s just about picking and choosing the little bits of information that you need, or the little bits of logic that you need for your component and pulling them in.”

The other huge thing about this is, once we start doing that. our components become largely presentational. It’s largely like, “Hey, actually, these components really about displaying the data. I’m really just bringing in some logic that’s written elsewhere, and I don’t care and we’re just going to display like what this data looks like.”

[00:13:19] Al: What you’re saying is, is that at that point, you’d really probably want to see the template first at the top of the file, right? That’s sort of what you’re saying?

[00:13:25] AR: No, never.

[00:13:26] T: That’s why you’re smiling a demon for the last five minutes. Are you serious?

[00:13:31] AR: I was going to say, it was nice having you but –

[00:13:36] T: It was not nice having you.

[00:13:37] OS: The thing is, I think that’s true. Because it’s like, yeah, when I come into the component, it’s –

[00:13:42] T: No. 

[00:13:43] AR: I’m sure it’s really nice having you here.

[00:13:47] T: Oh, I think this is the record for the shortest episode. Thanks for listening.

[00:13:52] OS: But like, seriously, though, when it comes down to the point where your component is really just a setup function, and you’re saying, “Use this, use that, use this, use that.” I don’t necessarily need to see all of that and really what I care about, like, if I care about those composables, I can go look at those composables. Really, I actually do just want to see the markup. I want to see the markup, like what is this, component displaying? Is it doing any special presentational logic?

Now, that stuff becomes a lot more interesting. Stuff like that, that’s where the options API is still incredibly useful, right? Like if you have some logic that’s specific to presenting some data rather than some particular business logic, right? I think there’s definitely room to see some templates first. It’s going to float people’s boats in different ways.

[00:14:43] T: Yeah, I will say even though I’ve been scratched first for like the last couple of years now. Sorry, time flies. It’s been more than two years. Oh my God! As a primarily like, UI library type developer, that was a really big reason it was hard for me to give up template first, even though the other arguments made sense in terms of the ergonomics for flipping between template and script and template and style.

If I was working with a lot of components were like I needed to see the API of the component right away, it made sense. For me, what I really cared about is looks. I’m a super shallow developer. Okay, maybe not. But like, I like knowing what the thing looks like before I thought about the data, like, they work together for me instead of being completely separate. So, letting go of that was really hard.

[00:15:34] OS: Yeah, I definitely hear that, because like, when I think about these components in general, like if I have all my logic extracted away really nicely, it does sort of beg the question, does the developer reading this code already know what these compostables are giving us? Do we know the shape of the data? Do we know what it looks like? Because yes, reading a template with no context whatsoever, can be somewhat difficult. But if you know what these composables are doing, it can be fun.

But all in all, I think it really comes down to your individual development team. If you’ve got one or two engineers, and they’re like, “I really needed to be this one way,” then it probably will end up being that way. Like, that’s fine, as long as everyone agrees on what’s in your file. Plus, VS code for me remembers the like position I was in most of the files anyway.

[00:16:29] T: That’s like a real problem here. Why can’t VS code just know when I need to look at the template first? Because I’m like, “Okay. What is this component? I’m trying to understand.” Then when I already know what the component is, and I just want to know like the names of the properties expecting and then show me the script tag first.

[00:16:45] OS: TBD on if that’s super-duper possible, but it is open source, like we could go patch the set, if we ever figure out how to know exactly what you want to see.

[00:16:57] Al: To make a feature request for GitHub co-pilot, or whatever it is where it’s able to like predict what you’re wanting to do when you type in a couple of words. It’s just like, “Wow! Okay. Cool. Here you go.”

[00:17:10] OS: Actually, that’d be pretty dope. Because it’s like, “Yeah. Oh, yeah. Clearly, I’m looking at this data, so I swapped to this other file. I want to see that data.

[00:17:18] T: There is an extension, I don’t remember the name that lets you split up the single file component into like multiple windows, so it’s still the same file. But you can look at everything at the same time, which I think sounds pretty neat. Haven’t tried it. 

[00:17:32] OS: Yeah, I’ve seen that.

[00:17:32] AR: I can’t even remember the name?

[00:17:34] T: I saw it on Twitter, try searching Vue extension.

[00:17:43] AR: That should go well.

[00:17:44] T: I think I saw it through Anthony, so I’ll ask him.

[00:17:49] Al: With the Composition API, then, is it better – let’s say that we’ve made all of these composable and you’re wanting to kind of reuse some business logic, do you have a preference as to whether you pull in the composable item? And simply dot-dot-dot everything that comes out of it into the return method? Or do you – would you want to split it out as like, const, curly bracket, thing name, thing name, thing name equals composable?

[00:18:28] OS: That’s a fantastic question. I’ve personally done both and I think there’s pros and cons to both. I think overall, like, yeah, if you’re just given the results of your composables and you’re just flagging them all together. The next thing about that is, if you’re, intimately aware of what these composable are doing and what values they return, then that is really nice. Because when you’re in your template, and you see these particular variable names, you know what that thing is, you know the shape of that data, like you understand what’s going on, right? 

If we get some results of our composable, and we’re doing a little bit of data munging, or whatever, then like, yeah, it can be a little bit harder to follow. But sometimes that does mean that we’re going to have a better experience working within like one particular template, or something like that.

I think it’s going to be largely situational on what you should do. I don’t think you should outright ban one or the other. I think they both have their cases. Of course, another thing too is we’re composing composable like into our mega composable before we bring that into, you know, another component. Essentially, we’re data munging there, and we’re sort of creating new names and whatnot. It might be a little bit hard to realize the dream of – actually, you made me realize something here that actually like, we’re constantly trying to get information out of developers’ heads and into code or into documentation or whatever. It’s probably a bad thing. If I’m reading through a template and I just have all this stuff domain knowledge of these composables and exactly what the types are and whatnot. That could be a bad thing.

[00:20:07] T: As you were talking about composables, consuming composables, I was like, “I’m getting reducer vibes, I’m like getting goosebumps. Like, “Oh! Love that.” But yeah, that’s a great point. That’s something I’m wondering as well, because I think earlier, you were talking about how one of the great things about the Composition API is it makes your code more dry. But I think that was probably one of the initial upsides of Mixins as well. So what do you think Composition API is doing differently or how is it going to avoid turning into the same massive Katamari thing that the Mixins were?

[00:20:52] OS: Don’t even get me started! The thing is, right, is because yeah, when you start building your Vue application, you’re like, “Oh, man! I really have like all this logic, and I want to reuse it in this other component and then you’re introduced to the concept of Mixins. Actually, like this is pretty good. This is way better than any other like frameworks or Mixins that I’ve ever used. Like that’s true, these Mixins are pretty dang good comparatively, but as – and this is always the problem. As your applications grow, that’s where you start seeing the problems come in.

One of the most unfortunate things about Mixins is that they can be reliant on data that’s defined in the consuming component. You may have seen this happen in your applications, maybe not. But a lot of times, like you’ll see someone write in a Mixin, like, this dot some property, that is not all – it’s not created in this Mixin. It’s nowhere to be found, but because it’s a Mixin, when a component consumes that, if your component provides that value, it’s going to work just fine.

Then all of a sudden, you have these mutually recursive field instances and that yields a big problem. The moment you try to refactor that code, it’s an absolute nightmare, I’ve had to do it, it’s bad. Sometimes, you don’t realize you’re doing this, because sometimes, you know, I don’t know if y’all have had this development flow. But you know, maybe something’s not working a little right, you do whatever it takes to make your code work, right? Then you’re like, “Oh! Once it’s all done, we’ll get it cleaned up before you put up the PR.” And like, your cleanup doesn’t end up being as extensive as you want it to be. Like, that’s how these things happen. Where like, yeah, you have the this Mixin that’s reliant on the component that’s going to consume it. 

Anyway, the huge thing with the Composition API is, it’s impossible to do that. You can’t somehow reference a value that you don’t have access to, right? It’s either you’re getting this value from another composable, you’re getting it from the outside world. But there isn’t a way for you to try and rely on something that a component will give you, unless you’re accepting it as a parameter to your composable or something like that.

I think that’s fantastic. Like it helps avoid a whole class of bugs that maybe you weren’t even aware of up until this point of little things like that happening. Another one, too, is looking at like the name spacing issue as well, like the fact that you could have maybe seven, eight components, and I’ll consume this one Mixin and you go to end of the Mixin and you decide, “Oh, I’ll just add this property onto this Mixin, not realizing that one of those eight components that consumes it also uses that property name and it cause a chain reaction of issues. Like, this is just stuff that the Composition API doesn’t allow you to do.

It’s just a much more professional version of trying to reuse information, reuse data, and logic throughout your application. So like, maybe you can hear how I feel about Mixins after having the Composition API.

[00:24:02] T: [Inaudible 00:24:02]

[00:24:04] OS: Yeah, it’s overall that like, yeah, the Composition API just gets rid of a whole host of issues that you have with Mixins. In fact, Mixins were my only complaint in Vue 2. And the fact that like, Vue 3 is like, yeah, I just don’t use those anymore. It’s that’s like a dream come true.

[00:24:20] T: Not having had much experience at all with the Composition API, I’m still a bit skeptical because I remember, a common nightmare of mine was, I don’t remember if you could import Mixins into other Mixins. You’d essentially have a Mixin - that was yes. Okay. Alex is nodding, yeah. A Mixin that was importing like a bunch of other Mixins that we’re importing a bunch of other Mixins. And also, they all had generic names, because you got to keep everything generic, which meant that there were multiple files with the same name, but it’s okay because they’re in a folder. That shows you what the thing is. They all also have like very generic properties. It’s like, “Oh my God! When you’re debugging and like the data is wrong, and you see it in the Vue dev tools and trying to hunt it down. It’s such a nightmare. So when you’re like, oh, yeah, with composable, you can like import other composables. It’s great. And I’m like, “It doesn’t sound great to me.”

[00:25:08] OS: I think, seeing it in action might help you a lot. Because if you think about – way back in the day of like just vanilla.js and like maybe you have like some little tiny file that just like exports one function that does one thing. It’s really a matter of like, when you’re composing – because composables, they’re just functions that return references that are reactive, right? Are functions that can give computed or whatever, right? Essentially, you’re just calling these functions, getting some values and creating a new function that’s essentially re-exporting these values. However, you don’t get into any of the name spacing issues, right? Like you’re not going to get into that, “Oh! All of a sudden, I’ve got these composables with the same name.”

Of course, you could do that, but there isn’t a real reason to because the idea is, when you compose two things, you get something new, right? Because like, let’s say we wanted to have a view component that, you know, made peanut butter and jelly sandwiches, right? We might have a composable that’s like uses peanut butter and another composable use jelly. And like, maybe we want that PB&J composable. Right? The PB&J composable is like, I’m going to use peanut butter, I’m going to use jelly. I’m going to export use PB&J, right? Since they’re composing and building off of each other, that’s where it’s like, you see your application sort of rising from all of these little pieces. I think that’s where the beauty of the Composition API comes in.

It keeps you from shooting yourself in the foot the same way you would with Mixins. Especially like, yeah, I never want to see anyone ever, ever bringing Mixins into Mixins. Like, just please, like don’t ever do that. Like the fact that the Composition API said, “No, we’re going to import regular old functions, regular references and do what we got to do with them. It’s like leaning on JavaScript a lot more. Like when you look at like React hooks, and like the Composition API, really what they’re doing is they’re just leaning on the vanilla.js far more.

It’s like, yeah, let’s write plain functions, right? Let’s use plain objects. Like, let’s not make everything super-duper complex. And that’s how you see this leveraging off faster as well. Like when you say, “Oh, yeah. Why can Vue update this property on the page 10,000 times in a second?” “Well, yeah, because it’s just a regular old plain JavaScript function.” There’s nothing special about it, right. So yeah, I think overall, it’s – don’t be too scared of the Composition. It was definitely designed with composition in mind. It was designed for you to have your composables consuming composables and not blowing up the world, and being fairly easy to follow as well.

[00:27:50] Al: Yeah, in a previous job, I had a code base where we were using Mixins and the pattern that we got into to try and like add some, like safety to it, so that you’d have to like know what was going on, is that we would do things where I was like, “Okay, cool.” Mixin is going to refer to a property that you’ve already defined on your component. But you have to provide the name of that property, right? So, we were doing functions that would make objects, that would have functions, that would reference a property on a thing. It was just like, lots of weird –

[00:28:24] T: [Inaudible 00:28:24]

[00:28:27] Al: Yeah, it was weird scoping issues that we were getting into when you didn’t do it right.

[00:28:33] T: Yeah. I just never tried to Mixin data with component data. I was like, it’s only going to be for generic functionality as much as possible. Otherwise, I’m going to find – I’m just going to do good old copy and paste like Dan [inaudible 0:28:46].

[00:28:51] OS: I think like when I think about it, I don’t know, we just want to keep composing stuff. Like, the huge thing about like Composition, is just keeps you from shooting yourself in the foot. It’s like, “Hey! We want to allow you to do everything that you were doing with Mixins, but in like a sane, thought through way.” Because it’s like, yeah, as you’re saying, teams have had to come up with their own concepts and ideas of how to not shoot themselves in the foot. Ultimately, you end up doing it anyway. Right? And so yeah, it’s just like, it’s kind of just like Vue all grown up. That’s really what it is.

[00:29:23] T: Yeah. This is bringing up a question that I’ve had, which is, what do you think is – and of course, we’re generalizing here – easier to teach to a beginner developer, Options API or Composition API?

[00:29:40] OS: Options API every single time. Right? I think that that goes into sort of what Ari and I were chatting about earlier, is that yeah, options API isn’t going away. It’s not going away. I think that’s the beautiful start to anyone’s Vue journey. Is like, yeah, learn how to make a basic little view component and then, when you get to the point that you’re like, “Oh, hey! I want to reuse this logic. It’s not too difficult to pull logic out into a composable. It’s actually pretty darn simple.

I think, going through that process, as a developer that’s new to Vue is going to help you understand like, the purpose of composable. Like, why do we have them in the first place? I think, the same way that if I were teaching someone React, I don’t want to teach him Hooks right away. You’re going to scare the poor developer.

[00:30:31] T: You’re not going to make him like a class component, are you?

[00:30:35] OS: No, but like simple functional components, right? Like, we can do like some nice, easy stuff first and then we can start building on these other concepts, you know? And yeah, I think that’s exactly what it should be for Vue is like, yeah, teach Options API first, and then show like, “Okay. Now that you understand this, you understand how Vue works. Let’s start getting into composables.” Because to be fair, is much as I’m saying composables are amazing. There are some slight caveats that you have to understand.

You have to understand reactivity in view quite a bit better than you did than Mixins, right? Because it’s just like, “Oh hey, you can make composable and mess it up, where you’ve got this value that’s not reactive, and Vue is not responding to changes in that value.” That’s like, “Okay. You have to understand that, “Oh! I need to create a ref for this. Oh! I need to create like some new computed value for this.” That’s not going to be clear to someone who’s brand new to Vue. 

I think teaching that Options API first, letting them understand how view approaches reactivity in general, and then start saying like, “All right. Now, we’ve got this reactivity API, and it does all the stuff or whatever,” is I think the way to play it. So yeah, I guess, you know, none of us did talk through the learning curve for the Composition API, but there is one it does exist.

[00:31:52] T: Yeah. I was going to say, I haven’t tackled it yet, so there’s nothing to talk about.

[00:31:58] Al: I think it’s similar, though, in a sense to like if you’re teaching somebody Vue, you’re not going to be like, “All right, let’s start off with Mixins.” Right? Like it’s that same thing. Like you’re going to be like, first, you need to learn how to write a Vue component, and what Vue is and what we’re doing with Vue and see how it works. Then, you know, the Composition API is like, “All right. So you want to make a framework on top of Vue, great” –

[00:32:25] T: My impression is, and it’s funny actually, because I feel like some of the people that I saw most excited for Composition API are maybe like newer to Vue, but very into React’s developers, who don’t really understand reactivity. But they’re like, “Oh, yeah! This makes more sense. I feel like, especially in the context of, we were talking to somebody who was relearning Vue again for the first time, a couple of weeks ago. I feel like they have, at least at the surface level, kind of different audiences where the Options API is maybe for somebody who like, understands, like JavaScript data structures and stuff.

Then they’re like, “Okay. Here’s how the thing works. You don’t use this in the template and the data is like, where all the stuff comes from. As long as you accept that stuff, it’s okay.” If you’re the type of person that maybe has, at top of mind, in working memory all the time, how contacts work, how this works, then maybe you’re going to be annoyed all the time at all of the magic that Vue is doing. Because you can’t just accept that that’s the thing, and then be like, “Okay. Now, that I’ve accepted the rules, it’s very simple.”

Then with the Options API, I feel like it still has a lot of Vue-specific rules and things that you have to learn. But for the type of person that is always thinking like, “Oh! I want to really be doing just pure JavaScript stuff.” It’s a lot more comforting from that angle. I could be wrong. But that’s been my impression of general opinions on the two of them.

[00:33:56] OS: Yeah. I mean, I think you’re pretty much right. Like yeah, I would describe the Options API as cozy. It’s really cozy.

[00:34:05] T: That’s a great word for it.

[00:34:06] OS: Like if you know you some JavaScript, like if you’re just like, “Ah, yeah, I’m JavaScripter over here. I know what I’m doing.” You come to Vue for the very first time, and you see the Options API, you’re like, “I know how to write an object. I got this,” Right? Like, I’m about to kill this whole app. I’m going to end this company’s whole career. That’s how you’re feeling with the Options API. Right?

That’s – but yeah. I mean, I see like, if you’re this crazy React Hooks person, you’re going to be like, “Something’s wrong. I need to define lots of little functions. If I’m not calling something that doesn’t have the word ‘use’ in it. Something’s messed up. Like I definitely see that, but yeah, like options API is super-duper cozy. I think yeah, it’s like, we should start with the cozy stuff. Then when we need something that’s a little less cozy, but you know, keeps us in check, yeah, we can start reaching for Composition API.

[00:35:14] T: I love that description. Because it’s true, I don’t always feel this way. But once I get into the flow of making a UI element with the options API, I do feel legit cozy.

[00:35:23] OS: Yeah, it’s like all like nice and contained. When I write a nice little computed, I’m like, “Oh, yeah. Look at this computed.” It does the caching for me. Like it’s cozy. It’s nice, right? I think it’s good. Not telling Vue what to compare for multiple renders. I’m not doing that. I’m not throwing shade at these effects for anyone who’s wondering.

[00:35:54] T: So when would you use the options API and when would you be like, “Okay. This is where I need to pull in the Composition API?”

[00:36:03] OS: The moment your brain says, “Oh! I want a Mixin,” that’s when you should go use the Composition API. Yeah, it’s literally anytime that you say – because like, yeah, doing composition just for the heck of it isn’t really going to get you anything. Like, well, I mean, maybe you can. Like if you really want all of your component’s logic to like, just be in like one function, you can make that happen with the Composition API. If that’s your coding style, that’s really nice. But other than that, you’re not going to get a huge benefit. The huge benefit of the Composition API is being able to share that logic. It is like, you know, quite seriously, when you’re like, “I’ve got these multiple components, maybe similar views,” but like, maybe let’s say you’ve got like two different sides of your app. But you’ve got this data and like the logic is the same. It’s like, “Yeah, let’s reuse that. Let’s pull that out into composable.”

Then, it feels nice, because then your component when you’re like, like if you have a weather app or something. Like you’re just saying like, “Oh, yeah. You use forecast.” Like, yeah, like, that’s easy. It’s like, I didn’t have to go do – write some fetch. I don’t got to go, like hit Axios or something. I’m just like, “Oh, yeah. You use the forecast and now I have forecast data and I’m a happy boy.” Like that’s what I am, right? And that’s how we should be thinking about these things is like, I want to use this in more than one place. Let’s make a composable. And like –

[00:37:26] AR: Do you think there’s one other use case though, for when you don’t ever intend on reusing it, is when you have that one component, that sort of like, that central feature point of your app, and you just keep adding features and adding features. Suddenly, like, you can’t find anything in it because you tried to somehow keep features grouped together, but you know, across options, like that just stopped being an option. Are you proud Tessa?

[00:38:01] T: I’m really enjoying how much you’re enjoying your joke.

[00:38:06] AR: Hey, someone’s got to laugh. If that’s me, whatever. Because like, I’ve definitely had like the 1,600-line component, because features kept getting added on top of it. It would have been really nice if I could have broken those out a bit so that each part that was pertaining to that one feature was its own thing. 

[00:38:28] OS: Oh, yeah, definitely. I think that is a good example of not thinking about it in terms of reuse. It’s just like, “I just want to break this thing up.” Yeah, that’s a really good point. It’s fantastic for that. Like, if you can have these different, you know, logical concerns of like, maybe features like, “Hey! We’ve got three features in this dang component. That’s already too many for us, so let’s go ahead and refactor these three features into their own composables.” And then, you know, we can actually just say, “Oh, use feature one. Use feature two. Use feature three.” Then, when we have to come in and add more, we can just do those. I absolutely love that. I love how you’re thinking about it. This is prime example of how should you think about using the Composition API? Yes. Exactly.

[00:39:10] T: There’s some kind of like bug or crab. I don’t remember which, that like its primary defense mechanism, is it just keeps on collecting garbage and piling it on top of its own body until it becomes bigger and bigger because it collects more and more garbage. And yeah, Ari’s example before Composition API.

[00:39:35] AR: In this analogy, are we trying to keep people out of our components?

[00:39:41] T: I mean, yeah, when I see a long component, the first thing I do is close it out and then I’ll go back in after I take a walk or something.

[00:39:53] Al: I was going to say when you’re – I would imagine also when you’re wanting to do Composition APIs, when you reach that point, when you’re ready to start doing stuff in Composition API, that you don’t have to necessarily be like, “All right, let me go spin up another file, and go make a whole another thing,” you can actually just like do it right there, in your component file. Like you could just break all the logic out and be like, “Okay, really, these parts are here, and these parts are here, and these parts are here.” So you make three separate functions, and then put them all inside of a component. 

[00:40:24] T: Okay. But Alex, some people feel really, really strongly about having every tiny piece in its own file and its own folder.

[00:40:32] OS: Those people should take a walk.

[00:40:37] AR: Put it in the folder with an index, thanks.

[00:40:40] T: Yeah. That’s a blast. I mean, that’s just a very normal paradigm in Vue, Ari.

[00:40:47] AR: Our back end does that a lot?

[00:40:49] T: No. Wait, not with the Vue’s thing?

[00:40:52] AR: No, no, but literally everything is in its own file, and then that folder has an index where everything is imported, and then exported. It’s like, why?

[00:41:06] T: Yeah. But that does bring up another question that I feel like people might have. Because you feel like a lot of times you are going to use the compensation API and like his own file, right? So why should I go through the trouble of like learning how to use it and all this special syntax and stuff instead of just like making a JavaScript module?

[00:41:28] Ar: And to be cool, obviously.

[00:41:29] T: [Inaudible 00:41:29] thing about me.

[00:41:34] AR: I have actually.

[00:41:34] OS: Yeah, that’s a really good question. And the answer that I’ll give you is that regular JavaScript modules only get you so far because, fundamentally, what these regular JavaScript modules are missing is the reactivity. What the Composition API is letting us do is compose things that are reactive, that we want Vue to react to.

You can extract regular helper functions out as much as you want, and like, that’s cool, I guess. But Vues is not going to react to that. You can then take it and use it in a Vue computed method or just a regular Vue method and, just by virtue of using it somewhere, where the other things are already reactive, will make the results of that thing reactive. But your little helper function is not going to be reactive. That’s the huge kicker is that it’s not reactive. The moment when you say, “Oh! Well, I’ll just take my little JavaScript module, and I’ll use the reactivity API and I’ll export functions where the things are reactive.” Well, you just made a composable. Right? That’s exactly what happened, right?

If that helps you think about it a little better is like, “Hey, yeah! I’m extracting out these functions to their own files to just make my codebase cleaner and I’m going to sprinkle a little bit of reactivity API on top.” Then yeah, that’s not a terrible way of thinking about it. But yeah, it’s largely that, you know, regular plain JavaScript modules just don’t have the reactivity. That’s what Vues is all about. That’s what our app is all about and we need that reactivity.

[00:43:12] T: Is there any reason that like somebody making like their own small hobby app would be likely to use – need to use the Composition API, as opposed to just like using it to try it out?

[00:43:23] OS: Honestly, not really. Like that’s the thing. Like if you’re just making like a little hobby app, and it’s just you, you’re the only dev and you have all the knowledge of how everything works, you totally can just go straight to your options API and be happy. How to use Composition API for some things in the future where you would be very happy. There’s going to be that day, you come back to the project, and you’re like, “Oh! I have a 3,000 line Vue component and I don’t know what’s going on.”

It’s good if we can afford that. It’s like, you don’t have to, but you know, a lot of what we’re doing with the Composition API is not copying and pasting code. Allowing others on our team to reuse code that we’ve already written. If it’s just you, if you wouldn’t be a good teammate for yourself, you know, you’ll take a little bit of the effort to you know, do a little bit of composition. But if you also just like clean code basis, like it’s a –

[00:44:17] AR: No, I like it messy and I like it to be all my fault and I like to punish future me. That is how I’ve been living.

[00:44:26] T: What’s like the longest component, Vue components specifically that everyone has worked on?

[00:44:32] OS: I feel like something like 6,000 lines. 

[00:44:36] T: 6,000?

[00:44:38] OS: Components can get thicc, all right. And I think it’s fine and like, “Yeah.” Like it happens and like it fine. But like, we got to stop.

[00:44:53] T: Yeah. I feel like mine was like the 4,500-line range.

[00:44:53] OS: Yeah.

[00:45:01] Al: See, I always –

[00:45:02] Ar: Honestly, say 2,500 was my worst.

[00:45:06] Al: I feel like when I reach a certain point, I go, “Okay. No, this is too big” and I break it down into smaller pieces, I can’t. And I feel like that line is depending on what I’m doing is like a thousand lines or something like that, like I have a really low tolerance for –

[00:45:21] OS: I definitely hear you. But I have this concept with components, too thicc to quit. You got to just keep going. It’s like, we’ve already come this far. All right. Like, is today the day we’re refactoring this? Absolutely not, we’re going to add this feature. We’re going to keep moving.

[00:45:43] T: I think also, you reaching that breaking point doesn’t mean somebody else reached that breaking point, right? Like, am I going to leave a 4,500-line file, 4,500 lines? Maybe not, but I started there.

[00:45:59] Al: All right. So, I got a spicy one. I got a spicy question. We’re talking about Composition API and a big part of the Composition API is the fact that it’s, you have a setup function. Have you done Composition API and sprinkled in some JSX in there at all?

[00:46:16] OS: I personally have not. In like my lifetime of using JSX with Vue, I did it one time. And you know, it’s fine. Like, yeah, I don’t have a ton of experience with JSX in Vue. But if you have happy stories, or horror stories, I’d definitely love to hear.

[00:46:39] T: Also, as a pleb, love to hear the explanation for why exactly this question is so spicy?

[00:46:44] Al: Well, because I know that some people here have some very strong feelings about JSX. But maybe. No, I’ve been playing with it. I realized that you can, if you use define component to define a component, because in Vue 3, you can bring in a method. It’s called define component. You can pass it an object and define your component in there and it’s very helpful for TypeScript because it does all the correct typing for you. But you can also pass it a function and write a composable inside of it, and return a function that returns JSX.

That is your render function and have it all self-contained within one function that is wrapped in a define component. That will render correctly. In playing with it, I’m like, I show that to people who come from React world, like the React land of things. I’m like, “Oh! Well, you can write Vue like this," and they all go, “Really? That’s so interesting.”

[00:47:50] T: Why don’t they just keep using React at that point? Like I don’t get it. I also really appreciate our east face that she’s making, because I feel like Ari’s approach is like, “Let’s take the trash off the bug,” and Alex was just like, “No.”

[00:48:04] Al: How terrible can I make this look before it really upsets people?

[00:48:09] T: That’s like the dumpster coming to light. 

[00:48:11] AR: This reminds me of like, so I feel like there are two types of tidy people in the world. There’s the type of tidy person that needs everything to be organized and there’s the type of tidy person who just doesn’t want to see clutter. I feel like what you’re describing is just shoving clutter into a closet.

[00:48:35] AI: It’s like you know me or something.

[00:48:38] T: I thought it would be more like the type of person that has like a cup on their desk. And on top of the cup is a book and on top of the book is like their mouse and their pen holder and all this stuff. And like it looks messy, but you can’t move any of it because they know where everything is. And once you move a pen, they’re like, “Where is literally anything? Where are my glasses?” and you’re like they’re on your face, Alex, and he’s like, “What?”

[00:49:00] AR: Yeah. This comes from the fact that I am not a tidy person, but my husband is, but I know where everything is in my mess. But he just likes to not see mess, so I can never find anything now. So, it just sounds like you’re one of those people who likes to hide things from me.

[00:49:18] Al: Oh, no. No, no, no, no, no, it’s all out there in the open. And that’s why it’s beautiful.

[00:49:25] T: Now, now I’m getting hives.

[00:49:28] Al: You put all of your logic and you’re rendering all in one function and just put it right there. It’s all there. You’re good to go.

[00:49:34] AR: You wrapped it in another function.

[00:49:36] Al: Yeah.

 

[00:49:38] OS: Yeah, it’s like you definitely can, like it’s definitely a thing that you can do. Like the thing is, I feel like for like just render functions in Vue in general, I think they have their purpose in libraries. Libraries are when you’re trying to do something that’s like very complex to do in a normal Vue template. Like I have this Vue library called Vue Oxford. It’s a library where you get a Vue component called Oxford and give it some children. It will render them as a list and it will place in Oxford comma at the appropriate place. That’s what you know, this library does.

I implemented it using a render function because doing in template logic of like how many items do you have, and like you can do it like you could straight up just write like four cases, right? Then I was like, actually, it’s kind of simpler as a render function, which is why I did it like that. But yeah, it’s like, I just never want to see anyone write a render function in my app. I just don’t want to see you do it. Like, please, don’t. It’s like we work so hard to understand Vue and like, “Okay, template data.” That’s what – like we’re not trying to mix them right now, just template and data. I understand the want to do it, like I was a React developer before, I was a few developers. And like, when I first came into Vue, I was like, Vue is the lamest thing I’ve ever heard of, are you kidding me? I got it. What year is it? I got to run a template. Are you kidding me?

That’s definitely what my feeling was. But after using Vue for a little bit, I realized that I actually, you know, what this does, it makes me not make mistakes. I got a simple template, and I got some data. So, I think overall, like I would, instead of having a composable that returns a render function, I would rather just see a low, low component that’s a template that consumes one tiny consumable. Just because I feel like you know, my team is going to understand that more like people are going to see it and understand what’s going on. I’m just imagining, like, you know, going to like my team, and putting up that PR that sets up for Vue and being like, “All right, everybody, we’re going to start writing some JSS.

[00:51:59] Al: It’s already there. 

[Crosstalk 00:52:00]

[00:52:02] OS: It’s there by default. I’ve been writing H like an idiot this whole time it’s been set up already. 

[00:52:09] Al: believe so. I believe it is a default, but like, you can just start writing JSX and will work.

[00:52:13] OS: Absolutely bonkers. I’ve been writing H all these years.

[00:52:20] T: What the H? I’m guessing it’s work that made you switch to Vue, huh?

[00:52:25] OS: Oh, yeah. I mean, it was that and like, Vue was some new hotness. I was definitely willing to give it a try. And like, yeah, I think – so I have lots of thoughts and feelings on like the whole React versus Vue debate, like, obviously, they’re both great frameworks. But I think having gotten to use both for so long, I really understand that, like, React appeals to that like inner nerd in you. Where you’re just like, “Oh This is so technical and so interesting, and like, ugh, thinking in React.” But it’s okay, I was like –

[00:52:57] AR: I have no opinions about that.

[00:53:00] OS: Yeah. And like there’s that and like the sort of like the in factor, like I know how to think in React and they know. Like there’s sort of that versus like, Vue really appeals to the, I’m really trying to get my job done. Okay, like, my product manager just came to me and was like, “Yo! We need this feature and we told the customer they’d have it last week.” Vue allows me to get that done and Vue is not trying to like make me feel good about myself when I write with Vue. It’s just trying to let me do it.

I think that React – React does make me feel good about myself. Because like, when you get like your hooks all working right and like it’s optimized and everything, you’re just like, “Oh, I’m not making too many closures during this render," like, you get like really excited because it makes you feel smart. But like, at the end of the day, it’s like, we don’t care about that. Actually, I need to ship features. I think that’s like the huge difference for me.

Not that you can’t ship features fast in react, but you got to think about just code. Like you don’t have to think about the code that much. You have to think about what you’re trying to deliver and I think that’s sort of like the shift for me.

[00:54:12] T: It sounds like we might have to have you on for another episode, so Ari can [inaudible 00:54:17] her thoughts.

[00:54:22] AR: This is actually going to be by far the spiciest thing I have ever said in the almost two years of doing this show.

[00:54:28] T: There’s just competition there.

[00:54:30] AR: I know. Someone once asked me what I thought the difference was in, let’s just say toxicity level between React and Vue communities. I firmly believe that it boils down to, React is all about being clever and the types of people who value being clever are not the type of people that work well with others. Vue is about getting things done, as you said. That is why I think, until now, the Vue community has been a little less toxic. However, I personally feel that with the introduction of the Composition API, there has been a shift in the Vue community, and I’m honestly not happy about it.

[00:55:12] OS: Hard takes in this corner. I wish I had a bell that I could ring

.

[00:55:17] Ar: Ding ding. Sorry, I’ve been holding that in for a really long time.

[00:55:24] OS: Yeah, no, like, can we talk about that? 

[00:55:27] Ar: On the next episode.

[00:55:29] T: Yeah, we’re going to have to do another one.

[00:55:31] OS: All right. We’ll hold that one. We’ll hold that one. I have so many thoughts and feelings.

[00:55:37] T: Oh, yeah. I mean, speaking of thoughts and feelings, I’ve been reading a lot of AITA lately, and I read one where this woman bought her first house, but it was near her hometown where her parents still live. She has to commute to the city, so she’s like, “I’ll work in the city and stay with a friend three days a week, and then I’ll stay in my home two days a week and the weekend. Perfect.”

She wanted to take her time on packing everything, buying furniture, making sure everything is set up exactly the way she wants. Her lovely, generous, kind parents, as a favor, took her spare key and let themselves into the house, bought her furniture in like a very ornate antique style, unpacked all of her things and put them away on their own. Then, the things that they felt like didn’t go anywhere, they repacked into other boxes. Your tidy story reminded me of that, and I was getting really stressed.

Okay. Last question. What are some, like big gotchas that people new to the Composition API should watch out for and like, what is something really satisfying that you did with the Composition API?

[00:56:58] OS: Hmm. Yeah, I mean, I think overall, like the biggest gotcha, by far the biggest gotcha with the Composition API is not understanding Vue's reactivity. That’s going to be the biggest gotcha that you can possibly run into. I highly recommend, instead of just trying to wing it, just go look at a tutorial. I think it’s just going to really help wrap your mind around how Vue thinks about reactivity, and how you’re composables need to return reactive values and making sure that you’re returning reactive values. I think that’s going to be a huge thing. 

I think there’s like some smaller gotchas, where sometimes you’re going to have an object that you think all the properties are reactive, [inaudible 00:57:38] de-structure it and then it’s not reactive anymore. Then it’s like, “Oh! I got it. He used two refs on this thing.” That’s definitely going to be like a gotcha. But I think, as you understand the reactivity API a little bit better, you know, it’s not going to trip you up at all. But yeah, I say, go do a tutorial, you’ll be much happier doing a tutorial than just trying to just wing it, for sure.

[00:58:01] T: Nice.

[00:58:02] OS: Coolest thing I’ve done with the Composition API, I don’t think I’m that cool. I mean, like the –

[00:58:10] Ar: I just think –

[00:58:13] OS: I think like with underlying stuff, like if we’re just talking about like the reactivity API, like the coolest thing I’ve done in the history of my life was I use a Vue to write a backend, using the reactivity API, which basically, you had –

[00:58:26] Ar: A link to that talk will be in the show notes.

[00:58:31] OS: Yeah, absolutely. Because I thought that was the coolest thing. Like just like having a reactive database, where as you hit your database, making changes, Vue’s reactivity system could trigger effects, and go off and like do things like hey, AWS, Lambda, send tweets, like you can do so many interesting things because of user activity system. In terms of like, composable, I don’t know, it would make my app cleaner. Like the major thing that I’ve gotten to do with composables.

[00:59:02] Al: It’s not about reducing the amount of clutter. It’s about putting it into nice piles everywhere so that you can find it easier.

[00:59:11] OS: Yeah, nice little pots of clutter.

[00:59:14] T: I wish we had time to talk about – I can’t think of the word, but like the faction, let’s say for lack of a better word of people pushing for like replacing Vue X with a Composition API. But that’s all the time we have for this week’s episode. So Oscar, if people want to ask you on their own, where can they find you on the internet?

[00:59:35] OS: Yeah, absolutely. Hit me up on Twitter. I’m @oscar_spen. Pretty easy to find me there. On GitHub, Oh, Spencer. I just open a random [inaudible 00:59:46], I guess. They won’t probably see it. Those are going to be the best place that you can find me.

[00:59:55] T: Nice. Yeah. That calls to mind, Eduardo, who I think GitHub is also the best channel if I remember correctly. Yeah. Okay. So now, it’s time to move on to this week’s picks. Ari, would you like to go first?

[01:00:10] Ar: Sure. My pick this week is a Hulu original show, Only Murders in The Building. Incredible cast, just off the bat, Martin Schwartz, Steve Martin, Selena Gomez, Sting.

[01:00:23] T: Not everyone’s named Martin. That’s a little disappointing. 

[01:00:25] Ar: I know, right? Yeah. Sting even has an amazing cameo in it as himself. He plays a not very likable version of himself no less. There’s definitely ‘don’t stand so close’ jokes in there. But yeah, just well written funny. I’m a huge Steve Martin fan, though. So if you don’t like his style of comedy, you’re probably going to hate it. We should never talk in real life, just FYI. That’s my pick.

[01:00:55] T: What about on the podcast. I’m kidding. I don’t have any strong opinions either way.

01:01:00] Ar: Wow! Really, Tessa? It was really nice having you.

[01:01:04] T: I know he’s a prolific writer and I also have not read any of his books yet. Okay. How about you Alex? It looks like everybody has like murder or something.

[01:01:16] Al: So the pic I have this week is a game called The Artful Escape. It is the story of –it’s not fantastic, but the art in it is amazing. 

[01:01:28] Ar: Artful?

[01:01:29] T: That would be pretty embarrassing if it’s bad.

[01:01:36] Al: It’s about a young man who is trying to live up to his uncle’s reputation of being a famous folk singer, white guy, surprisingly. He wants to be a psychedelic guitar rockstar. It’s him going on an interstellar adventure trying to find himself. So, yeah, it’s not the best story but the art in it is really good.

[01:01:58] T: Is it a board game of – I just realized I assume because if your pick is a board game, it doesn’t sound like one.

[01:01:58] Al: No, it’s a video game. It is it is a video game.

[01:02:07] T: Nice. Oh, and also listeners, you should all be very proud, Alex picked this one all by himself.

[01:02:13] Al: I did. My wife did not help me at all with this one.

[01:02:17] T: Okay, and Oscar. What are your picks for the week?

[01:02:21] OS: Yeah. My pick is going to be this game that’s relatively new called Dyson Sphere Program. And so, for those of you out there who are big fans of Factorio, it’s a complete rip of Factorio. I’m not going to lie. It’s a complete rip of Factorio. But basically, with stellar, amazing graphics. That whole thing about planets, a lot of people complain like, “Ah! Well, when I beat Factorio and I leave the planet. I don’t go anywhere.” The Dyson Sphere Program, it’s all about planets. You basically create factories on different planets and it’s super-duper cool. It is a complete rip of Factorio. Sorry, I’m not going to say that it’s not. But I think everyone should play it because it’s got gorgeous graphics. Nothing like doing stuff that’s similar to your day job when you’re not working.

[01:03:09] T: Yeah, like when Ben talked to me about it. Oh my God. I was like, “That sounds like work. No, thank you.” So that’s it. Yeah, and this is my first time realizing it’s a game. When I first saw people mentioned it on Twitter, I was like, “Oh! Must be like your new vacuum or something. Like they have that orb one and like they have [inaudible 01:03:26]. Then when they were talking about a bit more, I was like, “Okay, I guess Dyson is also getting into space program.” That’s why I have no clue at all until today.

[01:03:36] OS: That’s awesome.

[01:03:38] T: Yeah. I guess that just leaves my picks. I said I would pick The Great Ace Attorney Chronicles until I started playing it. I started playing it. I only played through like the intro thing where the character goes to court and then I didn’t play any of the court cases, but I started, so very proud of myself. That was Alex golf clapping. Well, listeners, you will also know that I’ve been having a lot of trouble with like little flying demons this summer. So, I’ve tried a lot of different things. I’ve also learned speaking of two types of tidiness. There are people that will be okay with a flytrap even though it’s hideous because you’re addressing the problem, and then people who would rather just live with the problem, so you don’t have to look at a flytrap. I’m definitely not the later.

Other flytrap, I’ve seen and tried. I just opened this one. It seems to be okay so far is the Terro Fly Magnet Super Fly Roll, it’s just a long strip. It does the same thing with the like fake flies on it. I don’t know why they all do that. But it has a giant hot pink strip in the middle, so I think that distracts me from being like, “Oh, there’s fly pictures on there.” And it’s like not sticky at all sides, so I don’t have to worry about it getting stuck on my wall or anything like that. That’s great.

Then, this is not at all related to the flies. I was just thinking about this audiobook I listened to a few years ago called Tiny Beautiful Things, which again, flies are not – it’s a compilation of advice, letters and replies from Cheryl Strayed of wild fame when she was working as an advice columnist called Sugar. It’s just like a very – it’s a very cozy book. Like it’s just very gentle and comforting. So, if you want to read something like that, then maybe check this out and the audiobook has like a very soothing narrator. I think it’s Sheryl herself. 

Yeah, and that’s all for this week’s episode. If you aren’t following us on Twitter, you probably know by now where to find us @enjoythevuecast. So go there and hit the follow button. If I’m remembering correctly, if the button is black, that means you’re not following us, so hit it. And if it’s white, it means you are following us. Unless you’re in dark mode.

[01:05:42] Al: It’s the other way around. Oh, yeah.

[01:05:44] T: Well, if it’s filled in, right, then you’re not following us. So, if there’s a fill color. If there’s no fill color, you’re good. Don’t hit the button or hit it twice. Either way. This is getting too complicated. Also, subscribe to us if you’re not already on your pod catcher of choice. And if you have time, and you like us, leave a good reviewer. And finally, share at least one thing you enjoyed about the show either on Twitter to your followers to Gloomy Loomy or to your friends and colleagues in real life. Thanks for listening and until next time, enjoy the Vue.

[END]