RFC the Vue: Script Setup with Lachlan Miller (RFCs 227 & 228)

EPISODE 65

[EPISODE]

[00:00:09] A: Hey everybody, and welcome to Enjoy the Vue. I'm Alex. Today, on our panel we have Tessa.

[00:00:16] T: Hi.

[00:00:17] A: And Ben.

[00:00:19] B: Hello, hello.

[00:00:21] A: And our special guest for this episode is Lachlan Miller. And this week, we'll be talking about script setup. Lachlan, what is this script setup thing that I've been hearing about?

[00:00:34] LM: Sure. So, there's two RFCs in the Vue.js RFCs repository. I'm looking at them right now. They're number 227 and 228, if anyone wants to go and check them out. But basically, one of the feedbacks that the team got with the competition API is there's a little too much boilerplate. You have to create the setup function and you have to return all the values from setup function that you would like to be exposing in your template. I think, for that reason, Evan put some thought into how we can reduce the boilerplate and sort of improve the developer experience, always trying to incrementally improve Vue.

There's two RFCs. The first is you can add a setup attribute to your script tag and it basically allows you to write your kind of composition components without using the setup and returning the variables. So, you can imagine if you have a regular competition API component with setup, you just remove the setup and the return, and you write everything in that script block and any variable you declare inside of the script tag will be made immediately available in the template. So, nothing really changes about how Vue works, or anything you've learned is still applicable. It's just a slightly more ergonomic way of authoring components.

There's another RFC, which is a little bit more creative, it kind of strays off the path a little bit to make the boilerplate even more reduced. But I think we can talk about the first kind of main RFC, which is the newsgroup set up one a little bit first.

[00:02:05] A: Yeah.

[00:02:09] B: And so, to give our listeners like a mental image, because might not be looking at a computer screen. Again, if you're thinking of your block, you have your script, and instead of your normal, like export default object and then you have setup inside, it's literally just a script block. And then you have like space, that setup, as long as that's just an attribute, an extra attribute we throw on there and that's it. And then everything else inside of scripts now acts as javas, like the setup function.

[00:02:33] LM: Right. And you can go ahead and import anything you normally would import from node modules, or whatever, and use the reactivity API in exactly the same way you declare reps and reactive. Any variable you declare will be available in the template automatically, whether you like it or not, which is not really a big deal. If you don't want to use it, just don't access it in the template. The idea is just to reduce the boilerplate, because you're constantly writing export default, you're constantly writing return, and there's not a ton of value in constantly writing the same thing over and over again.

Yeah, I'm pretty interested in RFC. I personally think it's great. I don't have to learn anything new to use it. I just have to write slightly less code. So, definitely a win in my books.

[00:03:18] B: I think what's tricky, though, is that in the traditional composition API, as Lachlan mentioned, you have to explicitly return what you want to expose to the component. Right? So, in this setup, I guess we're to assume that there's some sort of IntelliSense from letting the what is in what's not being exposed? Because if I write a bunch of stuff, and I'm only trying to expose one variable, for example, that would slow down performance, or whatever, I think that might be.

[00:03:47] LM: I mean, internally, whatever is returned is kind of put in this context variable, and that's injected into the templates. If you actually look at the RFC, Evan actually outlines the exact transformation that takes place. Basically, every variable you declare is just inserted into a return statement and that entire thing is inserted into a setup function. So, it kind of constructs the composition API setup function for you, just saves you writing a little bit of code. As you mentioned, all the variables are now available on the template. I don't see any real downside to this. I mean, performance is obviously something you need to think about. But I'm guessing that Evan would have thought about these things and sort of benchmarked them before just throwing them out there.

[00:04:28] B: So, you mentioned ref and reactive work as normal, but I think I tried playing around with that recently. So, normally, in the composition API, when you use the reactive object, you'll usually unbundle the object with two refs as a way to not have to prefix all your templates with like, State dot first name, State dot last name, State dot full name, right? Have you found a way to do that inside of the script setup block?

[00:04:52] LM: I think it should work the same, you just destructure it and they should be made available in the template. I never really thought about it, actually. But yeah, I do –

[00:05:00] B: You’re not explicitly setting a return. So, if you’re not explicitly setting a return, you can’t actually tell – that’s when I ran into a problem. At least I haven't – that’s one thing I haven't figured out with it yet. Trying to get to the answer.

[00:05:12] LM: Interesting one. Yeah. My assumption would it be, I thought it would just be the same, like you would have your reactive object and you can just access it in the template. I could be missing something here. Like we said, this is a very new proposal.

[00:05:26] B: Yes, very experimental. We’re talking hypothetically.

[00:05:27] LM: Yeah, it is possible. There's a bit of a learning curve there. But yeah, I mean, I think most of the – just looking at the feedback now on the – yeah, just looking at the RFC feedback for the basic script setup RFC, it's got all thumbs up, it has zero thumbs down. I think people generally seem pretty satisfied with it.

The most sort of polarizing RFC is ref sugar. So, instead of writing React const variable equals ref count, for example, to declare a new variable, there's an alternative syntax which has been proposed, where you just say ref, colon, and then you just put your number in or your variable in, and it kind of makes it magically reactive. This is something that got a lot more mixed feedback, because it's sort of implicitly taking your variable and making it into a ref or reactive. But that's a further layer of abstraction away from from Vue, which is already at one layer of abstraction away from JavaScript.

Some people love it. They're like, “Wow, it's even more concise now.” But the downside is, it's a little bit more difficult for new developers to learn. There's a kind of more steep learning curve, and Vue traditionally was all about simplicity and ease to learn, so I think that's something that we all want to keep in Vue, both for developers and for new users alike.

[00:06:47] A: Yeah, this is really interesting to look at. I've pulled it up on my screen. So, I'm looking at it. I hadn't seen – I think I had previously seen the script setup RFC. But I don't think that I've seen the ref sugar one. For anybody listening who has ever looked at another framework, another JavaScript framework called Svelte, the syntax for this looks very similar to Svelte and how they do some of their stuff. Having not seen this before, I have mixed reactions.

[00:07:28] LM: So, what is your first impression? Because I mean, I think we can all recognize that new things are always a little bit uncomfortable. When we all saw JSX for the first time with React, people were like, “Wow, what is this?” But some people came to love it. So, I mean, I think it's fine to have a negative first impression as long as you have an open mind. What's your first impression there?

[00:07:47] A: My first impression is I want to write Vue not Svelte. But at the same time, in theory, there is a potential performance benefit from syntax like this, where we move more towards compiler directives, so that the developer can say, “Hey, do the thing whichever way you think is best.” And then from a compiler standpoint, you can go, “Oh, you're actually doing like an object in there.” So really, we shouldn't use ref, we should use reactive instead, and that'll give us a performance boost, and blah, blah, blah, blah, blah, right? So, I'm torn about this one, because I'm like, “This is great. But this is also not something I would use.” So, those are my initial gut reactions on this. Tessa, how do you feel?

[00:08:36] T: I mean, just hearing it described, I'm already completely bought in. But I do also miss filters, so I don't know if people will trust my opinion on these things. Like, I'm already looking at the ref and reactive methods and thinking, “Well, that's new and foreign to me still.” To me, like, should I go with that? Or should I go with this other syntax to do the same new thing? To me, that doesn't feel like an abstraction on top of an abstraction. It just seems like one is a shorter way to do this new thing that I have to learn either way.

[00:09:13] LM: Sure. On the note of filters, unrelated, but it's pretty easy to hack filters back into Vue, if that's something you're excited about. The new compiler is very – has an extensions architecture. You can add things in yourself. I do think as time passes, we'll see more and more experimentation with Vue as we're seeing with the ref sugar as well. I'm pretty interested in what Ben also has think about it, because I know you've been doing Vue for a long time. It's a bit of a departure from familiar territory, right?

[00:09:41] B: Absolutely. One of the things you mentioned actually, that I did want to – as some of us like say, to double click into, is that this sort of –

[00:09:51] T: No, none of us are like that. Sorry, keep going.

[00:09:56] B: Some of us. So, you were mentioning this idea regarding like, it's a departure from what we're used to. It's like bringing in filters. A filter is actually a great distinction on this particular discussion, because it's pulled back even a little bit. For those who don't know, what filters are, you basically with inside of your template, you will say something like the current, like the total price, and then a single pipe operator and then say, like currency. And so, we’ll take the total price value, and then call it format it into the currency filter. That's kind of basically what it did.

But also, for those of you who are more familiar with Vue, you're probably thinking that's basically a computed property or like a method, right? The method is applying something and that's it. The reason this was deprecated, was motivated largely to the fact that JavaScript as a language is actually thinking of using the single pipe operator, for I don't know exactly what it was, but it's actually planned on using it for something going forward. If what we're interpolating between our curly braces is supposed to be plain JavaScript, now you have this risk of, like, is this single pipe for Vue filter, or is the single pipe for the new, call it, the ES 8, whatever comes out. So, knowing that there are specs being discussed, basically, this is one of the reasons it was basically taken out, since it's basically doing what you would normally do with a method anyhow.

That said, with this ref sugar syntax, one thing to clarify, too, is that in addition to just getting the syntactic sugar of saying instead of const, count, you would say, ref colon count, the other problem to solve is that you no longer have to do access the value with dot value. This is the biggest foot gun, when it came to refs or comes to refs in general is that most people aren't used to having to access that value when they're dealing with refs, and it gets into even a whole more messy territory, as Alex knows, watching me try to work with like watching refs, because then if it's an array kind of has a different thing, because you have to have a deeper understanding of what's going on.

I think this is why this syntactic sugar is being discussed is because, I know, some of a lot of our initial reactions to things is this is not how JavaScript does things and this is not what I'm familiar with. But I think one of the things I think Evan pointed out well, is that like, the language does need to find ways to move forward. A lot of times what libraries do as they help to build the conventions that we know of today, right? Like, jQuery is the reason why we all associate the dollar symbol with selectors. That's basically where that convention came from. Without jQuery, you wouldn't have like in your Chrome developer experience the dollar sign zero, which would select the most recent element, right? If I'm not mistaken, Lachlan, maybe you might know. But I believe that was inspired largely by jQuery.

[00:12:28] LM: Yeah, I think so. It's also very useful. So, there's that. It's interesting that you mentioned how it’s, I guess, moving JavaScript forward, because one of the original motivations with the competition API was to get us closer to JavaScript, right? Because all the sort of magic that the options API exposed and how it would mutate this made TypeScript very difficult to work with. But this kind of goes back in the opposite direction. It is a slight departure from JavaScript. Whether this is easier to type and the tooling will catch up is another question.

But one thing I noticed with this is it feels weird at first, but when you try it out, and like really try it out for a few hours, it starts to feel pretty good. So, I do think people need to give it a chance, at the very least, and see how they feel about it. People are saying, “Wow, it's so similar to Svelte.” If you looked at the State of JS survey, Svelte is really popular and it's gaining a lot of popularity. So, it's good to take inspiration from other frameworks. I think React and Vue have both driven each other and many other frameworks as well have, like jQuery is the reason why we have all the nice things we have. So, to ignore other innovations and other frameworks would be shortsighted. I think there's a lot of value in at least exploring these kinds of ideas.

[00:13:47] A: Now, one thing that I'm looking at with this, I find very interesting. So, we have a script tag with an attribute of setup on it and we define a bunch of things in there. I have a lot of components that have props, how do I define those?

[00:14:07] LM: Sure, I can cover this one, I suppose. If you actually – I guess you're on the GitHub page. If you click on rendered in the RFC, you can see a more longer detailed version of this. There are a few new methods exposed which are things like define props I believe it's called or something like that, it might be in the other RFC. It's in the other RFC actually. This one is purely about the sugar, the syntactic sugar.

If you look at the script setup RFC, the one we talked about earlier, I believe there is a defined props method or something like that, which will – yeah, define props and define image. So, you can specify which props will be received. So, there is that. It is another thing to learn, I suppose, but it definitely will help with TypeScript for sure and you have to define the props anyway. So, I don't think it really changes the amount of code you have to work.

[00:14:56] A: Yeah, I was just right off the bat, thinking about it, and sort of looking at some of the examples. I was like, “Where is this? Why can't I see it?” But now I see it. So, that's very interesting.

[00:15:10] LM: If you think about it, it's very consistent actually, with the defined component, especially for those working with TypeScript follows that exact convention. So, define component, define props, define limits. So, in this regard, granted, the pattern might be – it is a departure from what we're used it from options API, but then again, the composition API is supposed to introduce a new paradigm. I think coming with that level of understanding and open mindedness, I think is critical. For those who are probably wondering, how do I access the props that are being passed into said component? The attribute, if you give it an equal sign and then in the double quotes, it'll have the props and context argument that you would normally expect to get as arguments to the setup method. So that's how you expose those.

[00:15:52] T: So, for those of us not familiar with the TypeScript thing that you were just talking about, do you mind sharing a little bit of context?

[00:16:01] B: Yeah, I think actually, I'll throw this one to Lachlan, because he has a whole course on this. So, why don't you tell people about defined component?

[00:16:07] LM: Sure, okay. So, I mean, I think one of the big driving decisions behind the design of the new composition API is it is closer to JavaScript, in a sense. We don't have to – for example, in the options API, you can go and create a data method, then you can access it in a computed property by saying this dot foo, or this dot message, or whatever. How that came to be available under this is not entirely obvious sometimes because Vue does a lot of kind of magic instrumentation in the background, which gives you a really great experience if you're just building something small. But as your apps scale, TypeScript is valuable, and the dynamic nature of this in JavaScript is very difficult to type.

The way composition API is set up is it's much closer to raw JavaScript. There's no or less magic in the background. For example, when you want something to reactive, you say ref as opposed to just declaring in data and having it magically be reactive. This sort of separation makes it much easier to type your methods and type everything. And you can get better type safety, which is something that's very valuable to a lot of people on very large applications.

I think that won't change at all with this script setup RFC. It should work the same because everything is compiled to a traditional setup function anyway. Does sort of answer your question, or we're looking for something more specific?

[00:17:34] A: I guess my question is, is that with the the ref sugar syntax where it looks more like Svelte, do we know what the TypeScript story with that is going to be like? I know that editors and stuff give some help with types and type hinting and that sort of thing, but how is that going to go with the sugar syntax?

[00:17:59] LM: Yeah, good question. I'm also fairly curious to see how this plays out. I would expect that, I mean, I'm sure this has been thought about. I'm not sure how complex it is to implement, I have no doubt you can type something like this, especially with defined props, define limit, and all that sort of thing. It should, if anything, make it easier. But as always, you got to consider that someone has to write these editor plugins. Someone has to maintain them. And it's more complexity. There is actually a drawback section of the RFC I'm reading now, and it talks about the tooling. But there's no reason why we can't type these things in the same way we type everything else. Svelte has great typing as well and they have a similar API. So, there is previous literature on how you can do this sort of thing.

I don't see the technical side of it as a blocker. It's more about the people side of it, whether people adopt the API or a new new style of writing or not. It doesn't mean we have even more ways to right view components. We have classes, we have options, we have traditional composition, we have script set up, it's something we need to be considering when expanding the framework. And, as you all know, JavaScript constantly has new features, which is great. But it also means many more things to learn, which makes the barrier to entry much higher.

[00:19:16] T: I also want to tie back to something you said, Lachlan, about this context, with something Ben said earlier about the curly braces in the template and how that's pure JavaScript. I just wanted to add that note there that it's not technically pure JavaScript, right? Because we do have that proxying where anything on this you can just access without this dot, which like, personally, I really enjoy having that convenience. But that is a point that many people who start few find really challenging even for some people after they've been working with it for more than a year, they might still find it frustrating.

[00:19:48] B: Yeah, that's an important clarification point. Yes. This is so right. Not pure JavaScript. But JavaScript statement is really what I meant to say. That's evaluated.

[00:19:56] LM: Yeah, I mean, there's always going to be sort of caveats or rules you need to keep in mind. I think that it's not too bad to understand that anything exposing a template is available in the interpolation. The one thing that is not available with window, you can't say something like window dot blah. It's really just what comes from your template, which is somewhat unintuitive at times, because if something was on the window, you generally expect it to be available everywhere. It's not available inside of curly braces.

It kind of plays back to the point that this kind of ergonomic tooling can have downsides that it's not exactly what you might be used to coming from another framework. I definitely want to keep using that.

[00:20:39] T: Yeah, every time an event handler doesn't fire, and I know that I need to, like console log something just to make sure that it happened, I cry a little tear of blood, because I know I'm going to have to make a method just to console log it.

[00:20:53] LM: Right. No console logins inside of templates, which is – I mean, it doesn't happen that often, right? But when it does, it's like, “Oh, man, again.” It's a little bit. What would be really nice is if you could use a filter, where I would want to it – what I wanted to do, if you have a method and you have a filter, it would be nice if you could filter into console log, you can easily see the value. But that's something you can't do inside of a template, which is it's not a big deal. But it just does show you there are limitations when you have these of extra steps in your processing to give your ideal developer experience. You do have to make payments, and there are tradeoffs involved.

[00:21:32] A: Clearly, you just need to make a global mix in to bind console to your component and –

[00:21:45] B: With this kind of stuff though, while it wouldn't necessarily make sense maybe to build into the library directly. I mean, with [inaudible 0:21:48] plugin and things like [inaudible 00:21:50]. I feel like because you can identify where blocks are like for those of us who play with it, it will automatically import things. I know part of that is due to TypeScript. So, I can basically call components before I actually import it, and then it will call the import statement correctly.

I don't see why we couldn't enhance the DX from like, if you want to call it to a log method within the template, there's a specific one you would call, it would automatically create that inside the method block with a console log statement. I don't see why that wouldn't be possible. I think that would actually probably help a lot of people.

[00:22:21] T: We’ll make sure he hears this this episode.

[00:22:25] LM: I don't know if anyone's really played around with this. But Vue 3’s compiler has that kind of plug in architecture, you can build in stuff, basically. And you could easily build in like a console log or a filter or something like that. I do look forward to when people start experimenting more with compiler plugins and building different things. I have no doubt someone will build filter in the near future, so you can have filters again. They’re beautiful for migration purposes, at the very least, right?

[00:22:51] T: I mean, I like it because I like the aesthetics of it just this idea of you smash something through a wall, and it's kind of like the before, after, how it's been going, or that whole meme. But in terms of like the way I actually think about breaking down component data and stuff I think, conceptually, it makes sense to keep that stuff in the script tag where possible.

[00:23:10] LM: For sure, I agree.

[00:23:12] T: But this idea of whether the filter is worth any potential tradeoffs or not, it does kind of harken back to the question that Alex closed on last episode, which is, is there too much magic?

[00:23:23] B: I think, for me, I actually don't think there can really – okay, sorry. There are always an option for too much magic if you abstract to the point that people don't understand something. That I think is where you get to literally too much magic. But I think to say that you're abstracting things to make people more productive, and that they're just new learning, there are new things to learn, I don't actually consider that magic anymore. I think it's like a lot of things.

We are entering a new age where a lot of things are being abstracted away. I was just on a talk, a couple hours ago about how just, maybe five or 10 years ago, developers were manually configuring servers to make sure they could serve their web applications to the community. Now, we have serverless things. We have all these things that really empower us, and we don't have to focus on those things. Technically, now, then that means serverless is magic. But it's just like, I think abstractions, as long as we have opportunities to dive in and learn more is okay. But if you abstract to the point where people can't follow, then yes, that would be.

[00:24:24] LM: Yeah, I agree. I think the good abstractions are good. You don't just make them for fun, or just for the sake of it. But people said that there's a lot of boilerplate involved in setup, which led to the creation of scripts setup. It wasn't like, let's just make a new way to write components. It was more like, “Okay, there's been a lot of feedback and let's take the feedback on board and see how we can improve the experience based on this feedback.”

So, those abstractions are good. The ones that emerged from real world problems. So yeah, I don't think there can ever be too much magic, but there should be good reasons why you have abstractions. They should have the right thought process behind them.

[00:25:03] A: Yeah, I'm going to agree with Ben on this one, is that you want to – there’s a lot of stuff in Vue that already is magic, right? Templates are kind of magic because, ultimately, they get compiled down into a render function. The same thing in React with JSX. You have these magical compiler directives that look kind of like HTML, but they aren't. We're already doing stuff that is magic, to a certain extent. Vue is doing a lot of stuff that's already magic but, at the same time, if you go too far with that magic, it's going to not be magic. Then it becomes arcane, dark arts, and we're all in the Land of Pearl and it's not good. We don't need to go back to that world.

I think a little bit of magic can't hurt. I'm excited for this script setup thing. I'm hesitant about the ref sugar concept. But in general, I kind of like it.

[00:26:15] LM: All I will say to listeners is try it before you buy it, in this case. Definitely give it a good try for like a few days and then see how you feel.

[00:26:26] B: Seconded on Lachlan’s point.

[00:26:29] A: So, the last kind of question that I have for you is that this is an RFC that is open. Is there a way to play with it? Is this available? Is this something that we can play with, that we can write with now? Or is this something that is still just being sort of explored and discussed?

[00:26:51] LM: Yeah, so this is available right now in Vue 3 if you install the latest version. It doesn't mean it's going to be in the framework forever. But it's there, so you can try it out. It does give you a nice big console log saying it's experimental and it might change. But yeah, you don't have to do anything special to try it out. You just need to install the latest version of Vue, and you can get going with it right now.

[00:27:13] B: Yeah, and to double down on Lachlan’s point, experimental thing, while it shipped in the 3.0 whatever bundle it is, the API is experimental, so you cannot count on it to stay the same. That's why it's in there.

[00:27:26] A: Awesome. All right. Well, I think that's it for this episode. Lachlan, where can people find you on the internet?

[00:27:36] LM: Yeah, sure. So, I mainly hang out on Twitter and GitHub, but I started a YouTube recently as well, where I post new content occasionally. So, I'll get links left to those in the description for the show notes and you guys can check those out.

[00:27:49] A: Fantastic. So, with that, it is time to move on to this week's picks. Tessa, do you want to go first?

[00:28:01] T: I can. I was looking at testing stuff earlier today, because I was trying to think about what we might discuss, and I had found out that someone had a YouTube channel, which he just mentioned, so that was my pick. That's my pick.

[00:28:17] A: Ben, you're up.

[00:28:19] B: All right. Well, I'm thinking, so for those who don't know, Lachlan does have a couple courses on Udemy. So, totally recommend checking those out. So, my pick for this week is Lachlan’s Udemy courses.

[00:28:30] LM: Thanks.

[00:28:30] A: Cool. Clearly, I just need to make my pick. Just be like, “Lachlan, you should just – I pick Lachlan. That's my pick.” Lachlan, do you have any picks this week?

[00:28:43] LM: Definitely. So, not to do something a little bit different. I watched a documentary on Netflix recently called My Octopus Teacher. Have any of you heard of it? Maybe not?

[00:28:54] A: I believe I have.

[00:28:56] LM: It’s about a researcher and he's researching an octopus. As opposed to a traditional documentary, where you just learned about the animal, he researched one specific octopus and they sort of built this unexpected relationship, like a friendship. He was with it throughout its entire life, from when it was a young octopus until the end of its life. He sort of followed it for its lifecycle. I became familiar with him. It’s really, really interesting. Definitely worth checking that out. It is only an hour long, so it's not a really long watch. But yeah, it was really different to anything I've seen before and quite emotional, actually, to see a man forming a bond with an animal like that. Especially a wild one that we traditionally wouldn't – something so alien and so different to us. So, it's really, really interesting and fascinating stuff.

[00:29:44] A: Excellent. Finally, my picks are, the one pick that I have is Kelly Maloney's shop, SoSplush. You can find it at sosplush.com. She has stickers that are fantastic. I have gotten several of them. She has several Vue types of stickers and they are wonderful and amazing and really high quality and they look really good. And then I've plastered them all over my mug because they're pretty fantastic. So, that is my pick for the week.

[00:30:22] T: Oh my gosh, this whole time, like for the last two years or something, I thought it was So Splush. Like I thought that was the name.

[00:30:29] A: I'm not sure how to pronounce it. So, I'm going with SoSplush. It may be So Splush, I'm not sure. So, it's either SoSplush or So Splush.

[00:30:38] LM: Wow. These look awesome. I’m just looking at it.

[00:30:41] A: Yeah, they're really great.

[00:30:44] LM: Very cool. They even have a VM one, my favorite editor.

[00:30:46] A: And she sends them in this bright pink envelope. I have them right here and they are they are just lovely.

[00:30:56] T: For the listeners, Alex is showing us a very bright pink envelope and some Halloween stickers, but I can't see them because the envelope is so bright that I've turned away.

[00:31:05] LM: They look awesome, honestly. Very cool. She actually has a mask as well, which is something I think everyone needs at this point in time with COVID dragging on.

[END OF EPISODE]

[00:31:17] A: Alright, and that's all for this week's episode. Thanks for listening, and until next time, Enjoy the Vue.

[END]