Hi folks, I remember reading something about compo...
# compose
a
Hi folks, I remember reading something about composition local providers very sparingly in your compose code in this channel but I can't find it again. Is anyone aware of any downsides of relying too much on composition locals ?
j
They are hidden dependencies whose use offers no indication to calling code that it is a prerequisite for their presence in the composition.
You should really only use them for things which are effectively global (although the value can change locally in the tree) and always will be available
a
That refreshed my memory. I was indeed referring to Jim’s tweet on this subject. Trying to make people aware on PR’s that we should not be relying on them as much as we are right now. Helps to have a source to point to. Thank you the info as well Jake. I am trying to put across the point on hidden dependencies myself :)
c
You’ll see people reach for CompositionLocals when the number of arguments to a Composable function gets large and unwieldy, but it’s much better (and easier) to wrap the args into a single object that gets explicitly passed through the tree, rather than using the implicit Locals
d
Yeah, when I saw that
Context
was a CompositionLocal I sighed. I was hoping to get away from
Context
and Android specific stuff in Jetpack Compose. Like, pragmatically I understand why they are there though.
j
Context is a great example of a good CompositionLocal candidate since it's always available at the integration point at which the composition is created (for Compose UI)
If you don't like it you simply don't use it, but it's an essential type when you're running on Android for better or worse
d
This is the unfortunate truth lol
m
I've made some use of them, but i've deliberately restricted my use to things like ui defaults, theming and logging. And in both cases, all the things in the composition local have a reasonable fallback in case the higher levels of the composition fail to provide one.
The most complex use i've made of them is to provide defaults for things like our custom button so that it can have reasonable settings in different content slots on a page. This lets the caller just do something like this:
Copy code
CLButton(...) { Text(...) }
instead of
Copy code
CLButton(variant=CLButtonVariant.Fill, ...) { Text(...) }
when we provide them a content slot where there the convention is a fill button. It's akin to something like LocalTextStyle and LocalContentColor