В каких обстоятельствах такое может быть нужно? Только без теоретизирования. Рест

в ивенты нарушает инкапсуляцию компонента: ты извне решаешь, что компонент должен слушать, это же очень странно. А если не извне, то какой смысл в принципе, у тебя ж так и так есть перечисление, проще тогда уж просто перечислить on:.
on:* как штука, которая просто форвардит/обрабатывает все поднятые ивенты от компонента — ровно такое же нарушение инкапсуляции. Обработка всех событий разом — это явно дичара какая-то, а подъём всех… ну, как сахар может и можно, но explicit is better than implicit же, безопаснее со всех точек зрения — перечислить все форвардимые ивенты. Мало ли какие ивенты в ребёнка добавятся, это ж абсолютно непредсказуемая вещь.

Есть такая штука в кругах пользователей фреймворков: они сталкиваются с нишевым кейсом и думают, что его непременно надо предусмотреть в фреймворке, несмотря на то, что при формальном описании эта штука вызывает очень много вопросов.

Если on:* будет пробрамывать наверх только те события, для которых парент инстанса поставил слушателей, то это очень полезно и я не вижу особых проблем с инкапсуляцией

Типа в родителе явно прописаны on:event on:event на компоненте?

А обработчик, значит, на все ивенты повесить нельзя? Типа on:*={} не сделать, спец.синтаксис? А если парент сделает on:*? тащить в рантайм штуку, которая через всё дерево поднимает ивенты? а если там будет if/else, и в одном случае будет подписываться на один ивент, во втором — на два, а в третьем — поднимать всё наверх? На самом деле, тут еще много вопросов на стадии, как узнать, какие ивенты шлёт компонент. dispatch(nonDeterministic() + 'event') — удачи угадывать в компайл-тайме! :)

евенты навешиваются в момент инициализации инстанса компонента

1. Нет такого понятия обработка всех эвентов разом. Ты не можешь знать все эвенты их бесконечное множество. 2. Компонент сам решает даёт он слушать любой прокинутый на него эвент или нет. В этом нет никакого нарушения инкапсуляции потому что компонент легко может решить не давать слушать на себе любой или любой конкретный эвент дальше в твоих рассуждениях проснулся питонист способный оправдать любую вещь абстрактными мантрами о явном/неявном)

1. есть два кейса: on:* на дом-элементах. Он почти невозможен, потому что их много. Контекст, в котором я говорил про обработку всего — это про обработку ивентов компонента. Их не бесчисленное множество. И вон как меня поправил Алексей, оказывается, технически это сделать можно. 2. всё перемешалось. Этот пункт больше идёт к моему аргументу про то, почему рестить ивенты — это плохая идея. Как раз родитель передаст через пропсы массив ивентов, а ребёнок их повесит на дом. Вот и нарушение инкапсуляции. Да, я раньше питонил. Этот слоган мне настолько зашёл, что я его использую более менее ко всему своему коду. Кажется, слоган проверен временем оказался :) Это не абстрактные мантры, хотя и не чёткое руководство к действию.

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

Это какой? Пробежаться по on-свойствам ноды и навесить отдельные листенеры, лол? :)

> on:* на дом-элементах. Он почти невозможен, потому что их много их не много, их столько - сколько передали сверху

вот этот человек дело говорит

Синтаксис on:* — это же не только форвардинг, но и обработка событий. Вот будет on:*={callback} — что делать?

это проблемы конкретного предложения реализации

только форвардинг, on:*={callback} такого нет, и не нужно