Proposal: Multiple components in .vue files

What problem does this feature solve?

Other frontend frameworks, notably React, make it quick and easy to create many small components in a single file. This pattern promotes code reuse, component composition, and DRYness.

While Vue has this ability, it feels hacky and sacrifices much of the clarity and usability that .vue files provide.

This aim of this proposal is to define a clear and intuitive API for defining multiple components in a single .vue file.

What does the proposed API look like?

<component>

The <component> element is the building block of multi-component .vue files. Used as a top-level tag in .vue files, it’s effectively a self-contained “single-file component”, and it can contain anything that is valid in single-file components as they’re currently defined. A .vue file can contain any number of <component> elements. They are evaluated from top to bottom—no hoisting. The element accepts two properties that control its availability to other parts of the code:

• name (string, no default)

  The name of the variable that the component is assigned to. Components defined lower in the file can reference this component by its name. Additionally, if the component is exported (see below), this is the name under which it will be exported.

• export (boolean, default false)

  Whether or not the component is exported. If a component is exported, but doesn’t have a name, it will be the default export. More than one exported component without a name would create multiple default exports, and is therefore an error. All components must have either name or export or both.

By using the <component> element, individual .vue files gain a great deal more flexibility and power. They can compose a single exported component from many small child components, they can export many small components used throughout an application, they can export a main default component and less frequently used named components, and so on.

Examples

An isolated component (Foo) only used by another component in the same file:

<component name="Foo">...</component>
<component export>
    <script>export default { components: { Foo } };</script>
    <template><foo /></template>
</component>

Named and default exports:

<component export name="Foo">...</component>
<component export name="Bar">...</component>
<component export>...</component>

These would be imported in another file with import Baz, { Foo, Bar } from './Baz.vue';

An illegal file due to multiple default exports

<component export>...</component>
<component export>...</component>

An illegal file, because it combines the multi-component format and the single-component format

<component name="Foo">...</component>
<script>export default { components: { Foo } };</script>
<template><foo /></template>

Backwards compatibility

The addition of the <component> element would not be a breaking change—single-file components with no top-level <component> tags would continue to function exactly as they do today. As mentioned in the example above, combining the single-component format with the multi-component format is an error.

A potential point of conflict is the existing <component> tag than can be used in templates. I don’t foresee this being a problem, since the usage of <component> as a top-level tag in .vue files is well defined, but I can’t say for sure.

[cameronhimself]

@posva Thanks so much for your feedback 😄

Right now, this should be achievable in userland with a loader that transforms the components into inline components

Neat! That didn’t occur to me. I’ll look into it.

The only reason I would have a component created inside of an existing component in a vue file if it’s used only there. And in that scenario, I would rather use JSX to achieve it.

That is definitely the most common use case in libraries that allow multiple components per file, and I would foresee it being the same in Vue. However, there are other use cases; for example, you could have a single file that exports a bunch of small, common, presentational components, like SVG icons. Having dozens of tiny files in this scenario is, I would argue, less convenient than putting them all in a single file, and it makes for more verbose imports:

import Foo from './icons/Foo';
import Bar from './icons/Bar';

// vs.

import { Foo, Bar } from './icons';

This could be avoided by using an index file, but then you have to maintain it and remember to add additional icons to it, or add even more tooling to do it for you.

I disagree about using JSX, however—one of the reasons I like Vue is because I can get away from JSX, and using JSX alongside Vue’s template syntax seems needlessly inconsistent and hacky to me.

[sirlancelot]

Upon reading the title, I was initially against this proposal. However, after reading the description I think I can get behind this. The only thing I would change is that only ONE component can be exported. Other than that, I think this is a great idea to organize tightly coupled components or single-use components.

<template>
  <div>
    <comp-a />
  </div>
</template>

<script>
export default { /* ... */ }
</script>

<component name="comp-a">
  <template></template>
  <script></script>
</component>

Basically, for every <component> tag, add it to the components map of the main export. It also avoids JSX which is a bonus in my book.

Edit: Another benefit is that factoring out the nested component is a simple copy-paste since it follows the exact structure of a standard .vue file.