I have a few doubts :slightly_smiling_face:: - Is ...

# compose

[Ashu]

I have a few doubts 🙂:
• Is there any standard for storing colors/dimens/multi-language string resources in Compose?
• Is keeping these resources in XML still the standard practice or is it idiomatic to store these resources in Kotlin files in compose?
• If we are storing them in Kotlin files, what could be considered a clean way to support multiple themed colors or multiple language strings?
• Also, is there any benefit to keeping all dimens in a single place in compose?

[tad]

If you're Android-only, then the Android resource system is the most performant and easiest option for translated strings. Otherwise you can use anything you like; for our app, I wrote a thing to generate Kotlin code from a TOML file that picks a string based on the locale.

For colors and dimensions, Kotlin code is the ideal place to put them, because it doesn't make a whole lot of sense to change those based on Android resource configurations. MaterialTheme is a good example to follow; you could make your own analogous thing for common dimensions, or even just an Object with fields or Composable functions.

I would shy away from centralizing dimens in Compose, because dimens are very contextual in their usage. Usually you see a Composable UI element define a ThingDefaults object with some values that make sense, which are used as default values for the Composable function arguments. Button is an example that uses that pretty extensively.