Есть какой-нибудь паттерн или просто best practice для организации кода

компонента, который может содержать в себе разные дочерние компоненты принимаемые извне?

вероятно, ты про слоты

В том числе. Но я скорее о более сложных случаях когда переданный дочерний компонент влияет на поведение родительского.

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

как будто наоборот, советуют избегать провайд\иньект. Особенно в случаях, когда нужен общий контекст. Чем вам пропс / эмитс не нравятся?)

Каким образом тогда представляется реализация компонента ParentComponent который в слот принимает какой-то неизвестный компонент реализующий определенный интерфейс?

кто советует и чем это объясняется?) пропсы и эмиты не подойдут, если нужно передавать данные один раз в родителя, а дочерний компонент должен от них зависеть банальный пример: родитель - <Select>, дочерний компонент - <Option>, данные передаются только в родителя, но опциям они тоже нужны для определенной логики

Через provide/inject

родитель провайдит какой-то контекст (данные), дочерний компонент его инжектит и работает с ним

А обратно? defineExpose?

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

родитель провайдит метод, потомок вызывает

👍

просто prop типа function?

не проп, провайд

Понял, спасибо.

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

люди в интернете много чего советуют, но это не всегда верно и объективно) компоненты, которые используют inject, жестко связаны со своим родителем и не могут работать без него, поэтому это нужно учитывать перед тем, как использовать provide/inject в остальном это те же самые пропсы, только на неопределенную вложенность, иногда это оправданно и удобно, если применяется по назначению >Но объясняется это тем, что потом в случае чего хрен разберешься где и кто меняет данные просто не нужно провайдить сырые данные, которые сможет менять кто угодно, обычно принято провайдить либо просто readonly-данные, либо методы, которые их будут менять в родителе, тогда никакой проблемы нет >ну а для общей логики советуют компосаблы они решают другую проблему и почти никак не связаны с provide/inject композаблы позволяют просто переиспользовать кусок логики, а provide/inject - расшарить одни и те же данные между компонентами

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

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

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