1. The first code snippet doesn't apply any backgr...
# compose
s
1. The first code snippet doesn't apply any background color at all .However, when I switch to the second code snippet, the background is applied correctly! Is it a bug or something that I don't know about?
k
The first one accesses the theme before you set it, so it gets the default colors instead of the ones you want
💯 2
🙈 1
s
Oh hey! I never thought about that. Now it makes sense to me! Will it work if I define modifier variable inside lamba body of Theme composable?
yes black 2
And is it a good practice to do so because I really hate second code snippet because it looks ugly to me!
lol 2
s
Be very careful with storing modifiers in variables and applying them later, it's very easy to mistakenly use them multiple times (which is bad) or get weird bugs (which can be worse)
s
Is it fine I'm taking care it's only used as intended? Like if I create a val backrgoundContainerModifier and only applied it to intended background container?
s
I'm sure you're being careful, I'm just saying — you can get silly bugs even if you're very careful because of subtleties
s
Hey! I'll definitely be more careful from now on about this practice. Actually the only reason I do that is I don't want my parameter list look messy and keep my code clean! All though I'll definitely be careful when doing such.
s
I understand :) it can get a bit unruly. I'd feel bad about not warning about the risks, though, especially since it's such a recent memory for me
s
BTW I also don't like always padding padding while calling from parent composable is it a good practice to apply padding inside child component?
I totally feel your pain—I spent a good 20 to 30 minutes trying to figure out why the backgroundColor wasn’t being applied either!
s
One of the risks of putting modifiers in a variable 😄
s
yes i realized it so i'll be more careful and try to avoid this
s
is it a good practice to apply padding inside child component
I would say if it's "internal" padding to the component itself it's fine, if it's something you do to e.g., align with other things in the parent, I'd argue it should be in the parent
But that has little impact on functionality — unless you're then trying to reuse the component elsewhere
s
How about resuing the same button with different width but same size?
s
Width is part of the size, so not sure what you mean
s
I mean padding
s
Again, it depends on the "meaning" of that padding 🙂
There isn't a hard rule
s
Oh got it
s
My rule of thumb is that modifiers that relate to how the component is laid out (e.g., fillmaxwidth, or an additional padding for alignment or spacing) then I prefer it being set in the parent
But it's just personal preference as it makes most sense to me this way
s
Yes I understand! BTW thank you so much
🙌 1
Now I won't find myself storing modifiers in variables that much.
b
I think you are not using your theme correctly. You should be referencing from MaterialTheme which makes me think the setup is not correct.
s
Hey Brill! I've created my own implementation of Theme. I'm not using MaterialTheme!
👍 1
b
I'm sure you have a reason, but I'm curious why you would add all that extra maintenance? Anyway, the second one is working because the theme now knows its in dark mode, if your component is outside your theme, the colours would not get switched. When you set up the modifier outside your theme, it picks the default colour for the background. When you do it inside your theme, the theme switches the colour in that token to the correct one. This is working as expected from what I can see about how you set it up.
s
Hey actually it's a small project and I wanted to experiment around how can I implement my own design system instead of using Material 3. And yes I realized my mistake that I was trying to access the default value of backgroundColor which was set to Unspecified in my ComposeAppColorScheme theme class (idk how to explain but..)
And now all works fine because I'm using backgroundColor after applying my custom theme
1