How do you know where to draw the line when building components? How was it decided to build a `Box`...

# compose

[chris]

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.

[Zach Klippenstein (he/him) [MOD]]

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

[Timo Drick]

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

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

[curioustechizen]

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

[caelum19]

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

[Zach Klippenstein (he/him) [MOD]]

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

[Adam Powell]

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

[Adam Powell]

This is another post I like a lot: https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

[chris]

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

[Sean McQuillan [G]]

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.

[Sean McQuillan [G]]

But one of the ways that things make it into the API is feedback about things needed or confusing in this chat room :)

[Adam Powell]

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

[Adam Powell]

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 🙂

[chris]

Thanks for the insight guys! 😄

[Adam Powell]

Also lots of initial inspiration from kotlin's CoroutineContext

[chris]

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

[Adam Powell]

Don't give our PMs ideas 😅

[curioustechizen]

Don't give our PMs ideas

Uh oh too late.
Goes looking for Compose PMs

[Adam Powell]

It's also worth noting that both Box and modifiers continue to spark debate on the team

[Sean McQuillan [G]]

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

[caelum19]

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?

[Sean McQuillan [G]]

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

[Sean McQuillan [G]]

Then when building a screen it becomes an exercise in using the existing design system for the UI code

[Sean McQuillan [G]]

I often joke that there will be a AppNameButton component made for every app that uses Compose, but there's some truth to it 🙂.

[caelum19]

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

[Sean McQuillan [G]]

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

[Sean McQuillan [G]]

Basically, encapsulating the contract of "this is what a Button will look like / do" and then using it instead of the framework Button

[caelum19]

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

[Sean McQuillan [G]]

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)

[caelum19]

interesting

[caelum19]

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?

[Sean McQuillan [G]]

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

[Sean McQuillan [G]]

Hoist the single source of truth for the data to a ViewModel and then use existing arch practices to handle it from there