может предоставить меньше бойлерплейта. Больше - сколько угодно. MVP с долгоживущим презентером требуют как минимум задекларировать интерфейс view и иметь способ для сохранения состояния между пересозданиями вью» Да, все верно.
«иметь способ для сохранения состояния между пересозданиями вью» MVI на уровне идеи решает как-то этот вопрос? Если нет, то какое непосредственно это имеет конкретно к паттерну МВП? И если вопрос о реализации, то чем все же реализация МВП отличается от Mvi в конкретно данной ситуации? в MVI проблема с ЖЦ никуда не уходит сама по себе
"сорян, но это доказательство через утверждение какое-то. "я использую MVI только как презентационный паттерн и поэтому бизнес логику в него помещать нельзя»»
да ок. я вообще не увидел аргументов и четкого обьяснения того, что такое MVI , как и почему его можно назвать паттерном для модели.
Опять же было сказано «можно так сделать…» но почему так нужно делать сказано не было
> что такое MVI , как и почему его можно назвать паттерном для модели. Попробуйте пописать на Elm - тогда вы лучше поймете суть мотивацию появления однонаправленной архитектуры. Это будет полезно для выработки общего вокабуляра, иначе сложно объяснить в терминах и концепциях, которых кто-то не понимает. (и конечно полезно для общего развития).
Почему я так делаю - потому что это единственный способ писать UI приложения в функциональном стиле
Обсуждают сегодня