Do you think overriding `LocalContentColor` in app...

# compose

[Steven Yang]

Do you think overriding LocalContentColor in app development is a good practice?

I know that Compose/Material3 is heavily using this, but because of its implicitness from CompositionLocal I don't think it's a good idea to overriding it a lot in app.

Just had a conversation with my college and I think except the global or high level (like a screen) theme, or there’s a clear need to change the existing theme in certain scope, we should avoid using it and instead explicitly specify the component’s properties to improve the readability of the app code.
What's your opinion?

[Stylianos Gakis]

It works well for theming. And by making it built-in to the Surface composable it all works out quite well. You never end up actually doing the override yourself, just give your Surface the right color and let it set the local itself.

[Zoltan Demant]

Usually when I feel the need to provide it through the compositionLocal myself, I probably need to take a step back and rethink what Im doing. It usually involves a surface in one way or another!

[Albert Chang]

It's useful when you create a common component with slot API pattern. It allows you to set a default style for the content in the lambda passed by the user so that the user don't need to set the style manually on every call site.