а вот это что за магия

MyFastAdapterDiffUtil[adapter.itemAdapter] = items
MyFastAdapterDiffUtil[adapter.itemAdapter] = result

@alaershov
По поводу странности ресайкла — ну по логике не странно, если:
1) зашли на фрагмент со списком — он пуст и в презентере лист пукнтов пуст
2) загрузили — items презентера заполнились, diff посчитался — ресайкл обновился на его основе. Мы дернули  ещё раз кш(или бэк) и получили снова items — но они такие же оказались. result посчитался, мы всё передали ресайклу — но т.к. ничего по пунктам не изменилось — ресайкл не обновил ничего — тут всё логично!
3) далее мы сходили на фрагмент и обратно и Moxy повторно присылает во вью items + result — НО адаптер стал новый же при возвращении и он пуст, а items + result пришли в метод "старые" — items то есть, но вот result расчитан от того, что в ресайкле есть пункты эти и ничего обновлять в нём не надо.
это и происходит — ничего не появляется.

Я насколько это вижу, что вы себе сами усложнили жизнь, и теперь думаете, как бы запилить костыль) Если идти дефолтным путём, и оставить подсчёт диффа View, а из презентера передавать только актуальное состояние (текущий список элементов), то такой проблемы бы вообще не возникло.

это вот отсюда операторы:
https://github.com/mikepenz/FastAdapter/blob/develop/library-extensions-diff/src/main/java/com/mikepenz/fastadapter/diff/FastAdapterDiffUtil.kt

НО в этом классе — подсчет diff result и добавление items слито в один метод. И если ты хочешь считать результат и добавлять items отдельно — то так не выйдет, потому я для тестов, сделал копию где разделил эти методы и назвал пока MyFastAdapterDiffUtil

можно закостылить и дифф резалт передавать отдельным методом View с другой стратегией.

согласен, но разве норм на основном потоке считать дифф? (я только из этих соображений, это всё затеял))

конечно, лучше на фоновом потоке считать

Есть даже для этого стандартная реализация, на основе которой ListAdapter сделан.

Можно туда заглянуть, и почитать, как гугл рекомендует считать дифф в фоне.

я вот об этой штуке

Спасибо за помощь, почитаю!

Удачи) Вообще уважающий себя адаптер должен поддерживать самостоятельный подсчёт диффа в фоне, чтобы вам об этом думать не приходилось. Может и фаст адаптер умеет как-то.

вот и я про это думал, но что-то у этой либы не нашел такого пока)

самое время посмотреть в сторону AdapterDelegates от Hannes Dorfman

Почему Composite не успевает проинициализироваться? onFirstViewAttach ведь вызвался уже

Caused by: kotlin.UninitializedPropertyAccessException: lateinit property compositeDisposable has not been initialized