@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 Pedro, thanks for updating your blog. However you still say this: “As the team is not designing the components API as a set of data we can manipulate easily, there is no way we can compare an already rendered view with a new version of this view with just a bunch of modified values in order to implement an efficient UI rendering.”

hey @romainguy I meant depending ont he implementation this part could be really important from the performance viewpoint. Some lines below you can read this too

I guess there is an inner mechanism inside the rendering code making all these components efficient when talking about drawing. However, I can't talk about it because it wasn't part of the talk and the code I've reviewed seems to use canvas API for the component's rendering.

I've updated that paragraph to express better this will depend on the final implementation

Just wanted to chime in with a huge thank you for putting your blog post together! It’s great to see since that can help us understand where to improve our messaging and even influence the direction of development!

thank you so much @Sean McQuillan [G] appreciate it 😃