new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Vue · API reference · all subjects

built-in-special-elements

27 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

<component> is prop type

The <component> element has a single prop named 'is' with type 'string | Component'. The actual component to render is determined by the 'is' prop.

<component> is prop can be HTML tag or component name

When 'is' prop on <component> is a string, it can be either an HTML tag name or a component's registered name. Alternatively, 'is' can be directly bound to the definition of a component.

<component> example with registered name

Example showing <component :is="view" /> where view is a data property containing 'Foo', with components registered in Options API: ```vue <script> import Foo from './Foo.vue' import Bar from './Bar.vue' export default { components: { Foo, Bar }, data() { return { view: 'Foo' } } } </script> <template> <component :is="view" /> </template> ```

<component> example with component definition

Example showing <component :is="Math.random() > 0.5 ? Foo : Bar" /> with Composition API and <script setup>: ```vue <script setup> import Foo from './Foo.vue' import Bar from './Bar.vue' </script> <template> <component :is="Math.random() > 0.5 ? Foo : Bar" /> </template> ```

<component> rendering HTML elements

The <component> element can render HTML elements by passing the tag name as a string to the 'is' prop. Example: <component :is="href ? 'a' : 'span'"></component>

<component> with built-in components must be registered by name

Built-in components like Transition and TransitionGroup can be passed to the 'is' prop, but they must be registered if you want to pass them by name. Registration is not required if you pass the component definition directly to 'is' rather than its name.

<component> v-model incompatibility with native HTML elements

Using v-model on a <component> tag will be expanded to a modelValue prop and update:modelValue event listener by the template compiler. This won't be compatible with native HTML elements like <input> or <select>. Using v-model with a dynamically created native element won't work and you should split v-model into an attribute and event manually.

<component> v-model on native element example

Example that won't work - using v-model on a dynamically created native element: ```vue <script setup> import { ref } from 'vue' const tag = ref('input') const username = ref('') </script> <template> <!-- This won't work as 'input' is a native HTML element --> <component :is="tag" v-model="username" /> </template> ```

<component>, <slot>, and <template> are not components

<component>, <slot> and <template> are component-like features and part of the template syntax. They are not true components and are compiled away during template compilation. They are conventionally written with lowercase in templates.

<slot> props interface

The <slot> element accepts props with interface: ```ts interface SlotProps { /** * Any props passed to <slot> are passed as arguments * for scoped slots */ [key: string]: any /** * Reserved for specifying slot name. */ name?: string } ```

<slot> name attribute specifies slot name

The <slot> element can use the 'name' attribute to specify a slot name. When no 'name' is specified, it will render the default slot. Additional attributes passed to the slot element will be passed as slot props to the scoped slot defined in the parent.

<slot> element is replaced by matched content

The <slot> element itself will be replaced by its matched slot content. <slot> elements in Vue templates are compiled into JavaScript and should not be confused with native <slot> elements.

<template> as placeholder for directives

<template> tag is used as a placeholder when you want to use a built-in directive without rendering an element in the DOM.

<template> special handling conditions

Special handling for <template> is only triggered if it is used with one of these directives: v-if, v-else-if, v-else, v-for, or v-slot. If none of those directives are present, it will be rendered as a native <template> element instead.

<template> with v-for can have key attribute

A <template> with a v-for directive can also have a 'key' attribute. All other attributes and directives will be discarded, as they aren't meaningful without a corresponding element.

SFC top-level <template> tag is separate

Single-file components use a top-level <template> tag to wrap the entire template. This usage is separate from the use of <template> as a placeholder. The top-level tag is not part of the template itself and doesn't support template syntax such as directives.

SFC file structure: three top-level blocks

A Vue Single-File Component (SFC) uses the *.vue file extension. Each *.vue file consists of three types of top-level language blocks: <template>, <script>, and <style>. Additional custom blocks can also be included optionally.

Template block constraints

Each *.vue file can contain at most one top-level <template> block. The contents are extracted and passed to @vue/compiler-dom, pre-compiled into JavaScript render functions, and attached to the exported component as its render option.

Script block constraints

Each *.vue file can contain at most one <script> block, excluding <script setup>. The script is executed as an ES Module. The default export should be a Vue component options object, either as a plain object or as the return value of defineComponent.

Script setup block constraints

Each *.vue file can contain at most one <script setup> block, excluding normal <script>. The script is pre-processed and used as the component's setup() function, which means it will be executed for each instance of the component. Top-level bindings in <script setup> are automatically exposed to the template.

Style block configuration

A single *.vue file can contain multiple <style> tags. A <style> tag can have scoped or module attributes to help encapsulate the styles to the current component. Multiple <style> tags with different encapsulation modes can be mixed in the same component.

Automatic component name inference

An SFC automatically infers the component's name from its filename in the following cases: dev warning formatting, DevTools inspection, and recursive self-reference. For example, a file named FooBar.vue can refer to itself as <FooBar/> in its template. This has lower priority than explicitly registered/imported components.

Pre-processor lang attribute

Blocks can declare pre-processor languages using the lang attribute. The lang attribute can be applied to any block. For example, <script lang="ts"> uses TypeScript, <style lang="scss"> uses Sass, and <template lang="pug"> uses Pug. Integration with various pre-processors may differ by toolchain.

src attribute for external file imports

Language blocks can use the src attribute to import an external file. For example: <template src="./template.html"></template>, <style src="./style.css"></style>, <script src="./script.js"></script>. The src attribute also works with custom blocks. Path resolution follows webpack module request rules: relative paths need to start with ./, and you can import resources from npm dependencies.

src imports from npm packages

The src attribute can reference assets inside node modules and npm packages. For example, <style src="todomvc-app-css/index.css" /> imports a file from the installed "todomvc-app-css" npm package. When using aliases in src, do not start with ~; anything after ~ is interpreted as a module request.

Comment syntax in SFC blocks

Inside each block, use the comment syntax of the language being used (HTML, CSS, JavaScript, Pug, etc.). For top-level comments, use HTML comment syntax: <!-- comment contents here -->

Recommended top-level element order in SFC

The conventional order for top-level blocks in an SFC is: <template>, <script> (or <script setup>), then <style>. Custom blocks can follow after the standard blocks.

Give your agent this brain