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

Спасибо. Я кажется начинаю понимать

TEA работает, как голый реакт на функциях. События всплывают вверх, данные спускаются вниз. Только всё это защищено от грязных хаков самой платформой и типиками.

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

Таким образом в своих проектах вы можете использовать Cmd "не по назначению" или возвращать из update тройку с сообщением родителю. Но так как ни одно из подобных решений не универсально, ни одно решение не включено в архитектуру.

Кому неймётся, пилят свои поделки вроде tea-combine — не универсальные, но решающие небольшой круг задач более удобным способом.

А задача платформы здесь: не мешать делать надстройки, но не позволять прогибать мир под себя.

Проблема та же, что и в ООП: горизонтальные связи компонентов

Ну в ООП состояние локально. Если есть ссылка на объект, ему можно скомандовать измениться.

И это не то чтобы "проблема" в негативной коннотации. Это "задача". Которую можно решать грязно или чисто. Грязно решить проще, как правило. Поэтому нужно закрывать этот путь, чтобы можно было сделать только чисто :)

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

> иначе быть беде в элме
Именно в elm? В привычном подходе в frontend среде отсутсвие у некоторых компонентов/модулей своего состояния не всегда делает больно

> все состояние которая вьюха может иметь должно быть получено из аргументов и никак иначе
Конечно удобно, что по сути всё есть чистая функция, но «никак иначе» меня пугает

Нет никакого общего стора!!!

Есть состояние вьюхи. Это не модель вашего домена, это модель UI в первую очередь

То, что данные у вас могут храниться рядом с состоянием интерфейса, это всего лишь следствие.

Именно поэтому в Elm каждый введённый в инпут символ сохраняется в модели, там же хранится анимация вашего меню и вот это всё. Потому что model — единственный источник правды о том, в каком состоянии находится интерфейс.

Поэтому никаких "компонент" в общепринятом смысле быть не может — это противоречит концепции единственного источника правды

И мы не можем "не знать структуру формы, которую пользователь создаёт". Эта структура всегда будет отражена в модели.

Спасибо. Сложно.

Наоборот, это как раз просто.

Не "легко", но "просто"

Это сложно только в плане boilerplate 😁