https://kotlinlang.org logo
#compose
Title
# compose
m

Mark Murphy

04/21/2020, 9:16 PM
If at compile time all modifiers are valid for all composables (https://kotlinlang.slack.com/archives/CJLTWPH7S/p1587486859370700?thread_ts=1587486512.370000&cid=CJLTWPH7S)... will there be any sort of compile-time checking for validity here? Lint rules, perhaps?
l

Louis Pullen-Freilich [G]

04/21/2020, 9:22 PM
Possibly lint rules can help here, but there isn't really anything wrong with the example - you may want to have a left-aligned
Text
, horizontally aligned inside a
Card
for example - it's valid to express this, but it's just not always the accurate intention.
gravity
, like all modifiers, affects the element it is placed on, not children / the inside of that element
m

Mark Murphy

04/21/2020, 9:27 PM
there isn't really anything wrong with the example
For this example, yes. But I get the sense that it's not universal: all modifiers will not make sense for all composables. For example, does the
aspectRatio
modifier work on
Text
? I am just having flashbacks to having to answer an endless series of support questions like "why isn't
android:orientation
working on my
RelativeLayout
?". 🤪
l

Leland Richardson [G]

04/22/2020, 12:10 AM
IIUC, aspectRatio does work. it applies to anything that operates in the layout system, which Text does. The only modifiers where this isn’t really true are ones that only really “do” anything if there parent asks them for something, which is what we call
ParentDataModifiers
currently (not sure if that’s a public type or not
in general though, i agree with this being a potential problem, but as always, its a tradeoff with other complexity in the system overall and i’m not sure its worth it here
🆗 1
a

Adam Powell

04/22/2020, 5:36 AM
Things like gravity are exposed only in scope of the layout containers where they're valid on children, and those receiver scopes are `@DslMarker`ed so the leaking of
this
is pretty minimal in practice
👍 2
2 Views