Sam
03/01/2021, 10:07 PMonActive
and onDispose
? We went from clear semantic names to DisposableEffect
and i have no idea what to pass in as a parameter..Jordi Saumell
03/01/2021, 10:11 PMSam
03/01/2021, 10:15 PMonActive
and onDispose
? I just want generic component lifecycle events, now I have to think about which piece of state is an argument when that isn’t what I care about. Am I missing something?jossiwolf
03/01/2021, 10:47 PMSam
03/01/2021, 11:48 PMonAppear/onDisappear
React includes componentDidMount/componentWillUnmount
and Jetpack Compose presumably included onActive/onDispose
. We use them all the time, just like every other developer building production apps.Albert Chang
03/02/2021, 12:00 AMUnit
to DisposableEffect
.Colton Idle
03/02/2021, 12:15 AMSam
03/02/2021, 12:27 AMbeta01
in a straightforward manner 🙏Adam Powell
03/02/2021, 12:32 AMUnit
or true
or any other constant as effect key parameters is intended to look suspicious. It has its uses, but it correlates strongly with building composables that are more stateful than they could be, and that might break if something in their lambda capture changes during recomposition and the effect holds a stale reference to the original value instead of updating.Sam
03/02/2021, 12:36 AMIn react we haveand SwiftUIcomponentDidMount/componentWillUnmount
and we used to haveonAppear/onDisappear
which we used quite frequently when components loaded and unloaded (subscribe to stuff, scroll to initial position, etc). Now that those are gone, what is the recommended way to use these lifecycle events without writing suspicious code?onActive/onDispose
Colton Idle
03/02/2021, 12:52 AMSam
03/02/2021, 12:59 AMonAppear
is used 92 times in our SwiftUI
codebase of 150K lines.eygraber
03/02/2021, 3:51 AMonAppear/onDisappear
etc...) can be modeled as state if they need to be used for UI, and that would be the "correct" way to use Compose.
If you need those callbacks to have an effect that's not related to UI (i.e. a side effect) you can use DisposableEffect
or one of the other types of effects.
I think what @Adam Powell was referencing about looking suspicious is that the API is purposely clunky for that use case so that you would reconsider if you actually need to use it that way.
I personally try to keep my compose layer as "dumb" as possible so that the only thing it knows about is rendering state. If I needed to do something non UI related in response to lifecycle I would do it from the Activity/Fragment or a lifecycle observer, etc...Sam
03/02/2021, 4:59 AMAdam Powell
03/02/2021, 3:24 PM@Composable
fun MyComposable(
state: MyState,
params...
) {
onActive {
record(state)
}
if (foo != null) {
DisposableEffect(foo) {
// ...
}
}
and
if (foo != null) {
Button(onClick = { foo.performAction() }) {
// ...
}
}
Sam
03/02/2021, 8:14 PMComponentAppear { }
and ComponentDisappear { }
in our codebase to make the code cleaner for these use cases, is this currently possible?Adam Powell
03/02/2021, 8:15 PMDisposableEffect
and LaunchedEffect
are both built on the public RememberObserver
APIremember {}
an object that implements that interface compose will give it callbacks at various points in the remember lifecycle. This is about the only/lowest level "lifecycle" Compose works inRememberObserver
escape to user code and that user code passes it to composable functions as a parameter or `remember {}`s it in other places, it can linger in the composition for longer than you might expect. Best practice is to not leak references to them to user code unless you're prepared to deal with this.