In-template variable definition

[wspl]

Sometimes you will encounter such a situation:

<template>
  <div class="container">
    <p class="row">{{item && item.a && item.a.b && item.a.b.hello}}</p>
    <p class="row">{{item && item.a && item.a.b && item.a.b.world}}</p>
    <p class="row">{{item && item.a && item.a.b && item.a.b.goodbye}}</p>
  </div>
</template>

These code with the same logic need to be written many times.
I hope there is a way to define local variables in the template, then the above code can be abbreviated as:

<template>
  <div class="container">
    <var name="b" :value="item && item.a && item.a.b"></var>
    <p class="row">{{b && b.hello}}</p>
    <p class="row">{{b && b.world}}</p>
    <p class="row">{{b && b.goodbye}}</p>
  </div>
</template>

or

<template>
  <div class="container" v-var:b="item && item.a && item.a.b">
    <p class="row">{{b && b.hello}}</p>
    <p class="row">{{b && b.world}}</p>
    <p class="row">{{b && b.goodbye}}</p>
  </div>
</template>

Q: Why not computed?
A: The item in the above code may come from v-for, so computed is not a feasible solution.

[posva]

It was proposed in the past: vuejs/vue#7325
Currently you can achieve it with https://github.com/posva/vue-local-scope

[skyrpex]

Probably you already know, but if you use JSX you could do this:

export default {
    render() {
        const b = this.item && this.item.a && this.item.a.b;
        return (
            <div class="container">
                <p class="row">{b && b.hello}</p>
                <p class="row">{b && b.world}</p>
                <p class="row">{b && b.goodbye}</p>
            </div>
        )
    }
}

[afontcu]

Q: Why not computed?
A: The item in the above code may come from v-for, so computed is not a feasible solution.

You can also create a method that accepts a parameter, so you can use it in v-for loops.

[phiter]

The issue with methods is that they aren't cached, so a bit less performatic.

[LinusBorg]

Creating a local variable as proposed by OP would also not be cached.

I see, and a local variable could serve as an in-loop cache for method results where computed props can't be used.

[ReinisV]

Q: Why not computed?
A: The item in the above code may come from v-for, so computed is not a feasible solution.

Whenever I hear someone say that, I think "this is a perfect situation for creating a component for that item!". That would give you the ability to use simple computed getters that can be cached.

A component should always have exactly one reason to exist and one mission to execute. This parent components mission is not knowing how to render the child items.

[LinusBorg]

Well, component instantiations come at a price (memory-footprint & render performance), so sometimes it's better to render i list's items in the parent for that reason. There shuold be ways to keep these situations performant, an this RFC aims to address it.

[frehner]

Forgive my ignorance, I'm new to the vue community.

Could the above be done with optional chaining as well? e.g.

<template>
  <div class="container">
    <p class="row">{{ item?.a?.b?.hello }}</p>
    <p class="row">{{ item?.a?.b?.world }}</p>
    <p class="row">{{ item?.a?.b?.goodbye }}</p>
  </div>
</template>

it's stage 3 and has a babel plugin

[LinusBorg]

Not right now, as vue-es2015-template compiler doesn't aupport >es6 features

But that can be solved.

[michaeldrotar]

I was dealing with a similar concern recently in my work so wanted to add 2 cents...

(My day job is in Ember so I'll pseudo-code the concepts)

Generally I want to pass a data model to my components.. like pass a user to a component for showing the user's badge or pass a meeting to a component for showing when and where and who's attending that meeting... it's just simpler to do <my-component meeting=meeting> than to do <my-component name=meeting.name date=meeting.date whatever=meeting.whatever ...>

I've also recently come to appreciate that this allows me to flatten out deeply nested data and to add logic around data that's not directly suited to my use case. So I recently did something like this:

// Component receives `model`
name = model.model_name
date = computed(() => (model.date && date_from_format(model.date, 'YYYY-MM-DD')) || undefined)
instructions = computed(() => (model.location && model.location.meeting_instructions) || undefined)

The same can be done for lists... if I need to display a list of model.users, I originally considered passing them to a nested component as well, but sometimes that's overkill.

users = computed(() => {
  return model.users.map((user) => {
    const spouse = model.spouse || {};
    return {
      name: user.name,
      spouseName: spouse.name
    };
  });
});

Now the template can iterate users without fear of accessing a nested property that might not exist and my component js continues to uphold the contract that it's explicitly handling all the data that the template needs.

[cawa-93]

Will this make the code much less clear? In my opinion, if you have a large component, it will be difficult to understand what the variable is, where it comes from if it is not in the data of component.

Much simpler code that doesn't have any "magic" variables:

<template>
  <div class="container" v-if="item && item.a && item.a.b">
    <p class="row">{{item.a.b.hello}}</p>
    <p class="row">{{item.a.b.world}}</p>
    <p class="row">{{item.a.b.goodbye}}</p>
  </div>
</template>

[woothu]

Computed can also solve v-for performance problem, as items could be mapped to have additional keys for display purposes + you can use object destructuring.

Btw. most of times proper Item structurizing can solve this issue.

[chriswoodle]

I think I found some kind of way to accomplish in-template variables in vue 3. Here is an example where I create the "in-template variable" inside of a v-for. Basically declare an inline array and iterate over the single item.

<div v-for='item in items'>
    <div v-for="record of [cache.find(item.otherId).value]">
        <span v-if="record">{{ record.name }}</span>
    </div>
</div>

In this case cache.find(item.otherId) returns back a ref<{ name: string } | null>

I feel like it's its kinda hacky, and I'm not really sure the performance impact.