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.

The “rule of three” is what I usually use: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

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).

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)

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

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

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

@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.

I'll add that to my reading list for tonight 🙂

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.

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

Thanks for the insight guys! 😄

Also lots of initial inspiration from kotlin's CoroutineContext

There should be a behind the scenes documentary "Building Jetpack Compose" lol

Don't give our PMs ideas 😅

Don't give our PMs ideas

Uh oh too late. Goes looking for Compose PMs

It's also worth noting that both

Box

and modifiers continue to spark debate on the team

Might as well schedule a video crew now @Adam Powell 😆

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?

Yea – on a larger team you'll want to build a design system of components with your design team

As in a button which has just the app's name for text?

A button that applies the specific styling for your apps design, and maybe some click metrics tracking or whatever

Ahh I see haha yeah, maybe people just find buttons really fun to make

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)

interesting

Ah yea, that just becomes regular architecture in most cases.