Combining batch-modification of very large collections, version-flag-based reactivity, and virtual scrolling

[macrogreg]

I have a question about using Vue reactivity in a performance-efficient manner. I'll briefly describe the problem context and how I plan to solve it, and I'd like to ask for the community's feedback on my implementation strategy. Hopefully, this is useful topic for others too. If there is a better location for this discussion, please let me know.

I am writing a Vue/Quasar app that needs to display a list of items that can be potentially very long. The list may be modified, and some modifications include multiple operations on the underlying collection (insertions, removals, and swaps). To avoid excessive reactivity updates from such batch updates, I plan to use a version flag to control reactivity as follows:

(Sorry for potential small errors in code fragments. I am typing right here without compiling. The intention should be clear anyway.)

In some module:

export interface MyItem {
    readonly id: number;
    // ...
}

export class MyContainer {

    readonly #items Array<MyItem > = [];
    readonly version = ref<number>(0);

    modify = (): void => {
        // ...
        // Perform multiple operations on items
        // (e.g., inserting, removing and swapping positions around).
        // ...
        this.version.value++;
    };

    getItems = (): ReadonlyArray<MyItem> => {
        return this.#items;
    };
}

const globalContainer = new MyContainer();  // singleton

export function useContainer(): MyContainer  {
    return globalContainer;
}

Then, in my Vue component:

<script setup lang="ts">

const container = useContainer();

const itemsToShow = computed( () => {

    // QUESTION: Is the following access enough to trigger this computed to update when the version changes,
    // or will the compiler optimize this away unless I use the value? If not enough, what would be an
    // appropriate "dummy" operation?
    container.version.value; 

    return container.getItems();
});
</script>

The goal here is that itemsToShow reports a change when, and only when the container changes the version.
So, all the changes in modify will result only in a single reactive signal. However, the result of the computed does not actually depend
on version. Will this still result in the desired effect?

<template>

<q-virtual-scroll
    :items="itemsToShow"
    v-slot="{ item }"
>
    <MyItemViewComponent :key="item.id" :data="item" />
</q-virtual-scroll>

</template>

Here, MyItemViewComponent is another Vue component capable of rendering whatever data is inside MyItem instances.

The goal of this template is to ensure that:

1. If nothing is scrolled, but the container version changes, itemsToShow should signal this reactively, so the scroll view should be updated. Does q-virtual-scroll react to this as intended? With this approach, I assume I do not need to call the QVirtualScroll.refresh method, is that correct? (Notably, the docs for q-virtual-scroll say that refresh is for adding items to the list, but my modifications may add, remove and move items around.)

2. If the virtual scroll is scrolled, it should know to render the appropriate components using its internal position tracking. Nothing explicit needs to be doen for that, right?

3. :key="item.id" in the div within the virtual scroll aims to ensure that items already rendered do not get re-rendered again. Will this work, or should I use another approach here?

4. If MyItem contains any reactive data and that data is appropriately consumed inside of MyItemViewComponent, then Vue will always update the corresponding render, despite the item.id-key staying the same. Is this correct?

So, generally, is this a reasonable strategy for this kind of situation?
If yes, are there any additional details I should consider?
If no, what alternative approaches can you recommend?

Thank you in advance for your feedback!