Посоветуйте по архитектуре? Внутри компонента есть 2 компонента-списка, каждому из которых

передается информация откуда (из апи) брать для себя данные. Наружу каждый выдает выбранный итем списка.
Мне надо их связать, что бы список N2 фильтровался в зависимости от того, что выбрано в списке N1.

У меня несколько вариантов где это делать и как их связывать, я не уверенна, как лучше.

Затруднение в том, что о привязке знает только список N2 (получает среди данных по апи). Контейнер и тем более N1 - не знают

Чем выше уровень, тем лучше.

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

+

Почему не должен? Я немного упростила формулировку, это именно компонент со списком и сопутствующей ему логикой. Их много, они однотипные, передавать им обработанные данные из компонента-контейнера - неудобно.

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

Есть самый глобальный объект - само приложение. Остальное просто дети в дереве. Если реализовать логику (которая, к слову, изначально закладывалась в Vue) единого диспетчера, управляющего всеми детьми и данными, то достаточно просто дёргать в одном компоненте подписку на другой

Сложно спорить, мне правда кажется, что в концепции вью сделано все возможное для изоляции между несмежными поколениями. Т.е. родитель-ребенок непосредственно, и больше никаких связей. (Связи есть, но системы "немножко костыль", типа шин, рефов, vuex)

Шито?)))

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

+

Потому что их там не 2, а X Контейнер формируется на основании схемы, получаемой по апи опять же, это поля таблицы в форме редактирования

можно поподробнее? интересные заявления

Как глобальный объект может взаимодействать с компонентом вложенным в компонент? Например.

через provide inject например

ну так делай не 2 запроса, а X запросов, есть Promise.all или allSettled для этих целей если списки взаимосвязаны и должны обмениваться своими данными в контейнере, то зачем изолировать эти данные от контейнера?

Просто подумай о том, что xml сделан в виде дерева от корневого элемента, тогда как сам JS при присвоении переменной объекта, не копирует его а делает указатель. Другими словами сам JS подсказывает тебе путь

vuex-cache?

Потому что это очень удобно. Это выпадающие списки селекторов. Да, можно впихнуть в контейнер, но выгода этого не очевидна.

как это не очевидна, если это решает твою проблему с фильтрацией?

Это есть, но картину не меняет

Фильтрация появилась позже.

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

Укатывать в объекты и протаскивать? Ну можно, но это вот прямо концептуально предусмотренные vue способ?

Vuex - тебе ж писали

Кек. Какой концептуальный путь? Если бы был концептуальный путь, то не было бы такой горы фреймворков)))

о vuex я сама и писала. Это очевидно.

Ну... Чего-то разработчики vue себе предстваляли, начиная его создавать.

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

Разработчик и может его JSX достал?)