Как синтаксический сахар Kotlin может сломать вам логику работы приложения

[xlzpm]

Прочел статью. Понял, что все и в правду вошло в привычку, не представляю, как будут смотреть ребята pull request, когда я вместо object для перехода на другой экран, пропишу class, посмотрят как на чокнутого, но опять data object и предполагает под себя единый класс, который передает какой то state в effect

[kirich1409]

Возможно, ссылка на мой текст может послужить аргументом для использования. Моё видео про вред lateinit пошло в массы и я уже слышал: "Так не стоит делать, потому что в своём видео Кирилл запретил!" 😁

[jj_swp]

К чему это вообще? Синдром блогера (типо шарю)?

[Kudlayra]

Кирил вроде до санкций был подтвержденным Гугл экспертом.

Про lateinit действительно лучше не использовать без необходимости, спасибо за статью

[kirich1409]

К тому что моё мнение и советы для людей имеют вес

[Salt_Of_The_Flame]

"И вы точно не можете ошибаться! Никогда в жизни не ошибались! (и вот опять) "

[Lewigh]

В моём коде я описываю логику отправки события, которое каждое является уникальным и точно не подходит под описание "один экземпляр на всё приложение". Будь у моего класса хотя бы один параметр в primary конструкторе, то такого предупреждения от IDE с "полезным" советом я не получил.

Проблема не в IDE а в том что Вы нигде и никак кроме как в словей голове не обозначили что экземпляры данного класса должны быть уникальными и надеетесь на identityhashcode вместо того чтобы явно выделить это свойство класса. IDE в данном случае вполне права - либо делайте синглтоном либо явно прописывайте те свойство что сделают объекты этого класса уникальными.

[jj_swp]

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

Есть такие предложения, использования повсеместно дата классов и упование на магию R8.

[GarikCarrot]

Обратную совместимость можно починить через Companion object, если это необходимо

sealed interface UiEvent {
  data class ConfirmClicked(
    val id: String
  ) : UiEvent

  companion object {
    val ConfirmClicked = ConfirmClicked("default-id")
  }
}

[cpud47]

Так а в чём именно проблема-то?

События они же и есть данные - какая разница, будет ли приложение каждый раз создавать новый объект, или гонять туда-сюда один и тот же.
Если не использовать === то это должно быть ненаблюдаемо.
Вы же не пытаетесь сравнивать собития на равенство, да? (за исключением тестов).

Проблема с обратной совместимостью кажется надуманной: если у нас появились данные в событии - то разумно пробежаться по местам использования и предоставить там эти данные.

[AWE64]

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

[Viacheslav01]

Передумал

[McGars]

Согласен с тем что data класс/object генерит слишком много кода. И для обычного эвента ту мач. В связке Object или Class без uid с shared flow работает норм. Правда может быть дабл клик. Хотя, использование uid, как у автора, не спасет от дабл клика даже при использовании LiveData или StateFlow, так как от ui будет всегда приходить новый объект с новым uid. А если будет статичны uid то будет работать только с SharedFlow но дабл клик остаться.

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

Отсюда вопрос зачем тогда нужен random uid?

Думаю вполне можно использовать обычные классы или обьекты. Дата классы если прям реально используется сравнение где-то. Наподобии diffUtil или stateFlow.

Но в реальности data классы повсеместно по поводу и без везде используют и иногда со всеми и я. Хотя стараюсь думать сначала ))