A
Короч суть видимо грамотно распарсить и повесить на ноду object.values... либо object.key = on:event, object.value = actionFunc()🤔
Size: a a a
2020 December 21
ON
Рест эвентов давно нужен, только отдельной переменной
а как от пропсов отличать? нужен другой синтаксис, какой?
A
on:events={...eventsObj} ?
Так логика сохраняется...
on:event={singleHandle}
on:events={...eventsObj}
Так логика сохраняется...
on:event={singleHandle}
on:events={...eventsObj}
ON
on:events={...eventsObj} ?
Так логика сохраняется...
on:event={singleHandle}
on:events={...eventsObj}
Так логика сохраняется...
on:event={singleHandle}
on:events={...eventsObj}
или
on={...eventsObj}A
или
on={...eventsObj}Суховато... имхо и как-то второстепенно и выбивается из ядерных модификаторов)))
A
Хотя экономия...
A
А в малине это есть уже?
ON
А в малине это есть уже?
нет, есть только проброс всех событий наверх
A
такой подход будет удобнее для связки событий на уровне блока <script>... и не нагромождать атрибутами ноды в шаблоне, а ещё зачем?
DK
В каких обстоятельствах такое может быть нужно? Только без теоретизирования.
Рест в ивенты нарушает инкапсуляцию компонента: ты извне решаешь, что компонент должен слушать, это же очень странно. А если не извне, то какой смысл в принципе, у тебя ж так и так есть перечисление, проще тогда уж просто перечислить
Есть такая штука в кругах пользователей фреймворков: они сталкиваются с нишевым кейсом и думают, что его непременно надо предусмотреть в фреймворке, несмотря на то, что при формальном описании эта штука вызывает очень много вопросов.
Рест в ивенты нарушает инкапсуляцию компонента: ты извне решаешь, что компонент должен слушать, это же очень странно. А если не извне, то какой смысл в принципе, у тебя ж так и так есть перечисление, проще тогда уж просто перечислить
on:.on:* как штука, которая просто форвардит/обрабатывает все поднятые ивенты от компонента — ровно такое же нарушение инкапсуляции. Обработка всех событий разом — это явно дичара какая-то, а подъём всех… ну, как сахар может и можно, но explicit is better than implicit же, безопаснее со всех точек зрения — перечислить все форвардимые ивенты. Мало ли какие ивенты в ребёнка добавятся, это ж абсолютно непредсказуемая вещь.Есть такая штука в кругах пользователей фреймворков: они сталкиваются с нишевым кейсом и думают, что его непременно надо предусмотреть в фреймворке, несмотря на то, что при формальном описании эта штука вызывает очень много вопросов.
A
Лучше меньше, да лучше... спасибо
К
а как от пропсов отличать? нужен другой синтаксис, какой?
нет, просто через спред пропсов не надо спредить эвенты по умолчанию. Нужно, думаю, сделать возможность чего-то вроде on:some-dom-event={$$events["specific-event"]}
A
нет, просто через спред пропсов не надо спредить эвенты по умолчанию. Нужно, думаю, сделать возможность чего-то вроде on:some-dom-event={$$events["specific-event"]}
На 1 дом евент много специфичных кастомных? Это точно use: кейс.
К
На 1 дом евент много специфичных кастомных? Это точно use: кейс.
не понял вопрос. Специфичный может быть только на компоненте
К
я имею в виду, что можно тупо {...$$events}
К
либо по одному вытаскивать
A
не понял вопрос. Специфичный может быть только на компоненте
Пытаюсь понять твою конструкцию. Растолкуешь?
A
я имею в виду, что можно тупо {...$$events}
А. А как их от пропсов тогда отделить? И будет общая дырка пропс/евентс...🤔
{ ...$$somethingWhatIWant }
{ ...$$somethingWhatIWant }
AS
В каких обстоятельствах такое может быть нужно? Только без теоретизирования.
Рест в ивенты нарушает инкапсуляцию компонента: ты извне решаешь, что компонент должен слушать, это же очень странно. А если не извне, то какой смысл в принципе, у тебя ж так и так есть перечисление, проще тогда уж просто перечислить
Есть такая штука в кругах пользователей фреймворков: они сталкиваются с нишевым кейсом и думают, что его непременно надо предусмотреть в фреймворке, несмотря на то, что при формальном описании эта штука вызывает очень много вопросов.
Рест в ивенты нарушает инкапсуляцию компонента: ты извне решаешь, что компонент должен слушать, это же очень странно. А если не извне, то какой смысл в принципе, у тебя ж так и так есть перечисление, проще тогда уж просто перечислить
on:.on:* как штука, которая просто форвардит/обрабатывает все поднятые ивенты от компонента — ровно такое же нарушение инкапсуляции. Обработка всех событий разом — это явно дичара какая-то, а подъём всех… ну, как сахар может и можно, но explicit is better than implicit же, безопаснее со всех точек зрения — перечислить все форвардимые ивенты. Мало ли какие ивенты в ребёнка добавятся, это ж абсолютно непредсказуемая вещь.Есть такая штука в кругах пользователей фреймворков: они сталкиваются с нишевым кейсом и думают, что его непременно надо предусмотреть в фреймворке, несмотря на то, что при формальном описании эта штука вызывает очень много вопросов.
Если on:* будет пробрамывать наверх только те события, для которых парент инстанса поставил слушателей, то это очень полезно и я не вижу особых проблем с инкапсуляцией
ON
я имею в виду, что можно тупо {...$$events}
если я передам click, как компоннет будет знать, - это пропс или евент?