Ну что есть 🤷‍♀️… можно Шипилева посмотреть в др комнате

А с идеологической точки зрения почему нельзя “вешать Msg прям на onClick и тд”?
(это вроде бы и фактически невозможно)

… опечатался, я имел ввиду Cmd конечно, а не Msg

Т.к. модель - единственное место, где что-то может меняться, она и передаётся в subscriptions, когда изменения происходят.

Представим, что у нас есть таймер, который шлёт тики, но таймер - отключаемый. Состояние таймера будет в модели. Если таймер должен иметь изменяемый интервал, то интервал тоже будет в модели.

Опять же, у нас может быть "многостраничное" приложение, в котором не все страницы хотят получать тики от таймера -  исходя из currentPage в модели, мы решаем, продолжать подписку на тики, или приостановить, или начать снова.

Ещё пример - one-shot event, отложенный во времени. Раньше, во времена сигналов, можно было поиметь локальное состояние в сигнале через свёртку и таким образом получить таймер, который "срабатывает один раз".

Но проблема сигналов была в том, что сигнал нельзя было подавить, можно было только превратить Event () в Event Bool и в месте потребления сигнала игнорировать Falses. Та же ситуация с Subscriptions - состояния они иметь не могут, а если мы оное организуем через свёртку, то в каком-то виде каждое событие всё равно будет проталкиваться. В обоих случаях будет вызываться update (или его эквивалент в случае сигналов), и даже если модель не поменяется, view всё равно будет вызываться, строить новую - идентичную старой - версию DOM, потом будет производиться сравнение DOMов и вот это всё. Т.к. elm - энергичный, полностью избежать накладных расходов на обработку сообщений нельзя, поэтому от ненужных в данный момент подписок приходится избавляться.

Извиняюсь, только сейчас заметил, что вопрос изначально неправильно написал.
Вопрос был именно про использования на Cmd в onClick (вместо Msg), она же все равно “ленивая”.

Cmd имеет дргую семантику

Cmd Msg может сфейлиться, а просто Msg всегда удаётся

По смыслу Cmd Msg,  это отложенный эффект, тогда как Msg, это "чистое" сообщение, оно сразу попадает в update

Это да, я просто заметил что в update не пишу логики для всяких onClick,
а только создаю Cmd в обработке Msg  и просто возвращаю model.
Плюс напрягает создание лишних видов Msg

Типа как здесь (только много раз) http://elm-lang.org/examples/http

MorePlease ->
      (model, getRandomGif model.topic)

Cmd создаются в update "на потом" - они пачкой попадают в эффект менеджер и асинхронно выполняются за пределами пользовательского кода

Да я понимаю, меня “повторения” кода немножко утомляют

update, это единственное место, где происходит изменение модели. Эффекты могут возникать только в следсвте перехода модели в определённое состояние, т.е. опять же - в update. Другой вид эффектов - тех, что "возникают сами", это сабскрипшны. И т.к. оные возникают сами, они и не описываются в update

В данном случае нет никакого повторения. Есть чёткое разделение обязянностей

И как раз это разделение задизайнено довольно таки хорошо - настолько, насколько это было возможно в Elm сделать в принципе

И пропускать абсолютно все сообщения через update и описывать кучу сообщений на каждый чих, это правильный путь, ибо это и называется "системный подход"

в любом случае, ничего не мешает отдавать Cmd напрямую из view, если хочется

Можно, но событие всё равно придёт сначала в update, где потом нужно будет вытащить Cmd и вернуть в рантайм на обработку

Кароч, иметь onClick запускающий Cmd в обход update - плохо. Это неявное размазывание логики

type Msg = Cmd (Cmd Msg) | ...

[ onClick (Cmd (getRandomGif model.topic)) ]

Cmd cmd ->
  (model, cmd)

ага, так можно. Хоть и странно такого хотеть