avoiding namespace pollution is implicit here since

@Composable

functions can only be called from other

@Composable

functions - yes, we don't want that pollution either 🙂

From the language perspective and idiomatic Kotlin, it would be nice to have a sketch on how could a generic system look like, even if still a plugin. By generic, I mean something that is not bound to this UI system, nor to Android or anything else. Like it was said on

suspend

function, let’s imagine for a moment we are doing an “incremental structure updates” plugin to the language, and let’s pretend we can have a (soft) keyword. In the true Kotlin spirit, we should be able to develop libraries and frameworks, and not just UIs. Like if we have

compose fun Data(name: String)

, then where the composition context comes from, how do you scope different DSLs belonging to different systems, etc. These are open questions, and they are probably out of scope of this very specific use case, but I find it interesting thinking about it and it would be nice to see what you folks think here.

Sounds like Compose is strongly moving in the Functional direction (aka Functional DSLs). Would there be any plans in the compose language proposal on how state is managed? Do think that the compose language proposal should include the ability to initialise the context in a code block without having to pass through function parameters, so a user can use a composable API like this eg:

// ...
StoryWidget {
    story = StoryData
    Clickable {
        onClick = onClick
        Padding {
            amount = 8.dp
            Column {
                Title { txtContent = story.title }
                Image { src = story.image }
                Text { txtContent = story.content }
            }
        }
    }
}

@Leland Richardson [G] my comment about testing was in another direction. I simplified it in this channel saying that'd close the door for testing but if you read the post what I mean is that returning the components could simplify the way Android devs test their applications. Even if you don't think snapshot testing could be a good testing strategy, a good design should let the developer choose the scope of the test or the testing strategy we could use for our automated test suite. I'm going to paste here the same message I sent you and the rest of your team sending me private messages and asking for my email to send me detailed explanations about the usage of compose that are not part of the documentation: I wrote the article with the information Google provided during the Google I/O and wrote in the official compose documentation. If you think there is something I didn't express properly or I didn't understand properly that could be because of the lack of information. That's why the post is written using a lot of questions and assumptions. I'm just a random developer, if I understood that, any other developer may have thought the same. An example of the assumptions or inaccurate parts of the post is the inner state of the component. During the Google I/O talk the message was: "we don't want local state in our components, we will use a single source of truth" and nobody explained that the state can be part of the tree as other google employee already told me by DM. You have another example here:

However, this is not part of the repository right now and we will have to wait until a new release in order to check if the suggested implementation looks like this or not.

If nobody documents how the library is implemented the only thing I can find is questions around. I'm not judging anybody. I'm really sorry if you or your team feel bad because of my blog post. I didn't mean to hurt you or your team feelings. I already told Adam and the whole team I think you are doing it great with compose and as I said in my blog post:

The Android team is doing it great. Believe me when I say that this Compose API is way better than the current state of the art of Android development.

During the Google IO talk the team said "go to the repo and play with compose" and that's what I did. After playing with compose and the available documentation I wrote the post. if compose has an API that is not documented or used in the example provided, I'm afraid I can't review it. If you have examples of things that don't match what I explained in the blog post I'll add a note with the resources you provide me. I hope these resources will be part of the documentation soon.

Hey friends! I just published a blog “Compose from First Principles” talking about some of the implementation details around compose. Would love to hear your thoughts! http://intelligiblebabble.com/compose-from-first-principles/

Will the components have the same names as what we currently have? RecylerView LinearLayout EditText etc... If not, what is the plan to help developers have a easier time adjusting to the new names?

I think names is not the hardest part of migration, after all API and overall approach is completely different

Will there be an option to mix "regular" views with compose, so existing UI open source libraries are still usable?

Hi, I'm curious about design decisions between Compose and Scala.Binding ( https://github.com/ThoughtWorksInc/Binding.scala#design ) and why Compose wasn't designed towards Scala.Binding, but went to kind of "virtual DOM" way.

This can be done automatically (without needing

Key

) if

Item

uses a

@Pivotal

parameter such as,

fun Item(@Pivotal item: DataItem) {
   ...
}

then calls to

Item

automatically track the value of

item

.

Thanks for the details. What I do not quite understand is the meaning of

source location

in

unique to the source location of the call site.

in the blog, and in your explanation the meaning of

source property

in

you introduce a key that is combined with the source property to introduce a group specific key.

Do you plan to handle accepting a component of a certain type? Like having the

appBar

parameter of

Scaffold

only accept "a component of type appBar"

Is the plan that Compose will use the framework's app resource system, eg res/drawable-land etc? All the snippets I've seen show things like

Text ("Hello World")

instead of

Text (R.string.hello_world)

backpressure can mean different things depending on the context, but in the case of @Model objects, mutating a property does not synchronously cause a recomposition. Mutations are observed in a transaction, and recomposition happens when the transaction commits. When recomposition happens, the tree is traversed again from top-down, with higher up invalidated scopes recomposing before ones further down. Though we haven’t built things at true scale with compose yet, this was designed specifically to prevent some of the typical scalability issues you see with observable UIs

to be fair, we’re more like:

fun composition() {
    Column {
        Text("Hello")
        Image("<https://image>")
        repeat(2) { Text("Hello") }
    }
}

how would a user add an extra param to the Text method?

I would like to further express the problem brought up by @Jacob Applin. Say you have a component that is a text field named

TextField

. And then I want to make a version of that that validates text input named

ValidatedTextField

. I would now need to copy paste the possibly extremely long declaration of

TextField

, as part of the declaration of

ValidatedTextField

, and then feed all of these parameters into

TextField

, and then every time

TextField

adds new arguments I need to add those to

ValidatedTextField

.

Something like:

fun ValidateTextField(foo: Bar, @ParamsOf<TextField> p)

Will the system handle memory and resources cleanup? And will individual components be lifecycle aware? for example: dialogs

why are

mainAxisSize

,

mainAxisAlignment

, etc ints instead of enums? Oh it says right there that it should be changed nvm

Is there a way to draw based on the size of an element? Something like

Layout(children = {Text("Hello")},  layoutBlock = { measurables, incomingConstraints ->
    val sizeOfTheHelloText = /*calculate size*/
    Draw {
    /* draw some special border around the text */
    }
}

Or

OnChildPositioned(onPositioned = { coords->
    Draw {
    /* draw some special border around the text */
    }
}) {
    Text("Hello")
}

The problem lies in

Draw

, as 'there is no composition context' there. Getting the size of the text I managed to figure out how to do. For context, I'm trying to make a button that fills up like a progress bar.

Is there a plan where we can have a

hot reload

feature supported with compose just like in flutter or react ? One of downside of compose is that you can't visualize your UI anymore.

@Antanas A. HTML and CSS are not desirable. Just look at the massively inconsistent ecosystem of WEB UI frameworks and helpers. We don't want to be lost in a jungle of solutions that all have unsatisfying drawbacks. The cascading nature of CSS leads to many display bugs where some style is often applied to elements that were not designed for it. HTML is more verbose than what Kotlin can bring us, and lacks any logic. That's why there's "magic" frameworks or things like JSX. There are plenty of other reasons, but I think that's enough to justify trying to make something better, without the decades of legacy HTML and CSS have.

but I'm questioning the way why it's started from scratch and nothing reused (with exception: did they reuse low level 2d rendering engine which was in Chrome? Same as flutter - https://skia.org/ ?)

If so, how to implement this use case: for slow devices, animations for "slow devices" must be off , or in portrait mode do not show some UI elements

the greatest failure of Android may turn out to be its inability to blur the line between an APK and a webpage which have no meaningful difference except for the platform chooses to elevate one above the other

So... Swift UI? Looking pretty similar to compose 😎

SwiftUI. What a developer experience. I am now hoping for a common Kotlin bridge between Compose and SwiftUI. 😄 I am curious what Compose devs think of these developments