Комментарии 6
Ну в целом код выглядит абсурдным. Естественно получать Стейт созданием нового флоу это полный бред. Для этого уже давно придумали паттерн с private mutable value "_", где такая проблема решается автоматически.
Да и в целом получим более чистый код, так как изменение стейта будет делаться через отдельный метод. На уровне этого метода ты можешь делать кучу другой логики, помимо переопределения своего метода сравнения.
Использование лямбды внутри стейта - очень спорный вариант. Из моей практики такое было лишь несколько раз, при этом это решало, например, архитектурные проблемы (навигации со шторками). Так что хочется узнать, на каком реальном примере в похожем контексте будет нужна лямбда.
Мало того что лямбда мало где нужна, твой код ещё и зачем-то постоянно её пересоздаёт. Это не имеет смысла. Да и к тому же можно было отфильтровать dataSource на предмет одинаковых значений, например через distinct. Тогда не будет дудоса с пересозданием лямбд.
Полностью с тобой согласен. Я тоже бы никогда не написал подобный код в приложении.
Но эта статья статья вдохновлена как раз именно таким багом который я недавно фиксил в новом проекте. Меня лично больше всего удивило то что вот такими неявными контрактами можно зациклить рекомпозицию. И самое интересное что экран будучи зациклинным вполне нормально себя вел и никак не выдавал потенциальные проблемы перфоманса.
Собственно в статье я хотел поделиться своим кейсом и рассказать что бывает и такое, а хорошие/правильныеПодходы/бестПрактис это уже другая тема.
Попробовал у себя запустить код и рекомпозиций не наблюдаю
Спасибо за статью. В data-class использовать лямбды, это некомильфо.
Публикации
О зацикливании рекомпозиции в Jetpack Compose