c

    chris

    2 years ago
    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]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    Timo Drick

    Timo Drick

    2 years ago
    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).
    c

    chris

    2 years ago
    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

    2 years ago
    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

    caelum19

    2 years ago
    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]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    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

    Adam Powell

    2 years ago
    @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.
    c

    chris

    2 years ago
    I'll add that to my reading list for tonight 🙂
    Sean McQuillan [G]

    Sean McQuillan [G]

    2 years ago
    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 😃
    Adam Powell

    Adam Powell

    2 years ago
    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 🙂
    c

    chris

    2 years ago
    Thanks for the insight guys! 😄
    Adam Powell

    Adam Powell

    2 years ago
    Also lots of initial inspiration from kotlin's CoroutineContext
    c

    chris

    2 years ago
    There should be a behind the scenes documentary "Building Jetpack Compose" lol
    Adam Powell

    Adam Powell

    2 years ago
    Don't give our PMs ideas 😅
    c

    curioustechizen

    2 years ago
    Don't give our PMs ideas
    Uh oh too late.Goes looking for Compose PMs
    Adam Powell

    Adam Powell

    2 years ago
    It's also worth noting that both
    Box
    and modifiers continue to spark debate on the team
    Sean McQuillan [G]

    Sean McQuillan [G]

    2 years ago
    Might as well schedule a video crew now @Adam Powell 😆
    caelum19

    caelum19

    2 years ago
    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]

    Sean McQuillan [G]

    2 years ago
    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 🙂.
    caelum19

    caelum19

    2 years ago
    As in a button which has just the app's name for text?
    Sean McQuillan [G]

    Sean McQuillan [G]

    2 years ago
    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
    caelum19

    caelum19

    2 years ago
    Ahh I see haha yeah, maybe people just find buttons really fun to make
    Sean McQuillan [G]

    Sean McQuillan [G]

    2 years ago
    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

    caelum19

    2 years ago
    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?
    Sean McQuillan [G]

    Sean McQuillan [G]

    2 years ago
    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