Breaking up templates in Vue3

[arpowers]

This is a follow up to a discussion in @yyx990803's workshop yesterday.

Specifically I wanted to register a vote for an ability to break up and organize template "chunks" along with reorganized functions/options in Vue 3's composition API.

Use case.. here is the code for the landing page you see at fiction.com

As you can see, the code is nearly 1000 lines long. The composition API will definitely help with this. However, the template alone clocks in at 150 lines. In this there are discrete areas of functionality like figures vs grids, etc..

The initial suggestion was to break things out into multiple components, however, this comes at a cognitive cost in jumping around to different files. As well as what you might call "file bloat"...

Im not sure of suggestions for the direct implementation details, however please consider its feasibility if you haven't already.

[ycmjason]

What ideas you have in mind? Is the goal of this to split template into multiple parts within the same file? If so, I think it is an interesting idea!

Would something like "named template" work?

<template>
  <use-template name="header" />
  <use-template name="main" />
  <use-template name="footer" />
</template>

<template name="header">
  <header>
    ...
  </header>
</template>


<template name="main">
  <header>
    ...
  </header>
</template>


<template name="footer">
  <header>
    ...
  </header>
</template>

Just throwing ideas. This is sort of replicating how you can assign virtual dom to variables in a render function; which could be quite useful if we figure a nice way to do it.

[JosephSilber]

I always wished for something like this 👍

The official answer for this has usually been to use additional components, but sometimes you want something lighter directly within the same file.

[chriscalo]

Building off of @ycmjason's proposal, what if each named <template name="Foo"> behaved just like a named component (<Foo/>) that you could just use in your main <template>? They could even be marked as functional components if you wanted to keep a clean separation.

This would be nice for situations where you'll never reuse these one-off components and you don't want the overhead of putting them in separate .vue files.

<template>
  <Header :user="user" />
  <Main />
  <Footer />
</template>

<template name="Header" functional>
  <header>
    <h1>Hello, {{ props.user }}!</h1>
  </header>
</template>

<template name="Main">
  <main>
    ...
  </main>
</template>

<template name="Footer">
  <footer>
    ...
  </footer>
</template>

[arpowers]

So a functional template would be reusable in other files?

The syntax idea sounds great to me.

[ycmjason]

I really like the idea of using functional component. However, Vue 3 is going to remove support for <template functional> (see here), so it doesn't look like to me that <template functional> adhere to Vue 3's philosophy much.

I think these named templates should be treated as "partials" that form the bigger part of <template>. An obvious way to do this is to make them inherit variables binding from wherever they are used.
But this approach reminds me of the old php days which makes me feel 🤢.

The following code example will make you 🤢

<template>
  <div v-for="i in 5"><use-template name="water" /></div>
</template>

<template name="water">
  <div>{{ i }}</div>
</template>

I am definitely more inclined to having named templates to have their own scoped and things passed in as "props". But we just need to find the right syntax to do this?

[Akryum]

You can have implicit (not declared) props in Vue 3, so you could totally pass props to template-only components.

[ycmjason]

@Akryum but would this mean that, if vue team decided to go down this route, that each named template would create a new instance of vue component?

[ycmjason]

But I think Vue 3 component will be very cheap to create if they are template only? Combining with @Akryum's suggestion on using implicit props, we might be able to do:

<template>
  <Header :user="user" />
  <Main />
  <Footer />
</template>

<template name="Header">
  <header>
    <h1>Hello, {{ $props.user }}!</h1>
  </header>
</template>

<template name="Main">
  <main>
    ...
  </main>
</template>

<template name="Footer">
  <footer>
    ...
  </footer>
</template>

[Akryum]

See #25

[chriscalo]

+1 to having to pass props to these private components. Probably best if they aren't magically passed props from the parent scope.

They could explicitly access parent to get at its data, props, methods, etc.

[arpowers]

I also wanted to add that since the whole point of this feature is better grouping stuff together in these huge components:

Not sure if it can get to something like this:

<template name="header">
  <header>
    ...
  </header>
</template>
<script>
function myHeaderStuffForCompositionAPI () {
  // ... 
}
</script>

[michaeldrotar]

What's the advantage of this over having separate components that are just a <template> section?

I don't understand the cognitive costs referenced in the description as I generally find smaller, focused files easier to mentally consume and understand... and this approach seems more like file bloat than separate components would since you're ending up with one large file.

When you're in your main template and you see <SomeTag ...> there's no indication if that's a component (under some-tag.vue) or a template name="some-tag" (or name="SomeTag") in the current file and if you have to scroll to somewhere else in your file to find it and understand it and then go back to where you left off in the same file to continue reading through the entire template -- this seems more painful than file switching and returning to exactly where you left off.

Explicitly passing props also makes this sound like separate components... or rather, it sounds like you want a way to define multiple, separate components in a single file?

[ycmjason]

@michaeldrotar

Sometimes the smaller parts of a large component does not make sense on its own. So it would be nice if those smaller parts could be local to the larger component. Regarding cognitive costs, it is down to personal preferences and ways of working. I don't think we are claiming superiority of named template over components in its own file.

I agree that <SomeTag ...> can be confusing of where it came from. It would be nice if we can distinguish between registered components and local components. Perhaps with some prefix? <$SomeTag ...>? (Again, just throwing ideas.)

[michaeldrotar]

Understood this approach would be optional, I'm just struggling to understand the use case -- to understand what problem it's solving.

The idea of simply separating one's layout pieces is not a very comprehensive use case... and if this is something where that's the only use case -- something most projects basically do once and rarely revisit -- then this is creating alot of work for something that's very narrowly focused.

Maybe better use cases would better illustrate the concern?

I can think of two times where I've personally considered something somewhat related to this idea:

Complex Components
Consider something like a material card -- it may be useful to have simpler patterns of two-way communication between the parent mdc-card component and its child mdc-card/actions, mdc-card/action-button, etc children. I think implicit prop access might be a strong point here, and it'd provide a reason for why mdc-card/whichever-child can't be used on its own: because it has to share state with its parent.

Complex Loops
I've ran into scenarios where I'm iterating some items in the template and the data model doesn't provide exactly what I need so I need some computed stuff... these are definitely cases where creating a separate component feels like overkill if I just need one computed and if it's something that's not reused anywhere else (and then I'm splitting my styles across files when they really aren't designed to be used independently). Alternatively I could create a computed that transforms the entire data set to one that's "view-ready", but this can also be alot of work with large sets and then I have trouble naming things... things and viewReadyThings..? Like.. urgh.

But that said...
Both of these scenarios are more of a sub-component then merely a sub-template use case so I don't know if these are way out of scope for what the author originally intended... and while it might be quick and dirty in the moment, having multiple template and script blocks seems like a decision I'd end up regretting at some point.

[IlCallo]

Angular ng-template and ngTemplateOutlet system is one of the few things I miss since I moved to Vue.
The Angular syntax for those is pretty verbose (as always), but I guess there are ways to make it simpler keeping the modularity and code tidyness they provide.
Vue large components would benefit for that kind of API, some proposals in this issue are somewhat pretty similar.
Of course, clear and complete documentation of how that feature work doesn't exists in Angular official documentation 💚
But here some links anyway to take inspiration.
Official docs
A random guide