Using @stable for the stateful composable wrapper is probably a bad idea

[atick-faisal]

StatefulComposable.kt

In the context of the provided code, the use of the @Stable annotation likely doesn't make sense and could be removed. Here's why:

Purpose of @Stable

The @Stable annotation in Jetpack Compose has a specific function: It signals to the Compose compiler that a composable function has the following guarantees:

1. The output only depends on its inputs: For the same set of input parameters, the function will always produce identical UI output.
2. No side effects: The function won't modify any state that could affect recomposition behavior, beyond state parameters supplied to it.

Why it doesn't fit in this case

• Side-effect potential: Your StatefulComposable potentially has a side effect with the triggering of the snackbar (onShowSnackbar) in the LaunchedEffect when an Error occurs. While the state itself might be stable, the snackbar introduces an element that modifies the UI beyond the basic composition defined by the function.
• Statefulness: StatefulComposable likely already uses internal state mechanisms (remember value by, etc.) to manage changes to the underlying UiState. @Stable is usually more relevant to stateless composables.

When @Stable is Valuable

@Stable is a useful optimization hint for the Compose compiler. This annotation is best used with:

• Smaller, stateless composable functions that are building blocks within your UI.
• Functions where you want to guarantee zero recompositions unless any of the function's parameters change.

In conclusion, unless you have a very specific reason and can guarantee the absence of side effects, remove the @Stable annotation from your StatefulComposable.