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

Debouncing state emissions #336

Open
TheKeeperOfPie opened this issue Nov 28, 2023 · 4 comments
Open

Debouncing state emissions #336

TheKeeperOfPie opened this issue Nov 28, 2023 · 4 comments
Labels
enhancement New feature or request PR welcome

Comments

@TheKeeperOfPie
Copy link

I'm trying to migrate

val data = snapshotFlow { buildFromState() }.debounce(1.seconds)
...
data.collectAsState(null)

to remove the view side default null value.

But there's no easy way to debounce in Molecule. I think the closest you can get would be

val debouncedFlow = snapshotFlow { buildFromState() }.debounce(1.seconds)
val state = scope.launchMolecule { 
    debouncedFlow.collectAsState(buildFromState()).value
}

but this moves from Compose (the actual state) -> Flow (snapshotFlow) -> Molecule -> Compose (collectAsState) -> Compose UI, which is very inefficient compared to reading the state directly inside Molecule. It also requires calling buildFromState() redundantly.

If there was a way to control/throttle the recomposition timing in Molecule, then I could try and make it only recompose every second or when the debounce concluded.

@jingibus
Copy link
Contributor

@Composable
fun <T> debounce(value: T, duration: Duration): T {
  // ????
}

This can't be implemented on a StateFlow, but it should be implementable in compose

@JakeWharton
Copy link
Collaborator

I think that perhaps we want to consider accepting a frame clock even when using immediate mode. This would allow you to use an at-most-once-a-second frame clock either directly, or with the immediate mode. It would apply the back pressure to the recomposition rather than allowing it to run unbounded simply to discard its results.

@jingibus
Copy link
Contributor

I think that perhaps we want to consider accepting a frame clock even when using immediate mode.

I would think this would be equivalent to using the frame clock directly. What advantage does this give us over providing some utility code to create frame clocks from Flow<Unit>, or something similar?

@JakeWharton
Copy link
Collaborator

I was thinking that there was some advantage to still using the immediate mode such as immediately running if the period had already expired, but you're right that's just clock implementation details.

@JakeWharton JakeWharton added enhancement New feature or request PR welcome labels Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request PR welcome
Projects
None yet
Development

No branches or pull requests

3 participants