Channels
#compose
Title
s
seb
01/15/2020, 2:14 PMa
Adam Powell
01/15/2020, 2:21 PMMight 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 PMOh, 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 PMseems 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👍 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
@Previewthe 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 PMI 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 PMit'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
@Previewor 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 PMI 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 PMI 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.Buttonand now I'm debating with the material compose team that I want to kill the
ButtonStyle👆 2
👍 1
s
seb
01/15/2020, 3:26 PMI 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 PMClara 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
WidgetList<Widget>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")
}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 PMYeah 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 PMglad 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 PMbeen too busy working with Swing 😱
I hate Swing. Please port Compose to the JVM.
😄 2
LOL