Да. Поэтому и спасибо им, что сделали этот сахар. Он хороший и полезный :)

Особенно учитывая, что onMount и onDestroy недоступны вне компонентов :)

Он может быть полезным и для компонента. В целом если уже есть bind:this то экшен можно собрать руками из этого и onMount, afterUpdate, onDestroy

Так что именно-то хочется делать? Кросс-компонентная коммуникация, типа вызова функции на детях?

да, например начальный подскролл вирутального списка к конкретному элементу или просто императивный скролл виртуального списка к конкретному элементу.

инициализация доп эвентов на документе при маунте компонента-ребенка, ну и соответственно снятие эвентов при анмаунте компонента-ребенка.

примерно те же кейсы как у экшена на дом элементе =)

Ну вот.
Тут просто и возникает такая проблема, что скорее всего введение экшенов (которые, еще раз, дают императивный и реактивный доступ к ДОМу по своей изначальной затее) для компонентов не сэкономит никакого кода, и всё это можно решать едва ли не меньшими запарами имея существующие инструменты. Подскролл решается пропсами и биндами. Императивный скролл — биндом на export let функцию, и вся реактивщина останется у вас в родительском компоненте, а не во внешнем экшене.
Ну и по понятным причинам оно не даст вам реюзабельности, потому что все компоненты разные.

Так что хз.

ну дом элемнты тоже в каком то смысле все разные, но реализуют некоторые общие интерфейсы типа эвент таргета =)

С утверждением что они не сэкономят кода я скорее не согласен

Ага, чего не скажешь о компонентах как раз.

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

например если ты сделаешь IFocusable { focus(): void } то под это и дом и любой компонент с реализованным методом фокуса подойдет

главное чтобы тайпчек работал конечно =)

Мне всё еще непонятно, чем это лучше, чем bind:focus={parentFocus} и вызов его по требованию.

ну экшены же апдейт вызывают на определеной фазе лайфсайкла, например после комита в дом или я не прав?

чтобы повторить именно ту фазу лайфсайкла тебе надо будет вручную прописать в соответствующий метод onMount, afterUpdate, onDestroy и еще мб детектить какой-то чендж.

а то ты вызовешь фокус а компонент в себе нативный инпут еще не замаунтил =)

Ещё непонятно почему нельзя ставить атрибут slot на компоненты. Приходится обёртками... Хотя зарезервировали и обещали сделать давно

Эт задача для ребёнка предоставлять метод, который корректно отработает ¯\_(ツ)_/¯  Например, назначать focus метод, когда дом есть, то есть по сигнатуре делать его опциональным. В родителе проверять на трушность, вызывать, когда есть. Итого: всё решается примерно настолько же просто, насколько с use:. А обучить людей, что экшены на компонентах императивно вызывают методы на компонентах в привязке к дом-lifecycle — это, уф, дичара какая-то. Я бы проголосовал против такой фичи, лол.

Я читал неоднократно, что свелт ругают за огромное количество способов кросс-компонентной коммуникации: где у реакта он только один, у свелта их, кажись, 8.
А вы еще 9 хотите, да еще и сделать его просто адски непонятным.

не проблема не в этом, проблема в том что ребенок маунтит инпут когда какой-то пропс true например.

Предположим ты поставил пропс true и тебе надо вызвать фокус. Как это сделать? Если ты вызовешь сразу, то комита в дом еще не было и метод focus не указывает ни на что.

У меня с слотами вообще беда. Я почему-то постоянно натыкаюсь на какие-то баги с ними. У меня лично заведено 3 (!) бага, и ни на один никто так и не ответил :(