Size: a a a

2017 November 24

VC

Vasili Chyrvon in RxPM
Привет! Круто, что понравилось ;)
Да, юзаем коин. activity!!.getKoin().get<AnythingPm> ) либо можно StandAloneContext.koinContext.get<AnythingPm> ), но это не совсем по походу коина путь, там есть целый тред от меня в коине на эту тему. По итогу пришли к 1му варианту.
источник

VF

Va Fu in RxPM
судя по activity!!, Вы используете Conductor ? 🙂
источник

VC

Vasili Chyrvon in RxPM
Да
источник

VF

Va Fu in RxPM
хорошо, тогда еще такой вопрос. все PM, по идее, должны лежать в скоупе у своего Controller'a ?
источник

VC

Vasili Chyrvon in RxPM
Va Fu
хорошо, тогда еще такой вопрос. все PM, по идее, должны лежать в скоупе у своего Controller'a ?
Нет, для чего? Контроллеры переживают повороты и тп, и каждый раз ты в нем один раз создаешь пм. В коин модуле provideFactory { HomePm() }. Пока жив этот контроллер жив ПМ.
источник

VF

Va Fu in RxPM
provideFactory — не синглтон биндинг? я просто только с кодеина, пробую коин
источник

VC

Vasili Chyrvon in RxPM
provide - синглтон, а инстансы через provideFactory.
источник

VF

Va Fu in RxPM
тогда справедливо
спасибо, пойду ковырять дальше 🙂
источник

VC

Vasili Chyrvon in RxPM
👍
источник
2017 November 25

VF

Va Fu in RxPM
у меня созрел вопрос. вот у mvp есть несколько вариантов : Passive view, которая является набором функций типа setTitle, setImage и прочее, и есть supervising controller, в котором вью — setModel, и сама вью знает какие поля куда пихать. вот при данном подходе (PM), State — модель, или стоит делать много более мелких стейтов ?
источник

DG

Dmitriy Gorbunov in RxPM
Va Fu
у меня созрел вопрос. вот у mvp есть несколько вариантов : Passive view, которая является набором функций типа setTitle, setImage и прочее, и есть supervising controller, в котором вью — setModel, и сама вью знает какие поля куда пихать. вот при данном подходе (PM), State — модель, или стоит делать много более мелких стейтов ?
Хороший вопрос. Тут нужно определиться, является ли это независимым стейтом и скрывается ли за ним какая-либо ui логика. Например, если взять енитити типа Book,  у которой есть name, author, title. Следует ли в этом случае делать три стейта? Нет, конечно name, author, title тут свойства Book и когда мы обновляем текущий выбранный Book, мы отображаем свойства другого экземпляра. Тут очевидно что стейтом является выбранная книга, а за отображением ее деталей не скрывается динамическая ui логика. Модель не мутабельна.

Стейт - это как минимум то, что может изменяться.

Другой пример с книгой, допустим имеем экран заполнения информации о книге. И у нас есть отдельные поля ввода для редактирования свойств  Book.  А сам экземпляр Book мы создаём по кнопке "сохранить". В этом случае name, author, title будут состоянием экрана, то есть нужно три стейта.

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

VF

Va Fu in RxPM
это резонно. но, почему не сделать, например combineLatest и объединить все три поля в Book ?
источник

VF

Va Fu in RxPM
и все еще отдавать в PM целый book ?
источник

VF

Va Fu in RxPM
или вот такая штука, если у меня есть текст, например, прирост стоимости компании в процентах, и в юае у меня должна быть логика, что если прирост положительный, рисовать этот текст зеленым, если отрицательный — красным. кто должен проверять прирост, вью или PM должен отдавать какой-то стейт типа isRising, в зависимости от которого будет меняться цвет текста ?
источник

VF

Va Fu in RxPM
я понимаю, что это крайности, но поняв крайности, легче понять среднестатистический воркфлоу )
источник

DG

Dmitriy Gorbunov in RxPM
Va Fu
это резонно. но, почему не сделать, например combineLatest и объединить все три поля в Book ?
Это абстрактный пример, для того чтобы показать что за стейтом должна скрываться ui логика. Зачем создавать объект раньше времени? Данные в форме могут быть не валидны, например у книги обязательно должен быть автор и название
источник

DG

Dmitriy Gorbunov in RxPM
Va Fu
или вот такая штука, если у меня есть текст, например, прирост стоимости компании в процентах, и в юае у меня должна быть логика, что если прирост положительный, рисовать этот текст зеленым, если отрицательный — красным. кто должен проверять прирост, вью или PM должен отдавать какой-то стейт типа isRising, в зависимости от которого будет меняться цвет текста ?
isRising в данном случае свойство скорее енитити (бизнес логики). А то каким цветом отрисовывать этот флаг - это задача вью. Для пм тут нет логики
источник

VF

Va Fu in RxPM
тогда где хранится/выполняется вся бизнес-логика? (триггерится-то она, ясно где)
если у меня API возвращает Company без isRising, чья задача трансформировать модель для презентации ?
источник

VF

Va Fu in RxPM
какого-нибудь интерактора ? 🙂
источник

DG

Dmitriy Gorbunov in RxPM
Бизнес логика в слое модели: примирительно к чистой архитектуре - это интеракторы и ентити
источник