Love SwiftUI / Combine Framework where UI is a function of state ... Never going back to UIKit. Seeing Compose feel like removing XML, RecyclerView, PagingLib, ViewModel, Room etc ... whenever possible. Thank you for building Jetpack compose in opensource so I can follow the evolution. I am tempted to release all my apps on Compose with Kotlin Flow.

I think it's great you love it. pretty much all of us do. But I don't feel like it's close to being "Production ready" you actually need to compile a version of AS in order to run it.

How so PagingLib, ViewModel or (especially) Room are waste of time if they have no relationship to Compose, they created for different use cases and just do different things.

You’ll most likely end up using Compose alongside most of the things you mentioned: Room, VM, PL, etc

That's a bit of a bummer if we'll end up using the paging library. I'm hopeful that we won't have to use view model either but I'm not sure exactly how that'd work

Compose provides tools only for declarative UI. The rest of the infrastructure will most likely stay the same.

we're putting a lot of work into materials for getting from there to here 🙂

Paging library is an abstraction for loading paged data. Of course you can avoid using it with Compose, exactly how you can avoid using it now, if you don't see any advantages for you. But with compose you have all the same problems that paginglib tries to solve. The same for ViewModel

Right. We're looking at having some Compose-native constructs that would use ViewModel under the hood to save state/transport it across activity recreations where appropriate. The Compose `ListView`/`RecyclerView` is also being designed right next to the team that works on the paging lib so I'd expect some cooperation of ideas there too.

@Adam Powell is the

compose

recyclerview under development right now? or are you referencing to

ScrollerContainer

?

under design; no code to point at yet

Just another question: is

debugSizePaintEnable

under development? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1567525140035500

Yeah we're targeting a minimum of parity with the, "show layout bounds" developer option and ideally some even nicer tooling around it. I think we've probably gone off topic for this thread though 🙂

This all sounds wonderful. There's tons of elements of the paging library and view model that are good and necessary, but as we switch from an imperative world to a declarative one there's no doubt in my mind that there will be opportunities to handle those concerns in a more concise manner. It sounds like the team is taking these considerations in stride, which is awesome. Super excited to see all of the awesome work!

in the meanwhile, whilst compose is baking up you can try

square workflows

. It is sold as a

composable state-machine

library. It changes the way you reason about Android and also share similar concepts to swift-ui.

SwiftUI is just sugar, the Combine framework (data flow) is real meat. From my tests with Jetpack Compose (3 part series), https://android.jlelse.eu/jetpack-compose-primer-92ff005b7ce2 think the real power in Jetpack Compose will be the new simplified data flow as data is always passed down from the parent and events are always passed up from the widgets. This makes it very easy to reason about what is happening. ... have faith in the amazing Android team will do the right things with Compose / Kotlin Flow. Think RecyclerView, PagingLib, ViewModel will be abstracted away, Navigation might just be one line of Kotlin ... MVVM straight to Room/Repo. Sorry ... just on a high from SwiftUI ❤️ but also ❤️ all the feedback and this amazing Android community !!! This community is what drives Android forward.

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1570200666038300?thread_ts=1570159328.032500&cid=CJLTWPH7S If you’d like to explore this, here’s the docs: https://square.github.io/workflow/ And we're in the #squarelibraries channel if you have any questions!