Production-Grade Vue.js

HTML Best Practices

Ben Hong

Ben Hong

Production-Grade Vue.js

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

The "HTML 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 demonstrates how to use HTML in both a template block and the Vue render function. Templates are the recommended method since they are the most declarative way to write HTML. The render function is useful when the markup needs to be programmatically generated.


Transcript from the "HTML Best Practices" Lesson

>> So as the best practice, all HTML should exist in .vue files in either a template block or a render function. And so the alternative to this if you're wondering where else would it live is you could theoretically split out your HTML into individual dot HTML files. Or if you have other preprocessors you'd like to use like pug, for example.

Some people might actually break them out into different files. But this is not the recommended practice for a few things that I'll mention in a little bit. And so when we use w files, one of the benefits w provides us is that it actually has the opportunity to parse it and basically allow for some developer ergonomics that might not be possible otherwise.

If you're simply containing your HTML in an entirely separate file. And so one of the examples of this is self-closing tags. And so for those that don't have as much familiar with this. So here we have a standard span element that has a class of fa awesome, fa awesome info.

And so inside view, we can go ahead and it would be illegal to go ahead and close this off by itself. But this wouldn't actually work, as well as some other custom elements. This wouldn't work in standard HTML. So if you're ever working in like kofun, for example, and you're just trying to do some self closing elements, only certain ones are permitted to self close.

And so this is super convenient because as you're using your dot view files, when you have different components, for example, that have longer names or you're listing multiple attributes, it allows for a really clean reading experience from basically what's included in that component, especially if you don't have anything being passed in as far as slots and those things.

So a little bit of a reading ergonomic, but a nice thing to have In addition, one of the nice things about this is that when you include everything in the .vue file, you don't have to include the script and style blog. This is something that I think there are some misconceptions around.

So if you're just, I just want the HTML here, that's totally fine. You can still include it as just .vue view file. But then what's nice about this is going forward as you need to enhance components because that happens, right? You start out thinking you only need this.

But as you want t, for example, either scoped styles to that component, or maybe even add a little bit of functionality. It's as simple as a developer going into the .vue file and then adding the script block or style block, as opposed to then going into a separate file or creating a brand new one.

And so this is, again for enforcing consistency, which is probably one of the most important things when it comes to creating production. A great view apps is having that consistency then allows people to know reliably where everything's coming from. So something to keep in mind for those things.

And so when we talk about the template versus the render function, most of us are familiar up here with the template block, right. This contains our HTML and what most of us have experience with when it comes to vue. And so when it comes to the render function, this is something that most people probably very rarely encountered, because a lot of times there isn't a need for it.

But one of the misconceptions I've seen a lot with vue is that like templates are the only way to write HTML and this couldn't be farther from the case. So instead of having a template block her, what we can have instead is we'll have a render function that were declared inside of our default, export default objects.

And so by declaring the render function in vue two it's automatically passed the Create element function, which we can then use to go ahead and create the individual node objects, sorry, the DOM elements. And so in this case, we took our H1 that says hello fronted masters and as you can see here, we've used a Create Element function and gone ahead and created the h1 element with the Hello frontend Masters text inside of it.

And so this is basically an escape hatch for when templates become a bit unwieldly to manage and so we'll practice an example of this in a little bit. And so when it comes to vue three, one of the new things that's gonna take a little getting used to, is that vue because it's been basically code split and it's tree shakable.

Meaning that a lot of different pieces can be left off of production build if you're not using it. This means we're gonna start importing more helpers from vue three going forward. So as we can see here I've imported the this H function, which stands for hyper script, basically.

And so it's the equivalent of the Create element function. And so what this does is this allows us to then do the same thing as create element. And so rather than the render function always being bundled with the Create element function, in vue three, what's going to happen is we can simply pass it the H hyper script function.

And then that will allow us to then achieve the same thing. So the main thing here is that the hyper script function is imported from vue and then we use it inside of our render function. And so there probably some of you wondering too, especially those with react backgrounds, well, does this mean that we can use JSX?

And the answer is absolutely there are babel plugins that we can add to vue apps to that In the event, you wanna use JSX, you can use that with the render function just like you would in react. Templates are the honestly the best way to write HTML because it's extremely declarative.

And anyone can get in there and understand basically what's going on. So it's recommended as the default. However, in the event, you need to programmatically create your markup basically, this is where render functions can be extremely powerful. And so in the exercise we're gonna do together we're gonna go ahead and build an example of this to show where the render function might be better than the template function.

Another technique that I've seen a lot on big vue applications is the V-bind v- on object shorthand, and so unfortunately I think the experience with this is mixed so this is why we're gonna cover this right now. So most of us are familiar with the V-bind and v-n direct is where it allows us to dynamically bind either props or events, to our elements and do whatever we need to it.

So here we have the vue multi-select component and we've bound a couple of things to it, right. We've bound the options, the value of the label, and we've bound three different events, three different methods. And so, as you can imagine though, even with just these six, so these three, three attributes and three events, there's a lot of noise going on here.

And this gets even worse. The longer you have components with more props or more events it can be a lot what a lot of people don't realize is that this can actually be shorthand into the v-bind object syntax. And so v-bind can basically then think of it almost like a spread operator.

It takes an object where it takes the individual key pairs, as far as what the, in this case, the attribute name is. So in this case, whether it's options, value label, and then we bind it to whatever JavaScript equivalent that we want. And the same can be done for the v-on as well.

And so you can see here that our events now have been reorganized into the object format, which then allows us to basically contain everything in an object. And so some of you are probably thinking already too. So with ES6, we can go ahead and shortcut this, into just the key itself since the key and the value are identical.

And then on top of this what we have as well, which is really nice, is that you can then because it's just a JavaScript object, we if we had a VMs props for vue multiselect. Instead of a data object, we can then bind that and then track it somewhere else entirely.

And this allows us to shortcut what exactly is being bound into this component. And so just as we can do that for v- bind, we can do the same thing as well with the v-on as well. And so you might be wondering, okay, so which one is, why would I choose one or the other?

So when you just have simple prompt declarations or a few events, it's only doesn't make sense to do the shorthand because as you can see, it basically obfuscates what exactly is being bound and what events are being triggered. However, when you're doing things like binding on things that needs to be dynamic.

So whether you're swapping out components with the component the built in component, for example, or other things were properly to change, then this is a great way for us to then swap out only what's needed for the component. And something to basically keep in mind and a lot of people use when it comes to dynamically generating components.

So, I just want you to keep that technique in mind cuz you'll see it a lot in different code bases. So, there's a question regarding the render function. So, I'm gonna go ahead, and let me back up to here, okay. So, regarding the H functionality here. So, H is basically the equivalent here of create element that we saw in vue two, but in vue, they use the h to name for the utility function for hyper script for basically creating markup.

And so inside of the render function, basically we use that as basically think of it just like another name for a treat element. And what it does here in the simplest form, it takes two arguments, which is the element that you want to create on the left. So that's why it's the H1.

And then what will go inside of the element and in this case, and just plain text, it'll be Hello Frontend Masters. And so for those who wanna use the render function, one of the things that also makes it tricky in comparison with the template is that there's a whole API that goes with it.

You have to learn how to dynamically bind classes, figure out which arguments do what. And I totally recommend checking out the dots if this is something that's worth doing. But this is why for the most part, it's usually more valuable to just use the template and only the render function when there's an actual improvement as far as developer experience and maintenance.

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