Речь о встроенном локатор сервисе, в композ, который очень удобно

использовать. Старики, может вы, просто, начнете, наконец, перестать ассоциировать компоуз с вью классик?

ну а как же clean ?

Это путь к клину, точно

Я не в коем случае не утверждаю, что Compose это только UI. И уж точно не призываю следовать Clean. Напротив, я обычно призываю ему не следовать. Но это другая история. Кроме того, я разделяю DI как подход, и DI-фреймворки как инструмент. И всегда выступаю против второго, но за первое. В рамках этой дискуссии, я утверждаю, что применять CompositionLocal для DI - плохо. По причинам, озвученным в документации: https://developer.android.com/jetpack/compose/compositionlocal А именно: 1. Зависимости передаются неявно. Нельзя понять, что нужно для работы конкретной функции и всего её поддерева глядя на её сигнатуру. 2. Нет безопасности во времени сборки - код компилируется даже если зависимость не предоставлена явно. 3. Зависимости доступны всем без исключения дочерним компонентам. Даже тем, которым они не нужны. Если зависимость нужна только в одном самом нижнем компоненте, то она доступна всему поддереву компонентов.

+++ поэтому мы пихаем только то что нужно буквально всему поддереву. Например аналитика

Первые две решаются тестами, которыми решаются эти же проблемы во многих других не статических DI-решениях. Третья довольно странная претензия. У тебя редко когда перекрывается доступ к данным, в лучшем случае нельзя прямо обратиться и взять. А если что-то нужно на определённом месте в поддереве, то ничто не мешает расположить эти данные прямо над этим поддеревом.

Отсутствие типов в JS тоже решается тестами. Однако сделали typescript. Чем раньше выявляется проблема, тем лучше. Кроме того я смотреть тесты, чтобы понять, какие local проставить - это на мой взгляд кошмар

Тут уже вылезает вкусовщина и удобство. >Кроме того я смотреть тесты, чтобы понять, какие local проставить - это на мой взгляд кошмар Зачем? Всё проще. Тесты тебе сообщат, если чего-то по дереву не хватает.

Я про свой пункт номер 1. Понимания необходимых зависимостей при взгляде на функцию. Например я когда надо её переиспользовать.

Понимаю. Не вижу в этом прям ужасной проблемы, но да, в некоторых ситуациях может быть неудобно.

Спорно, ведь можно создать скоуп-зависимоть над нужной функци,

Проблема с неявностью ещё в том что никто не знает все дерево целиком ) аппку пилит куча людей и они начнут кидать туда все подряд даже на всякий случай что в итоге рано или поздно приведёт к переопределению заданного поведения и как следствие магическому поведению программы

С тем же успехом кто-то заменит что-то в DI для своего удобства и это пропустят. Тут дело не в инструменте, а в человеческом факторе.

Действительно