Hundreds of Recompositions Despite No Changes

[santiwanti]

Hundreds of Recompositions Despite No Changes

[JakeWharton]

Can you provide a full sample that demonstrates the issue rather than just snippets?

From a quick glance, it looks like your recomposition is triggering an insert which is triggering a query update which is then triggering recomposition. If nothing was actually changing the StateFlow would not emit to Compose UI–so something is changing.

[santiwanti]

Here is the sample project https://github.com/santiwanti/SqlDelighTest.

A LaunchedEffect is used to insert a value, and then that value just blinks on screen for 15 seconds until the recompositions settle

[JakeWharton]

On second look (but not yet trying the sample), the problem is that you're returning a new instance from both properties on every call. Remove the get() on both to create a single instance of each.

The current behavior is such because when recomposition occurs from the insert, viewModel.users is invoked again which produces a new StateFlow. That StateFlow emits an emptyList and then the real query value comes in which triggers recomposition. Then the process starts all over. Frankly, I'm not sure why it would ever stop.

This can also be fixed by wrapping viewModel.users in a remember { } to save StateFlow instance across recompositions, but there's really no reason the two properties should be creating instances on each call so I would change them instead.

[santiwanti]

You are absolutely right, changing the code to val users: StateFlow<List<User>> = ... and val users: Flow<List<User>> = ... fixed the issue. I had always used it as get() and thought it was the same because I never noticed a difference. Thanks for pointing this out. I will have to checkout the differences