MS
Поэтому я и решил без необходимости presenter из UIVC не вытаскивать. Но интерфейс класса строю так, чтобы при необходимости легко закрыть его протоколом и абстрагировать
Size: a a a
2016 November 23
СЦ
А у тебя I в V подключен напрямую?
ST
пасаны, вы тут такие все умные
ST
вставил 5 копеечек, разбавил обстановочку
MS
А у тебя I в V подключен напрямую?
получается что да. I к V обращается через интерфейс P, но V к I напрямую
MS
по крайней мере у меня пока не было необходимости сильно преобразовывать входные данные, чтобы переносить эту ответственность в P
СЦ
Странно, флоу данных получается довольно странный в модуле
СЦ
Это делается только ради того, что редко нужна цепочка V-P-I ? И можно сэкономить на P в ту сторону?
MS
типтого
MS
P выступал бы просто как прокси в моем случае
MS
т.е. по логике надо бы разделять конечно. но профита от этого на данный момент для меня нет
MS
в будущем возможно понадобится
MS
т.е. для меня главные преимущества такого разделения в том, что Router управляет переходами между экранами, так что каждый из них не знает про другой - это раз. и два - вместо интерактора и дата-сервиса можно легко подсунуть стабы
EE
Вот по поводу роутер управляет переходами. Ты как в него передаешь ссылку на текущий навконтроллер?
EE
Я пробовал два разных подходах, первый это при композиции какого либо маршрута я сохранял внутри роутера линк на контроллер и использовал его при композиции следующего перехода ( разумеется если Нав контроллер не менялся я и ссылку не обновлял)
EE
Во второй раз я его передавал с view
EE
Мне оба способа не понравились, но второй вообще фигня) как делают истинные джедаи?)
MS
Передавать явно боле корректно
MS
Но по идее, он даже не должен зависеть от текущего модуля