From 897ff86881adf8452da3a3ad68715e357a9528a5 Mon Sep 17 00:00:00 2001 From: achmadalfiansyah Date: Sun, 5 Oct 2025 23:27:23 +0700 Subject: [PATCH 1/2] feat: added question comparing side-effect handlers (LaunchedEffect, SideEffect, DisposableEffect). --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index 23779b5..a45404d 100644 --- a/README.md +++ b/README.md @@ -432,6 +432,13 @@ this.lifecycleScope.launch { - What are the best practices for performance optimization in Jetpack Compose? - How is navigation handled in Jetpack Compose? - What is Strong Skipping Mode? [Answer](https://www.linkedin.com/posts/anandwana001_coding-datastructures-jetpackcompose-activity-7193437801365823488-SlVT?utm_source=share&utm_medium=member_desktop) +- Compare and contrast `LaunchedEffect`, `SideEffect`, and `DisposableEffect`. Provide a clear use case for each one. + - `LaunchedEffect` is used to run a suspend function (coroutine) safely from a composable. It launches when the composable first enters the composition and cancels when it leaves. It will relaunch if its `key` parameter changes. + Use Case is to run a one-time suspend action when the composable first enters the composition, such as fetching initial data from a network or showing a `Snackbar` + - SideEffect is used to execute a block of code after every successful recomposition. It's an escape hatch to share Compose state with non-Compose code. + Use Case is to publish Compose state to non-Compose code, for example, updating an analytics library with the latest state value after every recomposition. + - `DisposableEffect` is similar to `LaunchedEffect` but provides a mandatory `onDispose` block for cleanup. The onDispose block is executed when the composable leaves the composition or when the `key` changes. + Use Case is to manage resources that require explicit cleanup, such as registering a `LifecycleObserver` and ensuring it's unregistered in the `onDispose` block to prevent memory leaks. ## Thread From bc4b1312ea3f5a3071ced931fec5b1e6538786f5 Mon Sep 17 00:00:00 2001 From: achmadalfiansyah Date: Sun, 5 Oct 2025 23:41:52 +0700 Subject: [PATCH 2/2] fix(compose): Clarify DisposableEffect behavior This commit corrects the description to clarify that: - The effect block runs synchronously, not as a coroutine. - Its primary purpose is for non-suspending side effects that require explicit teardown logic (e.g., registering listeners). - It is distinct from LaunchedEffect, which is specifically for launching coroutines. --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a45404d..3d215b4 100644 --- a/README.md +++ b/README.md @@ -437,8 +437,9 @@ this.lifecycleScope.launch { Use Case is to run a one-time suspend action when the composable first enters the composition, such as fetching initial data from a network or showing a `Snackbar` - SideEffect is used to execute a block of code after every successful recomposition. It's an escape hatch to share Compose state with non-Compose code. Use Case is to publish Compose state to non-Compose code, for example, updating an analytics library with the latest state value after every recomposition. - - `DisposableEffect` is similar to `LaunchedEffect` but provides a mandatory `onDispose` block for cleanup. The onDispose block is executed when the composable leaves the composition or when the `key` changes. - Use Case is to manage resources that require explicit cleanup, such as registering a `LifecycleObserver` and ensuring it's unregistered in the `onDispose` block to prevent memory leaks. + - DisposableEffect is used for non-suspending side effects that require an explicit cleanup (teardown) process. + Unlike LaunchedEffect, the main effect block of DisposableEffect runs synchronously during composition. This block executes whenever the composable enters the Composition or when its given key(s) change. Its primary function is to provide a mandatory onDispose block for cleanup. + Use Case: Its primary use case is for managing listeners or observers from the Android framework that are not Compose-aware. For instance, registering a LifecycleObserver or a BroadcastReceiver inside the effect block, and then unregistering it within the mandatory onDispose block to prevent memory leaks. ## Thread