A modern programming language that makes developers happier.

kotlinlang

For apps that are fully Compose top-to-bottom, I wonder if there would really be that many advantages to this approach of wrapping your DI/SL library of choice in a Compose API vs just providing your dependencies directly via function parameters, lambdas/lexical scope, or using Ambients directly when necessary.

One of the best practices for Compose apps is that UI should be defined in terms of pure data and event callbacks and not have many heavy external dependencies in the first place, so I would maybe be concerned that if UI has a very complex dependency graph it probably isn't separated from business and other non-UI logic as cleanly as it should be. 

I could see this approach potentially being useful in a mixed codebase that is being migrated to compose, but even then I would think it would be cleaner to provide deps to the UI in a more Compose-idiomatic way at the boundary between legacy code and compose code.

I haven't built a huge app that is purely Compose so I could be wrong, but discussions about DI libraries and compose often seem a little to me like trying to figure out where to put the nails because we're used to using a hammer (or a dagger, as the case may be).