Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some of the Composable DSL functions could be optimized #467

Open
Nek-12 opened this issue Jan 8, 2025 · 2 comments
Open

Some of the Composable DSL functions could be optimized #467

Nek-12 opened this issue Jan 8, 2025 · 2 comments

Comments

@Nek-12
Copy link

Nek-12 commented Jan 8, 2025

I was looking at the sources and realized there could be improvements made to the recompositions of DI functions.

  1. LocalDi should be made public to allow clients to provide the DI via a uniform syntax. When the localDi function is used, it is not marked as non-skippable, which leads to an additional nesting level in the tree. Instead, the LocalDi composition local should be made public so that clients can provide the DI more efficiently:
@Composable
internal fun ProvideDestinationLocals(
    component: DestinationComponent,
    content: @Composable () -> Unit
) = CompositionLocalProvider(
    LocalSubscriberLifecycle provides component.subLifecycle,
    LocalDestinationContext provides component,
    // LocalDi provides component.diContext // desired, avoids composition and object creation
) {
    // current - requires a nesting level in the tree
    OnDIContext(content = content, context = remember { diContext(component.context) })
}
  1. Some of the functions, such as OnDIContext(context: DIContext<*>, content: @Composable () -> Unit) create the DiContext in-place in the composition. This can lead to unnecessary allocations of contexts on every recomposition and heap pollution. We should avoid creating objects directly in composition and use remember with a lambda-driven DSL where possible.

  2. The functions that provide the DI context do not utilize rememberUpdatedState, which means once a lambda is captured inside the remember block, it will not change. If the user of the code has their lambda be recreated on recomposition, this will lead to issues as the With* functions from kodein that take lambdas will not pick up the updated lambda. This can only manifest if the lambdas capture parameters out of composition that can change. See docs for details

  3. DI value is not properly recreated when incoming params change. An optimized solution will make use of remember keys to properly re-create the di when the incoming parameters change. This is avoided by #3 and #2 but has to be kept in mind when those are addressed.

Would you like for me to take a stab at this feature in a PR?

@romainbsl
Copy link
Member

Improving / Enhancing / Fixing Compose is my next task on Kodein, but it is a side project, so not sure when. If you have some time and the whiling to contribute, be my guest :)

@Nek-12
Copy link
Author

Nek-12 commented Jan 9, 2025

Got it, I'll take a stab at it and let you know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants