I'm curious why is `LocalConfiguration.current` present in the Compose's `resources()`. Does it have...

# compose

[dimsuz]

I'm curious why is LocalConfiguration.current present in the Compose's resources(). Does it have the effect of recomposing when Configuration changes?

@Composable
@ReadOnlyComposable
private fun resources(): Resources {
    LocalConfiguration.current
    return LocalContext.current.resources
}

[sindrenm]

Yeah, I think it's to make sure it recomposes when LocalConfiguration.current changes. 👍

[Andrew Neal]

https://android-review.googlesource.com/c/platform/frameworks/support/+/1466806

[Andrew Neal]

Here's the CR for it, you can have a look at the conversation in the comments for more insight.

[dimsuz]

Great, thank you!

[Arjun Achatz]

Oh jeez.. this is gonna make reading compose code a bit more difficult 😅

[dimsuz]

Well, this seems more like an exception. Above linked PR contains some details on this particular instance.

[Zach Klippenstein (he/him) [MOD]]

Yea, this is a weird case because of the way the underlying state can change. resources can change out from under us whenever a config change happens, but the Context itself doesn’t change, so we have to explicitly observe the configuration object to know when the resources might have changed.

[Zach Klippenstein (he/him) [MOD]]

Oh jeez.. this is gonna make reading compose code a bit more difficult

It shouldn’t – this implementation detail is to ensure that callers of this resources() function are restarted whenever the resources might have changed, which is standard behavior for composable functions – they restart when state they consume is changed.