Нет, накладные расходы в данном случае дело копеечное (ну кроме огромного количества кода), но в данном случае и Стэйт небольшой

Но с точки зрения кода порт это очень дорогое удовольствие... опиши порт, декодер, энкодер, типы на элм стороне, типы на тс стороне, субскрипшены, хэндлеры... и все так и норовит в лапшу превратиться

Это по сути система коллбэков... мы уже не помним какая это была боль...

ну понятно, тут как бы свой подход нужен, хочешь чистоты и безопасности - делай, не хочешь, делай как обычно )

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

На стороне элм это решается тасками, на стороне тс - промисами... а вот когда на границе это никак не решается

по идее таки вещи как раз функционально проще описать в итоге, чтобы было без багов

Именно... проще... но не в элм

порты же прячатся легко за тасками

один раз нужно реализовать логику

А если нужно получить информацию из жс, на основе этой информации сделать вывод, запросить экшн...

В общем несколько раунд трипов быстро превращаются в ад

Например нам нужен поток, но если мы запросим видео а у пользователя нет камеры - мы упадём

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

Если бы был нормальный интероп, проблем небыло, завернул бы все в таски, зачейнил

А с портами это беда выходит

Кстати а как вы предлагаете порты в таски заворачивать? Научите

что мешает запрос-ответ через порт завернуть в таск?

реализации есть какие-то