что за реализации, например? может не элм тому вина

хоть аватар автора и не внушает доверия, но не вижу там лагов каких-то, да и какие тут в целом лаги могут быть в редакторе текста, если прямыми руками. Да и вы вроде не фотошоп собрались делать. Так что не видно, с чем очевидно элм тут мог бы помешать.

зачем гонять стейт туда-сюда?

Вот ещё я буду вспоминать, о чём беседа была неделю назад? Ох уж эти люди, которые отвечают на записи такой давности...

вопрос был о том, стоит ли делать какой-то там редактор (не совсем текста), и у Вас был аргумент, что жс интероп (например) все погубит

И?

Мой поинт: писать визивиг редактор смешанного контента на голом Elm — сложно и дорого. И медленно будет, или совсем дорого. А если брать "нативный", то нужен будет интероп и его будет много. Передавать полмегабайта данных в параметрах веб-компонента — сомнительное удовольствие. А значит будет жонглирование кусками через порт или стейт в ЖС

Кароч, если вам это всё кажется простым — дерзайте. Я — не буду

Я думаю, все зависит от задачи, которая не была тут описана по сути, если задача именно в написании логики этого редактора и он является основным (одним из) компонентом приложения, который надо постоянно докручивать, совершенствовать, то почему бы и нет

Вопрос в том, действительно ли вам нужен весь промежуточный стейт да ещё и разпарсеный на стороне элм... у нас в приложении есть модалка, которая даёт пользователю выбрать его камеру, микрофон, аудио оутпут, посмотреть превью всего этого добра. Изначально сделали её на элме с портами, получилось отвратительно, все криво косо. Пришлось переделать... и сделали так:
Элм передаёт в вэб компонент какие-то начальные атрибуты, там есть видео вообще или нет... и все... дальше пользователь крутит вертит переключает флажки настраивает проверяет и все это элм нисколько не волнует... и только когда мы уже готовы и жмём сабмит кнопку, Стэйт летит на элм

Довольно неплохо работает

Но это получается целый большой модуль на тс, если бы этот модуль был основой приложения, то элм возможно был бы вообще не нужен

> получилось отвратительно, все криво косо.  а что конкретно было криво, косо? и почему на тс все ок?

в чем ограничение портов получилось?

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

Порты совершенно не годятся если у нас есть многоступенчатое взаимодействие

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

В тайпскрипт такой проблемы нет потому что в тайпскрипт нет проблем с интероп

т.е. проблема была в организации логики синхронизации действий через порты, а не в технических ограничениях портов, ну там накладные расходы их?