Слишком мало информации конкретно по коду, пока могу предположить что пропс который изменяется мутируется на внутреннем уровне и рендеринг отсекается через scu
Сергей Соколов: Индекс как ключ это антипаттерн, нужно использовать значение которое характеризует объект а не его позицию в массиве, что произойдет если порядок элементов изменится, а при этом каждый ребенок имеет состояние?
denisftw: Я скажу что компонент должен уметь рендерить два состояния нет ничего из необходимого и все загружено, то есть задача переключить мысль на то что ничего необходимых данных может не быть. Про пустые состояния часто забывают а они не отемлимая часть приложения
copal: В общем виде все данные которые необходимы для корректного вычисления поступают через аргументы, так как часть из них может быть постоянной то функция карируется, то есть преобразовывается к цепочке функций которые возвращают функции одного аргумента, то есть для того что бы сменить имя нужно создать новую функцию и уведомить всех кому она необходима что нужно использовать теперь новую функцию.
В классическом виде вычисления с фиксированной точкой имеют много накладных расходов, поэтому делаются некоторые упрощения, что например состояние где-то хранится, но при этом обновление его происходит созданием нового объекта с измененными значениями. Итого и волки сыты и овцы целы
copal: В примере который вы привели вы описали чистую функцию, которая идентично тому поведению которое было обозначено, но если у нас есть объект у которого есть setName getName нет гарантии, что вызывая getName мы будем получать одно и то же имя ведь кто-то мог вызвать setName. В подходе cqrs этого быть просто не может так как нет внутреннего состояния, а все данные иммутабельны
copal: У меня возникло одно очень странное дежа вю.
Что же такое архитектура по вашему представлению?
И в чем же по вашему заключается функциональный подход?
copal: Во-первых, это действительно не mvc, это cqrs https://ru.wikipedia.org/wiki/CQRS . У mvc есть как минимум одна боль которая присуща всем приложениям, это зависимость от внешнего состояния, и в общем случае непредсказуемость изменения состояния, плюс сложные зависимости по обновлениям порождают каскадные обновления.
В сущности, так как реакт работает как стейт машина, mvc на него ложится с натягом, а собственно флакс с его однонаправленным потоком данных отлично вписывается в концепцию state -> view
copal: Жаль что я оказался не прав предположив, что вы адекватный человек, более слушать беспочвенные обвинения и сомнения я не собираюсь.
Вы ошибаетесь и на счет моего опыта и и прочего, я ушел с чистого mvc на бэкбоне, ввиду сложностей с поддержкой этих монстров и поиском зависимостей, и очень легким способом выстрелить себе в ногу и получить каскадные обновления
copal: событие пушнется в стек по historyApi его поймает, тот самый плагин, после этого роутер определит какой набор компонентов соотвествует этому адресу, запустит процесс рендеринга.
copal: mvc не единственный способ организации архитектуры приложения, популярный, но далеко не самый удобный. Рекомендую посмотреть на Flux архитектуру, и посмотреть повнимательнее нежели просто на то, какие аргументы получает конструктор.
copal: Про мидлы в редакс, да такая же система, это способ расширения поведения стора необходимым функционалом например работа с сервером или localStorage.
Относительно роутера все нет так печально как кажется с первого взгляда, а именно:
1. приложение на реакте это иерархия компонентов, следовательно нет компонентов нет вообще ничего, поэтому для организации иерархии представлений существуют Route, которые описываются в приложении
2. Под капотом роутер подписывается на изменения состояния history и управляет отображаемыми компонентами.
То есть имеем декларативно объявили что у нас вообще может рендерится а там все разрулится уже из пожелания контроллера.
Относительно mvc не стоит искать четких параллелей так как в реакте все несколько иначе
copal: Для роутинга в большинстве случаев хватает react-router`a при этом биндинги под редакс у него тоже есть, есть конечно граничные моменты для приложений энтерпрайз уровня, но они все решаемые
