There are numerous ways to define templates in Vue, but many of them don't work so well in production.
More Vue Tutorials
Instead of defining an HTML template for every component, you define all your component HTML in one top-level template.
This is similar to slots. The advantage of this approach is you can define all your app's HTML in one template, but still break up business logic into separate components. Single file components give you the best of both worlds between putting your HTML template in a separate file and putting your HTML template as a string literal.
Like string literals, everything about a component is in one place. Like separate HTML files, you can get decent syntax highlighting. The tradeoff is that single file components are typically declared in a separate .vue file with its own special syntax.
Single File Components
Below is an example of .vue syntax. Depending on your IDE, you may need to install an additional package for .vue file syntax highlighting.
So in order to compile your component, you need a build step.
There are numerous tools that can do this for you, like the Vueify transform for Browserify and vue-loader for Webpack.
Under the hood, both of these tools use vue-template-compiler. Here's an example of using vue-template-compiler directly to compile Vue syntax into a component:.
Vue School has some of our favorite Vue video courses.
Their Vue.js Master Class walks you through building a real world application, and does a great job of teaching you how to integrate Vue with Firebase.
In the case of boolean attributes, where their mere existence implies
v-bind works a little differently. In this example:
isButtonDisabled has the value of
disabled attribute will not even be included in the rendered
Template expressions are sandboxed and only have access to a whitelist of globals such as
Date. You should not attempt to access user-defined globals in template expressions.
Directives are special attributes with the
v-for, which will be discussed later). A directive’s job is to reactively apply side effects to the DOM when the value of its expression changes. Let’s review the example we saw in the introduction:
v-if directive would remove/insert the
element based on the truthiness of the value of the expression
Some directives can take an “argument”, denoted by a colon after the directive name. For example, the
v-bind directive is used to reactively update an HTML attribute:
href is the argument, which tells the
v-bind directive to bind the element’s
href attribute to the value of the expression
Another example is the
v-on directive, which listens to DOM events:
Here the argument is the event name to listen to. We will talk about event handling in more detail too.
New in 2.6.0+
attributeName, whose value is
"href", then this binding will be equivalent to
Similarly, you can use dynamic arguments to bind a handler to a dynamic event name:
In this example, when
eventName‘s value is
v-on:[eventName] will be equivalent to
Dynamic Argument Value Constraints
Dynamic arguments are expected to evaluate to a string, with the exception of
null. The special value
null can be used to explicitly remove the binding. Any other non-string value will trigger a warning.
Dynamic Argument Expression Constraints
Dynamic argument expressions have some syntax constraints because certain characters, such as spaces and quotes, are invalid inside HTML attribute names. For example, the following is invalid:
The workaround is to either use expressions without spaces or quotes, or replace the complex expression with a computed property.
When using in-DOM templates (i.e., templates written directly in an HTML file), you should also avoid naming keys with uppercase characters, as browsers will coerce attribute names into lowercase:
Modifiers are special postfixes denoted by a dot, which indicate that a directive should be bound in some special way. For example, the
.prevent modifier tells the
v-on directive to call
event.preventDefault() on the triggered event:
You’ll see other examples of modifiers later, for
v-on and for
v-model, when we explore those features.
v- prefix serves as a visual cue for identifying Vue-specific attributes in your templates. This is useful when you are using Vue.js to apply dynamic behavior to some existing markup, but can feel verbose for some frequently used directives. At the same time, the need for the
v- prefix becomes less important when you are building a SPA, where Vue manages every template. Therefore, Vue provides special shorthands for two of the most often used directives,
They may look a bit different from normal HTML, but
@ are valid characters for attribute names and all Vue-supported browsers can parse it correctly. In addition, they do not appear in the final rendered markup. The shorthand syntax is totally optional, but you will likely appreciate it when you learn more about its usage later.