Комментарии 5
К вопросу о сокращения в начале статьи и заголовка:
DI-компонент (Dependency Injection компонент) в этом контексте — это часть системы внедрения зависимостей (DI), которая отвечает за создание и управление объектами (зависимостями) в определённой области приложения.
Можно очевидный вопрос: почему не Hilt?
Похожую задачу (вроде бы) у себя со скоупами решает Koin, смотрел ли, как там сделано?
Hilt нам не подходит. Он привязывается к конкретной Activity или fragment. У нас ещё и compose экраны со своей навигацией, а также более сложные связи между зависимостями и нужна более ювелирная работа с графом зависимостей. Где-то нужно что бы di жил внутри нескольких экранов, где-то один di-компонент на экран, где-то di-компонент на сессию. Реализацию у Koin по жизненному циклу я смотрел. Там тоже идёт привязка к ViewModel. Сначала пытался у нас его переиспользовать, но там более мудрённое решение и поэтому сделал попроще. Сам Koin классный, ещё бы compile-проверку ему хотя бы на релизе, и было бы идеально. Это одна из причин, почему к нам в проект его не затаскиваем. Нам важна стабильность на этапе сборки. Когда я работал с pet-проектом, то первоначально делал на koin. Но у меня возникла проблема с тем, что нельзя было пробросить объект с параметрами через дочернего компонента к родителю, хотя функционал на это у него был. Просто не работало на тот момент.
Спасибо за статью!
В минусах бы еще указать, что параметры для компонентов никак не типизированы, следовательно возможны runtime падения, если ошибиться с параметром.
Возможно как "пластырь" для этой проблемы стоит рядом с компонентом класть функцию fun feature1Component(params: SomeParam): Feature1Component { return Store.component { params } }
Идея со глобальным стором и доступом к нему прикольная.
Dagger 2 и жизненный цикл