Production-Grade Vue.js

JavaScript Best Practices

Ben Hong

Ben Hong

Production-Grade Vue.js

Check out a free preview of the full Production-Grade Vue.js course

The "JavaScript Best Practices" Lesson is part of the full, Production-Grade Vue.js course featured in this preview video. Here's what you'd learn in this lesson:

Ben explains the single file component (SFC) structure and outlines a few best practices for writing JavaScript in Vue applications. Using TypeScript in Vue 3 is advantageous since Vue 3 is written in TypeScript.


Transcript from the "JavaScript Best Practices" Lesson

>> All right. To start off, we're gonna talk about the core languages that make up our Vue.js application. And so we're gonna start with single file components, which is probably one of the the backbone of a lot of what makes Vue.js's developer experience. So ergonomic and fun to build on.

As a quick overview for those who might be new to Vue for the first time. The idea here is that you have these files that have the extension .vue. And these .vue files are what we refer to as, single file components or SFCs, that you'll see often referred to in articles.

And so, single file components compose primarily of three parts. There is the template which includes your HTML. There is the script block, which includes the JavaScript that will be run within this file. And then as well as the style, as far as containing it's CSS and anything that pertains into this component.

And for those wondering though, this will automatically get like split out a build time into its various pieces, so that it's performant. But as far as the ergonomics of developing with it, single file components have proven to be quite useful as far as keeping the scope of concerns all into one file.

So, let's talk about the JavaScript portion of the Vue app, which is basically the core right of how we're building everything. The major discussion point right now, when it comes to, in the JavaScript world is should I use JavaScript or should I use TypeScript? Now, in my experience, a lot of times the arguments for TypeScript tend to revolve around trying to prevent bugs.

But as far as production grade level apps, a majority of the bugs often encountered in my experience are often not actually due to type violations. And so the thing about TypeScript, right? Is that while it does a lot to enhance the developer ergonomics of ensuring you're documenting what code is expecting, as we know, TypeScript does not inherently guarantee type safety, right?

It requires discipline on the team's part in order to do that correctly. When teams are considering whether or not to do JavaScript or TypeScript, a lot of times they're also talking about migrating to, right? They already have an app in JavaScript and saying, well, is it worth switching to TypeScript?

And because of the fact that again, most of the bugs we encountered these days aren't necessarily due to type issues. I'm spending the time to ensure that your entire code base has full type safety can be a significant cost to a team in terms of productivity. And so when it turns to slowing down, building new feature and then the things it has to be, we have to be really careful when weighing whether or not it makes sense to migrate from JavaScript to TypeScript.

And so as a whole, instead of spending time trying to convert our apps from JavaScript to TypeScript, most application would actually benefit from better testing strategies. As well as improved code reviews, in order to provide that, basically a more rigorous structure that they can rely on. On top of that, what a lot of people don't know is because a lot of us are using Visual Studio Code, type can actually be progressively added into a codebase using JSDOc comments.

Meaning that when you hover over it, you'll actually be able to see snippets of basically what the types are. And so I'll make sure to include a resource that y'all can see later. But this is something that again is very much to the Vue sort of ethos as far as like, allowing you to achieve the effect of documenting types but not in a way that requires you to like overhaul your entire code base.

And so for those who have done some research as far as Vue and TypeScript when it came to Vue2, TypeScript was not considered in the original design. So a lot of the ergonomics regarding especially things like Vuex are kind of painful to hack around at the moment. So if your application is already in Vue2, it's probably not worth it to upgrade it to TypeScript at this point because you're probably more in the maintenance mode, and there are less benefits than people think as far as like spending that time to upgrade.

On the other hand, if you're starting a brand new project from with Vue3, Vue3 has been completely rewritten from the ground up using TypeScript. And so this means that tooling, especially as the ecosystem continues to mature, we'll get a significantly better as far as TypeScript support. And so if you and the team are interested in trying out TypeScript and seeing how it works on a brand new project, I definitely would recommend trying it out on a brand new Vue3 project.

And so the final piece of caution, I want to add when it comes to JavaScript versus TypeScript is to understand the team makeup of whoever is working on the code base. Because especially in today's world where we have a lot of developers entering programming for the first time using JavaScript as their primary language.

This means that their familiarity with things as strongly typed languages, these are not as familiar with them. So there is an on boarding cost in addition to just the sheer fact of migrating everything over. So being cognizant of that mental overhead as far as pushing a team forward, pushing a team forward on time is important to consider when making those decisions.

So we have a question regarding whether or not these like typing applies to proptypes and so in this regard on Vue2 because props already inherently have the ability to give basic types. I think that and custom validators that usually will do the tricks far as typing your props without converting your whole code base into TypeScript.

But again, if your team does find the value in enhancing the entire application to TypeScript, it certainly can be used with prop types.
>> Discussion with a colleague yesterday, actually, we were wondering why Vue is recommending export default for single file components. And if you're not sure, it's okay, since it just came up yesterday and I saw it in your slide example, I thought I'd ask.

>> Okay, got it. So, there is a question regarding, why Vue, by default, in single file components uses the export default rather than sort of named exports. And so from what I understand, Vue will actually do its part to actually like pull out the name of the component and those things.

So it does a little bit of optimization as far as helping like sort of name bundles and point them to the right places. So, as far as I'm aware, that's why export default is what we use, by default, lots of defaults on single file components.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now