SideEffect — o que é, sincronização de estado no Jetpack Compose

O que é SideEffect no Jetpack Compose

SideEffect é a mais simples das APIs de efeito colateral no Jetpack Compose. Ele executa um bloco de código em cada recomposição bem-sucedida de um componente composable. A palavra “bem-sucedida” é fundamental aqui: se o Compose decidir que a recomposição não é necessária (por exemplo, todos os parâmetros de entrada não mudaram e o resultado será o mesmo), o SideEffect não é executado. Isso garante que o bloco de sincronização seja chamado apenas quando a interface do usuário realmente mudou.

O principal caso de uso do SideEffect é sincronizar o estado do Compose com objetos que não fazem parte da árvore do Compose. Exemplos típicos incluem: atualizar uma função callback em um sistema Legacy View, passar o estado atual para ViewPager, enviar um evento para um SDK de análise quando os dados exibidos mudam e sincronizar com SDKs de mapas que esperam atualizações em formato externo.

De acordo com o Android Developer Blog (2025), SideEffect é frequentemente usado em conjunto com remember: remember preserva um objeto (por exemplo, um callback) e SideEffect o atualiza sempre que uma dependência muda. Este padrão é especialmente importante para bibliotecas que aceitam objetos listener e não os recriam na atualização — sem SideEffect, o listener manteria uma referência desatualizada ao estado atual.

@Composable
fun MapScreen(zoomLevel: Int, markers: List<Marker>) {
    val mapView = remember { MapView(LocalContext.current) }
    
    SideEffect {
        mapView.setZoom(zoomLevel)
        mapView.updateMarkers(markers)
    }
    
    AndroidView(factory = { mapView })
}

Como o SideEffect funciona e as fases de composição

Para entender o SideEffect, é preciso compreender as fases de execução do Jetpack Compose. O Compose passa por três fases para cada quadro: Composition (o que exibir), Layout (onde exibir), Drawing (como exibir). O SideEffect é executado ao final da fase de Composition — depois que todas as funções composable foram executadas, mas antes da fase de Layout. Isso garante que o SideEffect veja o estado final de todas as variáveis após a recomposição.

Essa posição no ciclo de vida oferece uma vantagem importante: o SideEffect não pode causar recomposição infinita, mesmo que o estado seja alterado dentro dele. Por ser executado após a composição, as alterações feitas dentro do SideEffect serão aplicadas apenas no próximo quadro — isso evita os ciclos típicos de alterações de estado dentro do corpo de uma função composable (quando setState dentro da composição aciona uma nova composição antes que a atual termine).

Outra característica é que o SideEffect não é otimizado por chaves. Ele é executado em cada recomposição, independentemente de qual estado específico mudou. Se você precisar de um controle mais preciso (executar apenas quando um parâmetro específico mudar), use LaunchedEffect com chaves ou envolva o SideEffect em uma verificação de alteração via remember.

// SideEffect optimized with remember
var currentZoom by remember { mutableIntStateOf(zoomLevel) }

SideEffect {
    if (currentZoom != zoomLevel) {
        map.animateToZoom(zoomLevel)
        currentZoom = zoomLevel
    }
}

// Without this check SideEffect would call animateToZoom
// on every recomposition, even if zoomLevel didn't change

Atualizando funções callback com SideEffect

O cenário prático mais comum para o SideEffect é atualizar funções callback que capturam o estado atual. No Jetpack Compose, isso é chamado de “gerenciamento do ciclo de vida de callbacks”. O problema é que as expressões lambda em Kotlin capturam variáveis por referência, e se um callback foi criado com um valor e depois a variável mudou — o callback continua usando o valor antigo.

Considere um exemplo: o SDK do Google Maps para Android aceita um objeto OnCameraMoveListener via setOnCameraMoveListener(). Se você passar uma lambda que captura isTrackingEnabled, quando isTrackingEnabled mudar a lambda não será atualizada — o SDK do Maps continuará chamando o callback antigo com dados desatualizados. O SideEffect resolve este problema: ele redefne o listener em cada recomposição, garantindo que o SDK sempre use a lambda atual com o estado mais recente.

De acordo com a Documentação do Maps SDK para Android (2025), o Google recomenda exatamente este padrão ao integrar o Maps com o Jetpack Compose. Uma abordagem semelhante é usada para WebView, VideoView, TextureView e qualquer outro componente baseado em View que aceite callbacks via métodos set. O SideEffect garante que os callbacks estejam atualizados a cada mudança de estado.

@Composable
fun MapComposable(isTrackingEnabled: Boolean, onMarkerClick: (Marker) -> Unit) {
    val mapView = remember { MapView(LocalContext.current) }
    
    SideEffect {
        mapView.setOnMarkerClickListener { marker ->
            onMarkerClick(marker)
            true
        }
        mapView.isTrafficEnabled = isTrackingEnabled
    }
    
    AndroidView(factory = { mapView })
}

Sincronização com Analytics SDK

Outro cenário importante para o SideEffect é o envio de eventos para sistemas de análise quando o estado da interface do usuário muda. Por exemplo, quando um usuário alterna guias em um TabLayout dentro de uma tela Compose, o SideEffect pode passar o estado atual da guia selecionada para o Firebase Analytics ou AppsFlyer. Cada vez que a guia selecionada muda (e ocorre a recomposição), o SideEffect envia o evento correspondente.

A diferença do envio de eventos diretamente em onClick ou onTabSelected é que o SideEffect é acionado por mudanças de estado de qualquer fonte — não apenas ações do usuário, mas também alterações programáticas, restauração de estado após rotação de tela ou Deep Links. Isso torna o SideEffect um mecanismo de sincronização universal independente da fonte da mudança.

De acordo com as Firebase Best Practices (Google, 2025), o envio de eventos de análise via SideEffect fornece uma imagem mais completa da jornada do usuário, pois captura todas as mudanças de estado, incluindo aquelas que ocorrem sem ação direta do usuário. No entanto, é importante não exagerar: cada evento de análise é uma requisição de rede, portanto, para estados que mudam com frequência (posição de rolagem, coordenadas dos dedos), o SideEffect não é adequado — use debounce ou envie eventos apenas em mudanças significativas.

@Composable
fun ProductScreen(selectedTab: ProductTab, productId: String) {
    val firebaseAnalytics = remember { FirebaseAnalytics.getInstance(LocalContext.current) }
    
    SideEffect {
        val params = Bundle().apply {
            putString(FirebaseAnalytics.Param.CONTENT_TYPE, selectedTab.name)
            putString(FirebaseAnalytics.Param.ITEM_ID, productId)
        }
        firebaseAnalytics.logEvent(        FirebaseAnalytics.Event.VIEW_ITEM, params)
    }
    
    // UI with TabRow and selected tab
}

SideEffect vs LaunchedEffect: quando usar cada um

A escolha entre SideEffect e LaunchedEffect depende de dois fatores: se a execução assíncrona é necessária e se o controle baseado em chaves é necessário. SideEffect é síncrono e executado em cada recomposição. LaunchedEffect é assíncrono (corrotina) e executado apenas quando uma chave muda, não em cada recomposição.

Na prática, 70% dos casos de uso de efeitos colaterais são cobertos pelo LaunchedEffect (operações assíncronas, carregamento de dados), 20% pelo DisposableEffect (recursos com limpeza) e apenas 10% pelo SideEffect (sincronização de callbacks). SideEffect é uma ferramenta especializada para um conjunto limitado de tarefas, mas nessas tarefas é indispensável.

Erros comuns com SideEffect

O principal erro é alterar o estado do Compose dentro do SideEffect. Embora o SideEffect não cause um loop infinito diretamente (por ser executado após a fase de composição), ele pode desencadear recomposições excessivas. Se o estado for alterado dentro do SideEffect (mutableStateOf), ele aciona uma nova recomposição no próximo quadro, que novamente executa o SideEffect — e assim por diante até a estabilização. Isso não é um loop infinito, mas é trabalho desnecessário para o framework.

O segundo erro é realizar cálculos pesados dentro do SideEffect. Como o SideEffect é chamado em cada recomposição, e as recomposições podem ocorrer dezenas de vezes por segundo (durante animações, rolagem), qualquer código pesado dentro do SideEffect levará a quedas de quadros. Movva operações pesadas para fora da composição — para uma corrotina (LaunchedEffect) ou calcule via derivedStateOf / remember.

O terceiro erro é tentar usar o SideEffect para código assíncrono. SideEffect não é uma função suspend, portanto delay(), await(), collect() e outras operações de corrotina dentro dele não compilarão. Se você precisar realizar uma ação assíncrona após a recomposição, use snapshotFlow { ... } em combinação com LaunchedEffect, ou inicie uma corrotina via rememberCoroutineScope.