https://kotlinlang.org logo
Join Slack
Powered by
I know yall are still rebasing onto the latest 1.3...
# compose
z
I know yall are still rebasing onto the latest 1.3 compiler for the latest IR support, so is it safe to assume there won’t be any dev builds that support kotlin 1.4 anytime soon?
a
One step at a time, but we're hoping to get there asap
z
No worries, just wanted to make sure I wasn’t missing something obvious.
a
If you poke around a bit in gerrit search you should be able to see the home stretch of the current rebase
😮 1
z
Exciting, congrats! Do you know if the rebase itself unblocks suspend functions or does that require more specific work?
a
reports so far are that suspend is working, so 🤞
🤞 2
I'm pretty excited to start pushing more in that API direction. Top of mind for me are an 
effect { }
composable as the 
suspend
version of 
onCommit { onDispose {} }
, animation clocks as 
awaitFrame
-type functions, the 
Flow
version of https://android-review.googlesource.com/c/platform/frameworks/support/+/1279164, and deep composition event scheduling around recomposition, when we run composition lifecycle callbacks, and eliminating the need for espresso idling resource-style polling
suspend
and 
@Composable
are like X and Y axes on the same plane, working with time and declarative snapshots, respectively.
z
Yea, it seems like there are a ton of really exciting possibilities here, these two APIs fit together so nicely. I work on library that, from a "declarative reactive" standpoint, is very similar to compose in a few areas conceptually, and it has something similar to (but more awkward than) your 
effect
coroutine builder and the reactive integrations. It generally takes new devs a bit of time to wrap their heads around treating reactive streams and async work as "something you declare to be happening now, and will be cancelled automatically when you stop declaring it". Letting go of the instinct to explicitly manage disposing is hard, but it makes it impossible to accidentally leak jobs/subscriptions and once it clicks for people they seem to like it.
a
Yep.
The other one that's come up as one of those, "click" moments for people is dialogs and popups
first instinct is to have it manage a show/hide state of its own and then there's a, 🤯 moment when you realize that you can write it as
Copy code
if (show) {
    Dialog(...)
}
z
Yep, we do something similar and it's much easier to reason about, once you stop looking for a 
show
method.
3 Views
Open in Slack
PreviousNext
Powered by