Vue3: Using v-for with keep-alive - vue.js

My Problem
I have a variable number of Tab components; there can be 1 or 10, but only one is going to be displayed at a time. However, I want to cache them between switches. I thought I could put a v-for loop inside a <keep-alive> but according to the docs: https://v3.vuejs.org/api/built-in-components.html#keep-alive:
Note, <keep-alive> is designed for the case where it has one direct child component that is being toggled. It does not work if you have v-for inside it. When there are multiple conditional children, as above, <keep-alive> requires that only one child is rendered at a time.
Question
This seems like a pretty standard use-case, so I'm wondering if there's an easier way about this that I'm missing. Is there a best practice to rendering a variable number of components inside the <keep-alive> component?
Update: Kind of an answer
I was able to separate the Tab logic from the v-for, which means the Tabs get generated elsewhere, while the TabContent is the only thing inside <keep-alive>. Kind of like so:
<keep-alive>
<TabContent tab-name="name" />
</keep-alive>
Then internally, TabContent uses the tab-name prop to grab the data it needs.
Admittedly it feels like a good solution but I'm open to other ways to solve this.
Update 2.0: For Dynamic Components, use :key
The last thing I figured out; my Tab titles are dependent on filenames, and the TabContent is generated from the file, so it takes a filename props. My content was dynamic.
You still can't use a v-for inside the <keep-alive>, but you can use keys still:
<keep-alive>
<template>
<component
:is="'TabContent'"
:key="currentTabTitle"
v-bind="{
filename: currentTabTitle
}"
/>
</template>
</keep-alive>

Take a look at Dynamic Components with keep-alive
<div id="dynamic-component-demo" class="demo">
<button
v-for="tab in tabs"
:key="tab"
:class="['tab-button', { active: currentTab === tab }]"
#click="currentTab = tab"
>
{{ tab }}
</button>
<!-- Inactive components will be cached! -->
<keep-alive>
<component :is="currentTabComponent"> </component>
</keep-alive>
</div>

Related

VueJS 2 - Re-useable parent component that can accept different children

I have a parent component, SearchComponent:
<template>
<div>
<div class="relative pl-8 pr-10 rounded bg-white border focus-within:bg-white focus-within:ring-1">
<input v-focus #keyup.escape="clearSearch" #keyup="doSearch" v-model="searchTerm"
class="w-full ml-4 h-12 pl-1 text-gray-700 text-lg rounded-full border-0 bg-transparent focus:outline-none placeholder-gray-400"
placeholder="Search..." autocomplete="off">
</div>
<ul class="bg-white mt-4">
<quick-search-item v-for="item in searchResults" :key="item.id" :item-data="item.itemData">
</quick-search-item>
</ul>
</div>
</template>
This is responsible for receiving user input and getting results from an ajax call, handling errors etc. and generating the result list.
What I'd like to do is to make this generic so that instead of having a quick-search-item child component I can pass in different types of child component (like car-search-item, person-search-item etc.) depending on the context of where the user is in the app and what they're searching for
I've read a number of tutorials and I couldn't find quite what I'm trying to do. This may mean I'm approaching this in the wrong way - but if anyone could point me in the right direction, or has a better approach, I'd be very grateful.
Thanks,
Lenny.
I would try to make use of the <slot> element. Check out the documentation here
<parent-component>
<slot></slot>
</parent-component>
Hope this can put you on the right path.
Schalk Pretorius was quite right: slots are the answer to this, specifically scoped slots. I found the Vue docs a little confusing as it refers to getting data from the child component and I wanted to do it the other way around, so as an aide memoire for myself and to help anyone else here's what I did:
In my parent component I defined the slot like this:
<slot name="results" v-bind:items="searchResults">
</slot>
The v-bind binds searchResults (a data item in the parent component) to the value 'items'. 'items' then becomes available in the slot.
In my child component I have a simple property setup called items:
props: {
items: {type: Array},
},
Then to hook it all together in my Blade file I did this:
<search-component endpoint="{{ route('quick_search.index') }}">
<template v-slot:results="props">
<food-results :items="props.items">
</food-results>
</template>
</search-component>
This creates the search-component. Inside that -as I'm using named slots - we need a template and use v-slot to tell it which slot to use (results), then the ="props" exposes all the properties we've defined on that slot (in this case just one, 'items').
Inside the template we put our child component and then we can bind items to props.items which will be the searchResults in our parent component.
I'm happy to have this working and I can now create lots of different results components while reusing the search component - and at least I learnt something today!
Cheers,
Lenny.

How to properly create a popup component in Vue 3

As part of becoming a better Vue programmer, I am trying to implement a popup similar to Popper with a clean and Vueish architecture. Here is a simple schematic that I came up with:
So basically there is a target component, which is the reference for the popup's position. The popup can be positioned above, below, right and left of the target, therefore I will need to have access to the target element in my popup. Also, the target can be an arbitrary component. It can be a simple button or span, but also something much more complex.
Then there is the popup itself, which will be put into a modal at the end of the body, It contains the actual content. The content again can be an arbitrary component.
I have a working implementation of the popup, but the basic structure seems to be far from perfect. I am using two slots, one for the target element and one for the content.
Here is what I have come up with so far for the template:
<template>
<div ref="targetContainer">
<slot name="target"></slot>
</div>
<teleport to="body">
<div v-show="show" class="modal" ref="modal">
<div ref="popover" class="popover" :style="{top: popoverTop + 'px', left: popoverLeft + 'px'}">
<slot name="content"></slot>
</div>
</div>
</teleport>
</template>
There are several issues with this that I am not really happy with.
Using the popup is not very simple
When using this popup in another component, two <template> tags are rquired. This is ungly and not very intuitive. A very simple use case looks like this:
<modal :show="showPopup" #close="showPopup=false">
<template v-slot:target>
<button #click="showPopup=true"></button>
</template>
<template v-slot:content>
<div>Hello World!</div>
</template>
</modal>
The target is wrapped in another <div>
This is done to get access to the target element, that I need for the layout. In mounted() I am referencing the target element like this:
let targetElement = this.$refs.targetContainer.children[0];
Is this really the best way to do this? I would like to get rid of the wrapping <div> element, which just asks for unintended side effects.
The best solution would be to get rid of one slot and somehow reference the target element in another way because I only need its layout information, it does not have to be rendered inside the popover component.
Can someone point me in the right direction?
Here is my solution, which was inspired by a comment on my question and which I think is worth sharing.
Instead of putting the target element into a slot, I am now passing its ref as a prop, which makes things much cleaner.
The popover component's template now looks like this.
<template>
<teleport to="body">
<div v-show="show" class="modal" ref="modal">
<div ref="popover" class="popover" :style="{top: popoverTop + 'px', left: popoverLeft + 'px'}">
<slot ref="content"></slot>
</div>
</div>
</teleport>
</template>
I has a targetRefprop, so the component can be simply used like this:
<div ref="myTargetElement" #click="isPopupVisible=true">
</div>
<modal :show="isPopupVisible" #close="isPopupVisible=false" targetRef="myTargetElement">
<!-- popup content goes here -->
</modal>
And after mounting I can access the target element like this:
let targetElement = this.$parent.$refs[this.targetRef];
I like this solution a lot. However, ideas, advice or words of caution are still highly welcome.

Passing slots through from Parent to Child Components

I have built a user-defined component (async-select) on top of another component (vue mutliselect) like this:
https://jsfiddle.net/2x7n4rL6/4/
Since the original vue-multiselect component offers a couple of slots, I don't want to loose the chance to use them. So my goal is to make these slots available from inside my custom component. In other words, I want to something like this:
https://jsfiddle.net/2x7n4rL6/3/
But that code oes not work.
However, if I add the slot to the child component itself, it works just fine (which you can see from the fact that options become red-colored).
https://jsfiddle.net/2x7n4rL6/1/
After surfing the web, I have come across this article, but it does not seem to work
Is there any way in VueJS to accomplish this ?
Slots can be confusing!
First, you need a template element to define the slot content:
<async-select :value="value" :options="options">
<template v-slot:option-tmpl="{ props }">
<div class="ui grid">
<div style="color: red">{{ props.option.name }}</div>
</div>
</template>
</async-select>
Then, in the parent component, you need a slot element. That slot element itself can be inside of another template element, so its contents can be put in a slot of its own parent.
<multiselect
label="name"
ref="multiselect"
v-model="localValue"
placeholder="My component"
:options="options"
:multiple="false"
:taggable="false">
<template slot="option" slot-scope="props">
<slot name="option-tmpl" :props="props"></slot>
</template>
</multiselect>
Working Fiddle: https://jsfiddle.net/thebluenile/ph0s1jda/

is special attribute vs v-if / v-show

is special attribute is:
<!-- Component changes when currentTabComponent changes -->
<component v-bind:is="currentTabComponent"></component>
conditional rendering is:
<div v-if="type === 'A'">
A
</div>
<div v-else-if="type === 'B'">
B
</div>
<div v-else-if="type === 'C'">
C
</div>
<div v-else>
Not A/B/C
</div>
I know the different between using v-if and v-show, but I don't know the difference between using a list of v-ifs for different cases vs using the is special attribute. When should I use them?
Does is work like v-if or v-show? I mean, does it render all the components anyways? Is is like a syntactic sugar for a list of subsequent v-ifs?
is would be useful if the list of v-ifs would all render a component if true.
Like so:
<template v-if="component == "firstComponent">
<first-component></first-component>
<template v-else-if="component == "secondComponent">
<second-component></second-component>
</template>
<template v-else-if="component == "thirdComponent">
<third-component></third-component>
</template>
This can then be reduced to:
<component :is="component"></component>
Concerning your second question
Wether component :is works like v-if or v-show depends on wether you wrap it in <keep-alive> or not. Read the documentation on this here. Note though, that using <component> a component only gets created until it is necessary the first time, wether you use <keep-alive> or not.
So:
v-if (re)creates the component everytime the condition is met.
<component :is="..."> creates the component everytime the condition is met (like v-if).
<keep-alive><component :is="..."></keep-alive> creates the
component at most 1 time (but possibly 0).
A component with only v-show on it is created exactly once.

events and self referencing components vue.js

I have commenting system which allows 1 level thread. Meaning 1st level comment will look like
{
...content,
thread: []
}
where thread may have more comments in it. I though this is good for self-referencing component and List with Slots.
But after a while I do not know how to wire this thing up.
SingleComment component is given below
<template>
... *content*
<b-button
v-if="isCommentDeletable"
#click="handleDelete"
</b-button>
<div v-for="item in item.thread" :key="item._id">
<SingleComment class="ml-3"
:item="item"
/>
</div>
</template>
...
methods: {
handleDelete () {
this.$emit('remove')
},
}
...
components: {
'NewComment': NewComment, 'SingleComment': this
},
name: 'SingleComment'
}
</script>
List component classic list is recieving array of items as prop and is given by
<div v-for="item in items" ...
<slot
name="listitem"
:item="item"
/>
</div>
and this is the parent where I want to use these two components with modal
Parent
<AppModal
>
...
<List
class="my-1"
:items="comments.docs"
>
<template v-slot:listitem="{ item }">
<SingleComment
:item="item"
:remove="removeItem"
#remove="removeItem"
/>
</template>
</List>
I want to wire this thing up in Parent so I can use single modal for whole list.
Do I wire thins thing up with events? Or? Any sort of help is welcome. I am stuck. I can make some hacks but I really do not know how to deal with this self referencing components.
If you only have one level of nesting, you could simply pass the component itself as a slot, like so:
<Comment v-for="comment in comments" :key="comment.id" v-bind="comment">
<Comment v-for="thread in comment.thread" :key="thread.id" v-bind="thread" />
</Comment>
Then you will only have to worry about passing props one level deep, as if you only had a single list of comments. I created an example of this on CodeSandbox here: https://codesandbox.io/embed/vue-template-mq24e.
If you want to use a recursive approach, you'll just have to pass props and events around; there's no magic solution that steps around this. Update CodeSandbox example: https://codesandbox.io/embed/vue-template-doy66.
You could avoid explicitly passing the removeitem event listener down by having a removeitem action on your Vuex store that you map to your component.
My opinion here, is that simpler is better, and you don't need recursion for one level of nesting. Put yourself in the shoes of a future developer and make the code easy to read and reason about; that future developer may even be you when you haven't looked at the codebase in a few weeks.