Лучшее враг хорошего

Сомнительный аргумент)

Решение кривое, что будет если повторный бинд будет после дестроя вью?

Да как обычно будет, делегат-то новый, пустой

Привет! Хотелось бы подробнее узнать о правильном переиспользовании логики, которая привязана к ui-компонентам. Конкретный пример: имеется кастомная композитная вьюшка со своим стейтом и экшенами, которая используется на нескольких экранах. С точки зрения ui она вполне себе независима от остальных вьюх на лейауте, а с точки зрения presentation model ей всегда сопутствует какая-то одна и та же внутренняя логика по обработке связанных с ней экшенов и изменений состояния. Мне кажется естественным решение обернуть эту логику в отдельную pm и один раз написать binding-функцию, которая будет связывать эту pm с вьюшкой.  
Собственно, вопрос: правильно ли я понимаю, что именно для этой цели был написан метод attachToParent в PresentationModel?

В поиске по чату натыкался на упоминания child pm и о том, что это нетривиальная фича требующая разъяснений. Это как раз об этом?

Да, все правильно. Вам нужно вынести логику в отдельную чайлд пм и переиспользовать в других PM-ках для экранов.  attachToParent нужен для того чтобы привязать ЖЦ чайлд пм-ки к родительской пм-ке где она будет находиться. Можно использовать обычную композицию, а можно более элегантно использовать фичу котлина https://kotlinlang.org/docs/reference/delegation.html#implementation-by-delegation

Класс, спасибо :)
И есть один кейс, который хотелось бы обсудить. Есть форма, на которой компоненты могут добавляться динамически. Например, форма загрузки фотографий. Каждая загружаемая фотография имеет свою вьюшку с набором стейтов: загрузка с детерминированным прогрессбаром, саксесс-стейт, еррор-стейт, ну и экшен для отмены загрузки или открепления фотки. Пользователь может аттачить несколько фоток, причем пока он аттачит одну фотку, другая уже может улетать на сервер, давая об этом знать отображением актуального состояния процесса загрузки.

Так вот, допустим, что для отдельной вьюшки загрузки фотки уже есть своя pm, включающая управление ui-стейтом загрузки и даже общающаяся напрямую с model-слоем. Хорошей ли будет идеей создавать в родительской pm динамически список таких дочерних pm?

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

На ui список загружаемых фотографий реализован через RecyclerView. Соу, что хочется сделать в общем смысле: привязать к элементу списка свою pm, при том, что списком этих pm управляет родительская pm экрана.

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

Кейс с RecyclerView и ПМ-ками для каждого айтема не проработан, там много проблем с ЖЦ (он немного отличается от фрагментов), а также есть проблема переиспользования ПМ-ок. Если делать пм-ку на каждый айтем, то упадет производительность и увеличится потребление пямяти. Поэтому для большинства списков лучше не делать так. Но сама идея витает в воздухе, я пока не нашел хорошего готового решения. Для статических вьюх чайлды работают хорошо - проверено.

Я подумал, что можно было бы прикрепить жц дочерней pm-ки к биндам и анбиндам viewholder-а, о которых можно узнавать в адаптере. То есть сделать ViewHolder, реализующий PmView и разруливать биндинг на уровне адаптера. Но в подробности и проблемы возможной реализации не углублялся :[

А почему сильно упадет производительность? Ведь, насколько я понимаю, сама по себе pm очень легковесная.

при бинде вьюхолдеров рекомендуется убирать всю лишнюю работу с созданием объектов, чтобы уложиться в 16 ms

У родительской пм-ки экрана и пм-ки вьюхолдера разный ЖЦ, в этом и проблема

Хм, но ведь не нужно создавать новую пм-ку при бинде к вьюхолдеру. В родительской пм уже есть список созданных дочерних пм, некоторые из них находятся в binded состоянии, а некоторые в unbinded, и пока родительская пм жива, дочерние будут переключаться между двумя этими состояниями при скролле. Если честно, я не понял, почему это проблема :(

1) Сопоставить вьюхолдеры и чайлд пм-ки не так просто, как миниму нужно реализовать пул пм-ок ну и т д
2) ЖЦ вьхолдера отличается, нужно прокидывать отдельно атач и детач вьюхолдера, это все влечет за собой проблемы разсинхронизации жц с родительской пм-кой
3) Самое главное, то ради чего это делается - это инкапсуляция запросов и прогрессов для конкретного айтема. Но так как пм-ки переиспользуются, то нужно во-первых перепривязывать в пм-ку соответсвующий айтем согласно позиции и программировать так чтобы все стейты от текущего айтема менялись, во-вторых все равно нужно будет делать мапу в родительской пм-ке чтобы хранить статусы запросов и прогрессов для каждого айтема.
Отсюда вывод что легче сделать мапу запросов в родительской пм-ке и просто обновлять стейт в адаптере.

По третьему пункту я имел в виду, что можно пожертвовать ресайклингом для пм-ок, тогда каждая пм будет обслуживать всегда только свой стейт, и все пм будут храниться в списке аналогично тому, как мы в обычных ситуациях храним списочные данные. Именно сами данные, а не вьюшки. И можно жёстко связать пм с конкретным стейтом загрузки. Получается ситуация, когда одному экземпляру пм могут в разные моменты  времени соответствовать разные экземпляры вьюшек, которые визуализируют инкапсулированный стейт пм-ки.  Оверхед по памяти, конечно, будет побольше, чем с обычным подходом с мапой загрузок, но в ситуациях, когда мы не допустим сотен итемов в списке, почему бы и нет :Р

Короче говоря, реализация в виде 1:1 мапинга child pm к модели данных списка (процессам загрузки в данном случае), без ограниченного пула переиспользуемых пм и создания объектов при биндинге