Есть создать общий стор пользователей, которые добавляются из разных компонентов,

имеющих свой инфинитискролл независимый и поиск, то норм будет каждый раз приписывать данные в стор и проверять их на уникальность по ид? а в компонентах уже гетером дополучать некоторые из сторы, а если не хватило то ещё подгружать?

а зачем тут стор вообще?

данные общие и на 1 странице, есть ли смысл грузить их 2 раза?

храни их в общем родителе и пропсами передавай в нужные компоненты стор - хранилище для всего приложения, а не для 1 страницы

вопрос тотже остался

в чем вопрос?

заменив стор на компонент родителя проблема не уйдет

почему она не уйдет?

общие данные для отображения, каждые нужно по отдельности фильтровать и прокручивать

так а проблема в чем? если тебе зачем-то нужно отображать на странице 2 независимых списка юзеров, то хранишь 2 переменные с данными, которые получил единожды каждый из них отдельно фильтруется и дополняется при скролле

хочется запихать эти 2 списка в одну переменную и из нее вычислять нужных

если тебе нужно 2 независимых состояния, как ты собираешься хранить их в одной переменной?

userList = [] computedUser() return userList

computedUser - это такая же отдельная переменная, которая вычисляет производное состояние и это подойдет только в том случае, если с сервера тянутся сразу все данные без нормальной пагинации

Ну вот а я хотел, чтобы из 2 разных компонентов данные подгружались в userList пагинацией, а дальше computed разруливал кому что отдать

если ты один раз проскролли все объекты, то локальный поиск в обоих компонентах бы покрывал потребности

а если не проскроллил, то как ты собираешься обрабатывать фильтрацию/сортировку? этот вариант бесполезный, если у тебя на руках нет сразу всех данных не нужно экономить на спичках, у тебя бэкенд не умрет от 1 лишнего запроса на 20 юзеров

в composables тогда наверное логику буду выносить

зачем ее выносить куда-то? это просто обычный компонент, который обрабатывает пагинацию по скроллу, тут не нужен ни стор, ни композабл 1 список - 1 инстанс компонента и 1 запрос на каждое действие (получение/фильтрация/сортировка/пагинация) ты можешь расшарить между ними начальное значение списка, если оно по какой-то причине одинаковое, но не более того

у меня тогда получается логика у таблицы и селекта одинаковая, в каждом из них нужно подгружать, а селект на многих страницах

так сделай это компонентом

таблица же отдельный компонент, а селект отдельно

какая у тебя логика между ними, которую ты хочешь расшарить в композабл?

подгрузка данных

а как она связана с селектом?

ну мне надо много где вставить селект пользователей, и для них поэтому отдельный компонент, который возвращает выбранного

это все еще не отвечает на вопрос, как связано получение данных и сам селект получение данные - одна задача, которая может зависеть от текущего выбранного значения в селекте, либо еще от чего-нибудь работа с селектом - другая задача опиши нормально связь между ними, потому что пока понятно только то, что у тебя есть какой-то селект и какая-то таблица с юзерами, а как именно они связаны и какая у них общая логика - непонятно