Does anyone have clear guidance for

onActive

and

onDispose

? We went from clear semantic names to

DisposableEffect

and i have no idea what to pass in as a parameter..

This might help you

But doesn’t choosing a state to pass in get away from the spirit of

onActive

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?

Why do you care about lifecycle events?

I don’t understand the question @jossiwolf? Lifecycle events are extremely important in component development, that’s why SwiftUI includes

onAppear/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.

You can just pass

Unit

to

DisposableEffect

.

I could have sworn I read something from @Adam Powell about not needing lifecycle events in composables? I could be wrong. In that case, my apologies Adam.

Thanks @Albert Chang! This allows us to migrate our code to

beta01

in a straightforward manner 🙏

fwiw passing

Unit

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.

Hmm, that confuses me and maybe I should ask a different way:

In react we have

componentDidMount/componentWillUnmount

and SwiftUI

onAppear/onDisappear

and we used to have

onActive/onDispose

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?

I don't use react and I'm not a compose expert, but wouldn't you just have state passed into the composable and if it updates then the composable would update as well. Reacts componentDidMount sounds side-effecty.

@Colton Idle for the majority of scenarios we try and write our components to be as stateless as possible, which is inline with the approach you are suggesting. That being said, there are also plenty of cases where we need to have code that runs when the component is loaded, and more code that runs when unloaded. To quantify,

onAppear

is used 92 times in our

SwiftUI

codebase of 150K lines.

I think the point is that those things (

onAppear/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...

In our experience, lifecycle events are important when you need super precise control over data loading / animation / scroll position / performance scenarios. Especially in an app like ours, where everything is in realtime and you can have 25K simultaneous users all in one chatroom. Coming from React and SwiftUI, the decision to obfuscate lifecycle hooks here seems unintuitive.

It's fine to use `*Effect`s for these purposes; we do it plenty ourselves too. The required arguments aren't to obfuscate, but because 9 times out of 10, you really do need to think about the data dependencies and end to end lifetime of the effect. We saw people write a lot of code like this with the old apis, even when they knew how the system worked:

@Composable
fun MyComposable(
  state: MyState,
  params...
) {
  onActive {
    record(state)
  }

Thanks for providing more color on the decisions, @Adam Powell, and I can see how people new to components/stateless/unidirectional flow could make those mistakes. I also see how floating onActive callbacks are a bit too magical. However I do still feel that the pendulum has swung too far for those of us who use component lifecycle events responsibly. I’m considering creating custom

ComponentAppear { }

and

ComponentDisappear { }

in our codebase to make the code cleaner for these use cases, is this currently possible?

sure, go nuts.

DisposableEffect

and

LaunchedEffect

are both built on the public

RememberObserver

API