https://kotlinlang.org logo
a

Adam Powell

01/15/2020, 2:21 PM
Might be vestigial, I'm not sure offhand. The person who would definitely know isn't in this slack, it seems 🙂
s

seb

01/15/2020, 2:42 PM
Oh, ok. It does look like it’s unused for now but not sure if planned to be later on… cause the alternative are tedious workarounds like I did here https://github.com/android/compose-samples/pull/46
a

Adam Powell

01/15/2020, 2:51 PM
seems a bit 6 of one and a half dozen of the other, tbh I prefer the "workaround" you used to annotation parameters, especially since annotation parameters are so limited in the types they can use
and the additional level of indentation can be solved by using the expression syntax for the outermost invocation of
themePreview
in those examples
👍 1
e.g.
Copy code
@Preview("Article screen")
@Composable
fun previewArticle() = themedPreview {
    ArticleScreen(post3.id)
}
since material themes are specific to the material design library it doesn't make a lot of sense for
@Preview
to have special knowledge of it, especially since I'm not even sure what extending that to support other parameterization that doesn't come from us would even look like
the way you've done it works first-class for everyone and doesn't involve adding any new concepts beyond composable functions themselves
s

seb

01/15/2020, 3:05 PM
I take that as I should be happy with my solution as someone that had been writing Compose for like two hours and be done with it 😄
I was actually wondered how preview theming could possibly work from the tooling side given theming is such a “vague” concept in Compose
a

Adam Powell

01/15/2020, 3:11 PM
it's definitely both more and less general-purpose. I know we've had some discussions about having the tools be able to supply plain old parameters to the composable functions you annotate with
@Preview
, which would allow for things like dropdown selection, etc. in the preview pane
or even just expression evaluation in cases where things are a bit more complex
words can't express how much better I feel about the way we're doing theming so far in compose vs. the android style xml system
👍🏻 1
👏🏻 2
s

seb

01/15/2020, 3:19 PM
I am so so happy that theming is completely different from the Android way 😄 Still need to play with it more to get a better understanding, but man does it feel better!
Flutter has done a very good job with theming it seems to me, and Compose’s following on a similar path, which makes me happy
a

Adam Powell

01/15/2020, 3:24 PM
I think one of the most significant things we learned from flutter was to stop worrying and love the duplicate widget sets in design libraries, which then suggests/enables this sort of theme model
👍 2
for years we held onto the idea of not having "forks" of
android.widget.Button
and now I'm debating with the material compose team that I want to kill the
ButtonStyle
object and just have different button composables 😄
👆 2
👍 1
s

seb

01/15/2020, 3:26 PM
I have to say, not related to styling, I am still trying to figure out if I prefer the modifiers way of Compose for some stuff, or the everything-is-a-widget way of Flutter. I can see pros and cons in both. Would be curious what the reason was for the choice
a

Adam Powell

01/15/2020, 3:47 PM
Clara and Anna-Chiara's kotlinconf talk went into some of it and it's still somewhat contentious on the team as well. It's a series of tradeoffs that involves the nature of composable functions and how much language extension is reasonable or possible to force the idea of exactly-one-layout-child composable functions. Add in the familiarity with LayoutParams for modifiers and treating them as universal LayoutParams as standard function parameters and I'm pretty happy with where we're at.
👍 1
Since Flutter is building a vdom of Widget objects there's the easy distinction of
Widget
vs.
List<Widget>
there. Since Compose uses the emit style that's not an option. We think the emit style is the right tradeoff since it permits a lot more natural control flow within what is otherwise a familiar kotlin DSL style
so then do we use something like contracts to say that for certain composable functions, it will always emit exactly one layout node to the tree, so that we don't end up in the situation of, "uh oh, this lambda I called emitted three things when I expected one, how do I lay them out?"
personally I think asking someone first learning hello world to understand something like that is kind of unreasonable, and just about every UI toolkit on the planet expects multi-child by default for containers, flutter is pretty unique in this, they leveraged an opportunity in their particular API shape
👍 1
so compose going down that road would mean that
Copy code
Padding(16.dp) {
  Text("one")
  Text("two")
}
would need to be defined in what it means, and every definition we tried confused some subset of the team or UX study participants. The modifier style is precise; you're passing a configuration parameter to a defined layout node.
So it's an additional concept, but it eliminates a class of confusing or nonsensical cases where an API designer would otherwise need to come up with an answer on the fly for what those edge cases mean, so I think it pulls its weight. It also does this while preserving the stability and well-defined meaning of what happens to your code when you refactor-extract method and reuse things at various levels of granularity.
If you compare to something like swiftui, it serves the same purpose as the fluent trailing wrappers there, but it brings it up to the top next to the noun of the container rather than the body block.
s

seb

01/15/2020, 3:58 PM
Yeah it definitely feels more natural. I suppose I need to get a bit better knowledge of how the layout composition actually happens wrt siblings and child widgets, but I do like a lot what y’all have done in Compose. It really didn’t take much for me to pick up the modifier idea, I just need to get the “sixth sense” on where to apply what to get what I want
I’m not familiar with SwiftUI, haven’t had time to look at it yet 😞
a

Adam Powell

01/15/2020, 3:59 PM
glad to hear it 🙂 we just landed a few API changes that I think should help with discoverability too.
👏 1
s

seb

01/15/2020, 3:59 PM
been too busy working with Swing 😱
I hate Swing. Please port Compose to the JVM.
😄 2
LOL