https://kotlinlang.org logo
Join Slack
Powered by
Ping? <https://kotlinlang.slack.com/archives/CJLTW...
# compose
s
a
Might be vestigial, I'm not sure offhand. The person who would definitely know isn't in this slack, it seems 🙂
s
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
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
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
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
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
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
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
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
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
glad to hear it 🙂 we just landed a few API changes that I think should help with discoverability too.
👏 1
s
been too busy working with Swing 😱
I hate Swing. Please port Compose to the JVM.
😄 2
LOL
Open in Slack
PreviousNext
Powered by