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

В том что с таким подходом реакт не нужен, берите бэкбон, джеквери или вью

С этим не спорю. Но вопрос остается, чем канал унутре хуже, чем канал снаружи, который будет перерисовывать компонент

Так я бы с радостью взял jquery, если бы на нем либы были по-человечески написаны. Я же реакт не ради реакта беру

Ну вот, а все потому что на джеквери в среднем в таком стиле и писали. А тут есть реакт, где UI = F(State), и вместо того чтобы простым и понятным способом оперировать со стейтом (если мы говорим про один компонент, если про целое приложение, то простой и понятный способ это redux) передавая аргументы в компонент (аргументы в функцию), прокидывается канал. В итоге непонятно зачем, пишется костыль, который при этом еще и сложнее выглядит

Ну канал выглядит гораздо проще, чем redux. Кстати, я понял, почему идея с перерисовкой не совсем то. Предположим, что у меня разлапистый стейт и мне надо поменять только одно поле. Если я пересоздаю через параметры, то каждый раз у меня стейт внутренний будет полностью генерирвоаться заново а не просто меняться. Собтсвенно то, о чем я говорю не нарушает идею UI = F(State), нарушается идея UI=F(G(Params)).

Мой вопрос остается. Есть ли проблема в том, что меняется стейтс мимо параметров?

> Ну канал выглядит гораздо проще, чем redux.

Канал нужно сравнивать с передачей аргумента в комнент, не с редаксом. С редаксом канал не сравнить, потому что редакс хранит состояние целого приложения, а не отвечает за изменение стейта одного компонента.

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

И это абсолютно не важно, т.к. у тебя реконсайл будет в обеих случаях. Цена одного компонента (объекта) ничтожна. Не факт что вся корутинная машинерия в JS тебе сейчас обходится дешевле. Делаю ставку что наоборот, что работает медленнее/тратит больше памяти

Есть, например если у тебя будет компонент в компоненте. Создание каналов, управление жизненным циклом

Так если я компонент создаю один раз, а потом просто внутрь сообщения передаю.

У меня там может быть какой-то сложный компонент. Я конечно не буду все это разворачивать ради кнопочки

А если у тебя чилды есть, в них уже все-все через пропсы передавать будешь?

Вас смущает что вы сначала поменяли стейт, а потом вызвали render?
Это нормально. Типичный observable. Все это одни и теже яйца.. observable, eventemitter. А redux - это паттерн.. там нет ничего кроме рекомендаций как писать свой собственный eventemitter.

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

Так а как чилды до стейта будут доступаться?

Вот мне тоже так показалось. Там не обсервер, там subscription на самом деле. Я просто не понял, почему у профессионалов это так напрягает

Ну как обычно в реакте, родителей спрашивать

ЧТО?

Ну а как стейт обычно прокидывается?

В реакте как и в compose родители прокидывают чилдам пропсы