The `BaseComponent` in itself basically is a lifecycleOwner, observes the parent's lifecycleowner (s...

# compose

[Joost Klitsie]

The BaseComponent in itself basically is a lifecycleOwner, observes the parent's lifecycleowner (so copies those and will call on_destroy when onDispose is called on itself) and creates the dependency graph (by extending the parent's dependency graph). Does anyone have any pointers here? 🙂

[Foso]

Hi, i tried Compose with react like Components https://github.com/Foso/ComposeReact

[Joost Klitsie]

@Foso I like the example 🙂 But in your case, is every time a new class instantiated? (Like on every pass through)

[Leland Richardson [G]]

what is the motivation here? Is there something you are trying to do but can’t?

Compose is embracing functions as the unit of abstraction. Classes don’t match the mental model quite as well (and they don’t for react either, btw, and react is moving away from classes as well)

[Leland Richardson [G]]

I’d like to understand what is pushing you in the direction of wanting this though, and if it’s just familiarity or something more fundamental

[Leland Richardson [G]]

managing the lifecycle of the class correctly is possible but it seems impossible to do and preserve a clean calling syntax or conventionally going for something in a companion object like in your example

[Joost Klitsie]

Well my problem is mostly: How should I structure my app? What architecture can I use? I didn't see any example thusfar, so if you can point me at something that'd be great. I see for example this article: https://medium.com/better-programming/create-a-component-based-architecture-in-android-jetpack-compose-96980c191351
Or the Jet News Application
But they do not provide any information how to structure an app. They only provide information for mainly 1 screen. There is no dependency injection happening. The app in the article only covers 1 screen, the Jet news is just passing on a bunch of repositories as arguments with the functions, that is not how I would structure a bigger app.

[Joost Klitsie]

@Leland Richardson [G] So how would you architect an actual app?

[Joost Klitsie]

written with compose

[Joost Klitsie]

do you know any resources for me to check out? 🙂

[Leland Richardson [G]]

we are working on more broadly focused resources/content that help answer a question like this, but i don’t think i can do so one-off in this slack thread, sorry 😕

is there a specific problem that you’re having (ie, you mention dependency injection?) that I can maybe provide a more specific answer for?

[Joost Klitsie]

Well lets say I have an app with a structure like this:

-Login
--Welcome
--Registration
--Username/Password
-MainOverview
--News Feed
---Article
----Comment
-Friends
--List
---Messaging
---Details
-User settings
--Name change
--Logout

Usually I would make my navgraphs resemble that, with nested graphs.
So I have the following: Every screen here is a fragment. I inject a ViewModel for every screen. The screens do not know anything about their position, only their parent component controls them. Basically any dependency injection will inherit from the parent component the dependencies and that is how we can inject things in every screen.

So how would I achieve an architecture in compose? I cannot just inject all the viewmodels into my single activity and then pass all of that as arguments down the composable graph. (or should I indeed do this? Expose the entire viewtree through 1 app state). Like if I turn them into classes that are components in themself, I can do injection per component, have 1 ViewModel per component etc. But how do I achieve a tidy architecture with compose if we do not have these components where we can inject things in between?

[Joost Klitsie]

Perhaps I should just rethink the way how I should architect an app 🙂 But I don't know where to start

[Leland Richardson [G]]

so it sounds like this is mostly a question around dependency injection

[Leland Richardson [G]]

is there a particular DI lib you are using?

[Joost Klitsie]

kodein

[Joost Klitsie]

Like my plan was to make a multiplatform POC app with react for JS and compose for Android, and kodein is multiplatform. I wanna see how much code I can actually reuse and still get a full native experience, and compose and react might help as they are (in a very loose sense 🙂 ) kinda similar (one day I also wanna add swift ui to the POC)

[Leland Richardson [G]]

sounds neat

[Leland Richardson [G]]

so give me a sec and i’ll provide an example for both contained and global

[Leland Richardson [G]]

ok so it took me a while to figure out what the names of these types are in kodein’s documentation

[Leland Richardson [G]]

there would be lots of ways to do this since there appear to be lots of ways to use Kodein

[Leland Richardson [G]]

this mimics the newInstance method of injecting with kodein

[Leland Richardson [G]]

https://gist.github.com/lelandrichardson/2e801abbb0f636992698129a9122a12b

[Leland Richardson [G]]

if you use kodein in a different way usually, let me know if it’s not clear how to create something equivalent for that approach

[Joost Klitsie]

Thank you very much, I'll have a look soon 🙂

[Joost Klitsie]

Okay I got it to run, indeed seems to solve my issue! I guess most important is the scoping of the binding, the remember doesn't seem to do a lot

[Joost Klitsie]

val ParentDI = ambientOf<DI> { DI {} }

val DI = ambientOf<DI> { DI {} }

@Composable
inline fun <reified T : Any> inject(): DIProperty<T> = DI.current.instance()

@Composable
fun myModule() = subDI(ParentDI.current) {
    bind() from singleton {
        Controller()
    }
}

val RootKodeinContext = DI {
    bind() from singleton {
        ParentController()
    }
}

class ParentController() {

    val state = MutableStateFlow(Random.nextInt())

}

class Controller() {

    val state = MutableStateFlow("I am magic")

    init {
        CoroutineScope(Dispatchers.Main).launch {
            while (true) {
                state.value = System.currentTimeMillis().toString().takeLast(4)
                delay(1000)
            }
        }
    }
}

// Provide a context at the root.... or anywhere in the tree you want
@Composable
fun App() {
    Providers(
        DI provides RootKodeinContext
    ) {
        Column {
            val parentController by inject<ParentController>()
            parentController.state.collectAsState().value.let {
                Text(text = it.toString())
            }
            Providers(ParentDI provides DI.current) {
                Child()
            }
        }

    }
}

@Composable
fun Child() {
    // constructs and remembers a Controller based on current kodein context
    Providers(
        DI provides myModule()
    ) {
        val parentController by inject<ParentController>()
        parentController.state.collectAsState().value.let {
            Text(text = it.toString())
        }
        val controller by inject<Controller>()
        controller.state.collectAsState().value.let {
            // use controller
            Text(it)
        }

    }
}

[Joost Klitsie]

It probably needs some finetuning 😅

[Joost Klitsie]

But I will figure it out 🙂 thanks @Leland Richardson [G]!

[Leland Richardson [G]]

no problem

[Leland Richardson [G]]

can you help me understand the goal of myModule() in your example?

[Joost Klitsie]

yeah so preferably the things are nested

[Joost Klitsie]

so I wanted to make a function to return a module that is a subDI of the parent

[Joost Klitsie]

the naming is off there as it is not a module

[Joost Klitsie]

it is a di container

[Joost Klitsie]

which is a sub container of the parent

[Joost Klitsie]

but I wanted to see how to build such a container, and I am guessing the ambient of the parentDI only lives in a composable function

[Joost Klitsie]

so therefore I used a function so I can make it a sub container of any given parent

[Joost Klitsie]

I think the original parent can be this: `

val ParentDI = ambientOf<DI> { (ContextAmbient.current.applicationContext as DIAware).di }

`

[Joost Klitsie]

and then all the other DI containers will be whatever child of how it is nested

[Leland Richardson [G]]

gotch

[Leland Richardson [G]]

you could make something like this

[Leland Richardson [G]]

@Composable
fun subContainer(
  bind: KodeinScope.() -> Unit,
  content: @Composable () -> Unit
) = Providers(
  ParentDI provides subDI(ParentDI.current, bind),
  content
)

[Leland Richardson [G]]

I don’t know the kodein library that well though… you might want to be careful if subDI produces a new object every time then it will recompose all of the composables that use inject

[Leland Richardson [G]]

you might want to implement a custom areEquivalent method in the ambientOf declaration

[Joost Klitsie]

Thanks for your help! Yes I will check if it actually recomposes (would a simple println in the right places show that? :) ) I also think I can simply use 1 di object that always extends and after that replaces the previous one, but I think that is also in your code snippet happening now :)

[Joost Klitsie]

Okay to me it looks like the Providers(...) is only called once. @Leland Richardson [G] do you know how or when that piece of code is called?

@Composable
fun subContainer(
    bind: DI.MainBuilder.() -> Unit,
    content: @Composable () -> Unit
) = Providers(
    DI provides subDI(DI.current, init = bind),
    children = content
)

If it is only called 1 time, I do not need to make a comparison with for example the context (because I'd have to maintain those myself but I'd rather not)

ambientOf<DI>({ old, new ->....

In theory (tm) the DI object is only build 1 time per "component" and shouldn't change during that component is alive. (so if I would remove and add a "component" from/to the graph then of course it gets reinitialized, but that is fine)
Then it'll look something like this:

val DI = ambientOf { DI {} }

@Composable
inline fun <reified T : Any> inject(): DIProperty<T> = DI.current.instance()

@Composable
fun composeSubDI(
    bind: DI.MainBuilder.() -> Unit,
    content: @Composable () -> Unit
) = Providers(
    DI provides subDI(DI.current, init = bind),
    children = content
)

// Provide a context at the root.... or anywhere in the tree you want
@Composable
fun App() {
    Providers(
        // Inherit from application
        DI provides subDI((ContextAmbient.current.applicationContext as DIAware).di) { // We could move out the contents of this somewhere else
            bind() from singleton {
                ParentController()
            }
        }
    ) {
        Column {
            val parentController by inject<ParentController>()
            parentController.state.collectAsState().value.let {
                Text(text = it.toString())
            }
            Child()
        }

    }
}

val myDIBuilder : DI.MainBuilder.() -> Unit =  {
    bind() from singleton {
        Controller("Some amazing text", false)
    }
}

@Composable
fun Child() { // <-- My amazing child component
    composeSubDI(bind = myDIBuilder) { // <-- should take care of its own DI stuff
        val controller by inject<Controller>()
        controller.state.collectAsState().value.let {
            Text(it)
        }
        SomeOtherChild()
    }
}

I think it is important to make it singletons (in kodein a singleton is only a singleton in the scope, not for the entire application) so it will just use the DI object to return the same instance all the time.
I didn't see the DI object changing during redrawing the text because of state changes, so I guess this would be doable for now like this.