https://kotlinlang.org logo
c

chris

07/16/2020, 3:50 PM
How do you know where to draw the line when building components? How was it decided to build a
Box
but to not create a
Circle
composable? I find myself wanting to break everything out into reusable components and rather than just creating the page I need, I end up building a whole infrastructure of components behind it.
z

Zach Klippenstein (he/him) [MOD]

07/16/2020, 3:54 PM
The “rule of three” is what I usually use: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
👍 4
t

Timo Drick

07/16/2020, 3:55 PM
One thing could be the nesting level. So when you reach a state where the level of nested elements gets to high you could break up into several components. And of course if you need the same Component again than this would also be a good reason to create a Component. And also just to increase the readability of the code (This is something you can not really measure on your own. Just ask you team members).
☝️ 1
c

chris

07/16/2020, 4:18 PM
Do you think they follow the same process for the compose libraries? I'm really interested in the design decisions that they have made and why. Where did they come up with the modifier idea and using extension functions on the Modifier object? (not being critical at all, I like it)
c

curioustechizen

07/16/2020, 4:26 PM
Another thing to consider is: by not breaking down into smaller components, you can take advantage of kotlin's lexical scoping, so you don't have to keep passing parameters down the tree. So, extract out a composable if it is really needed like the others already mentioned before me. But in my opinion there's also some disadvantages of splitting them out unnecessarily
👏 1
c

caelum19

07/16/2020, 6:33 PM
I like the rule of three approach @Zach Klippenstein (he/him) [MOD] mentioned, it is a lot easier to reduce reuse by finding what is common in 2 or more instances of code than to attempt to predict the future and get caught in analysis paralysis. Maybe you're already familiar of them but IntelliJ/Android Studio's extract variable and extract method functions are really helpful for this 😄 Also I find high fidelity designs are really helpful for knowing what will repeat how many times and get a strong idea of possible areas your app could expand and save a lot of time in general
z

Zach Klippenstein (he/him) [MOD]

07/16/2020, 6:35 PM
It’s not only easier to abstract when you have more examples, but abstracting too early can actually have a negative effect on tech debt. There’s a lot of stuff written about this online, here’s one: https://medium.com/@thisdotmedia/the-cost-of-premature-abstraction-b5d71ffd6400
🆒 1
a

Adam Powell

07/16/2020, 7:18 PM
@chris > Do you think they follow the same process for the compose libraries? I'm really interested in the design decisions that they have made and why. Not always this rule in particular, but yes, I'm currently 22 pages into a draft of compose API guidelines right now. 🙂 Part of what has made compose interesting is that the programming model itself has been taking shape over time, and we've adjusted our design principles continuously throughout. Feedback from here, formal UX studies, and elsewhere has shaped debate and discussion too.
😯 1
c

chris

07/16/2020, 7:20 PM
I'll add that to my reading list for tonight 🙂
s

Sean McQuillan [G]

07/16/2020, 7:21 PM
From a "how does it make it into the framework" I'd say that there's a few things: •
Box
is in because we found the regular need for a simplest single child composable that doesn't impose a layout when we used Compose ourselves. As well as a lot of discussion. •
Circle
hasn't been discussed as a Composable itself because it's already handled by clip and applied to any composable (e.g. a
Box
). Since we already have one abstraction for non-square shapes adding a second might make the framework harder to learn.
But one of the ways that things make it into the API is feedback about things needed or confusing in this chat room :)
a

Adam Powell

07/16/2020, 7:22 PM
The modifier API in particular has been the result of probably over a year of iteration on ways to solve the general problem space of declaring composable, generic properties for UI elements outside of the core toolkit itself. Partially motivated by the explosion of code that is
View.java
over its 10+ year lifespan to support common properties, and partially inspired by Flutter's SingleChildWidget, while working within constraints of not wanting to further complicate the type system of composable functions with a lot of emits-zero, emits-exactly-one, emits-multiple kind of distinctions
and the fluent builder thing in particular came from @Sean McQuillan [G] making the specific challenge of, "I want it to look like a builder chain" and so I played with some ideas 🙂
😄 1
c

chris

07/16/2020, 7:26 PM
Thanks for the insight guys! 😄
👍 1
a

Adam Powell

07/16/2020, 7:27 PM
Also lots of initial inspiration from kotlin's CoroutineContext
c

chris

07/16/2020, 7:27 PM
There should be a behind the scenes documentary "Building Jetpack Compose" lol
1
a

Adam Powell

07/16/2020, 7:32 PM
Don't give our PMs ideas 😅
c

curioustechizen

07/16/2020, 7:35 PM
Copy code
Don't give our PMs ideas
Uh oh too late. Goes looking for Compose PMs
🙊 1
a

Adam Powell

07/16/2020, 7:46 PM
It's also worth noting that both
Box
and modifiers continue to spark debate on the team
s

Sean McQuillan [G]

07/16/2020, 8:10 PM
Might as well schedule a video crew now @Adam Powell 😆
c

caelum19

07/16/2020, 8:38 PM
Any thoughts or links on how to avoid duplicated code and possibly duplicated solutions to the same problem when there are many people who may be involved in the same codebase(s) or problem and may or may not be in the same team?
s

Sean McQuillan [G]

07/16/2020, 8:39 PM
Yea – on a larger team you'll want to build a design system of components with your design team
Then when building a screen it becomes an exercise in using the existing design system for the UI code
I often joke that there will be a
AppNameButton
component made for every app that uses Compose, but there's some truth to it 🙂.
c

caelum19

07/16/2020, 8:44 PM
As in a button which has just the app's name for text?
s

Sean McQuillan [G]

07/16/2020, 8:45 PM
A button that applies the specific styling for your apps design, and maybe some click metrics tracking or whatever
Basically, encapsulating the contract of "this is what a Button will look like / do" and then using it instead of the framework Button
c

caelum19

07/16/2020, 8:46 PM
Ahh I see haha yeah, maybe people just find buttons really fun to make
s

Sean McQuillan [G]

07/16/2020, 8:47 PM
I'd expect in a largeish code base (10+ devs) it'd make sense to make a custom version of most of the drawing components with a API that only supports what your app allows (Text, Button, etc). Probably less often for layouts (Row, etc)
c

caelum19

07/16/2020, 8:49 PM
interesting
well. good to know that design systems should still work well in Compose 😄 I guess it is slightly off topic but I was wondering more about backend, not necessarily the backend separated by a network, but where problems go beyond rendering data and inputting data, or would you recommend a sort of "system design" (😂) still for that?
s

Sean McQuillan [G]

07/16/2020, 8:50 PM
Ah yea, that just becomes regular architecture in most cases.
Hoist the single source of truth for the data to a ViewModel and then use existing arch practices to handle it from there
👍 1