DEV Community: Marcos Anjos

Jetpack Compose fez sentido pra mim quando eu parei de comparar tudo com XML

Marcos Anjos — Wed, 01 Apr 2026 01:48:48 +0000

Quando comecei a mexer com Jetpack Compose, tentei entender tudo com a cabeça do Android antigo. Eu ainda pensava em XML, Activity, Fragment e atualização manual de interface. Por isso, no começo, parecia que estava faltando alguma coisa: cadê o XML, os ids e o findViewById? O que me destravou foi perceber que Compose não era só um jeito novo de fazer a mesma coisa, mas uma forma declarativa de construir UI. E, vindo do React, foi aí que tudo começou a fazer sentido.

A primeira virada de chave

A principal virada de chave para mim foi perceber que o Compose não era “Android sem XML”. No React, a gente já está acostumado com a ideia de que a interface responde ao estado. No Compose, a lógica é parecida: você descreve a UI com funções @Composable, usa estado, e o framework atualiza o que precisa quando esse estado muda. Não é o mesmo modelo do React, mas a ideia de “descrever a interface em vez de montar tudo manualmente” está ali. Quando eu passei a enxergar o Compose assim, ele começou a fazer muito mais sentido.

Row, Column e Box me fizeram parar de brigar com layout

A parte de layout foi uma das primeiras coisas que me deixou confortável. Row e Column são quase autoexplicativos. Um organiza na horizontal, o outro na vertical. E o Box resolve aqueles casos em que você quer empilhar coisas ou alinhar um elemento dentro de uma área. Não é CSS. Mas, se você já trabalhou com flexbox, a sensação não é tão distante.

// código React
export function ProfileHeader() {
  return (
    <div
      style={{
        display: 'flex',
        flexDirection: 'row',
        gap: 12,
        alignItems: 'center',
      }}
    >
      <img
        src="/avatar.png"
        alt="Avatar"
        style={{
          width: 48,
          height: 48,
          borderRadius: 999,
        }}
      />

      <div
        style={{
          display: 'flex',
          flexDirection: 'column',
        }}
      >
        <strong>Marcos</strong>
        <span>Android + Backend</span>
      </div>
    </div>
  )
}

// código Compose
@Composable
fun ProfileHeader() {
    Row(
        modifier = Modifier.fillMaxWidth(),
        verticalAlignment = Alignment.CenterVertically,
        horizontalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        Image(
            painter = painterResource(R.drawable.avatar),
            contentDescription = "Avatar",
            modifier = Modifier
                .size(48.dp)
                .clip(CircleShape)
        )

        Column {
            Text(
                text = "Marcos",
                style = MaterialTheme.typography.titleMedium
            )
            Text(
                text = "Android + Backend",
                style = MaterialTheme.typography.bodyMedium
            )
        }
    }
}

O que eu gostei aqui é que o layout fica muito explícito. Você bate o olho e entende a estrutura da tela sem precisar ficar pulando entre XML, style, tema e código.

Modifier foi a peça que mais me confundiu no começo

Se teve uma coisa que me pegou de verdade foi Modifier. No início eu pensava nele quase como um “style” do Compose. Só que não é só isso. Com Modifier, você mexe em tamanho, espaçamento, comportamento, clique, borda, background, clipping, alinhamento… e o detalhe mais importante: a ordem importa.

Isso parece pequeno até você perceber que:

padding antes ou depois de clickable muda a área clicável
clip antes ou depois de background muda o resultado visual
border, padding e background não são intercambiáveis

Foi uma das partes em que eu mais apanhei, porque no começo eu só encadeava as coisas até “ficar com cara certa”. Depois entendi que ali existe uma lógica mesmo.

Um exemplo simples

@Composable
fun SelectableCard(
    selected: Boolean,
    onClick: () -> Unit,
    content: @Composable () -> Unit
) {
    val borderColor = if (selected) Color(0xFF4F46E5) else Color(0xFFE5E7EB)

    Box(
        modifier = Modifier
            .clip(RoundedCornerShape(12.dp))
            .border(1.dp, borderColor, RoundedCornerShape(12.dp))
            .clickable(onClick = onClick)
            .padding(16.dp)
    ) {
        content()
    }
}

Depois que eu entendi que Modifier não era enfeite, mas parte da lógica visual e interativa da UI, muita coisa ficou mais previsível.

O lado bom: if, when e loops são só Kotlin

Uma coisa que eu gostei rápido no Compose foi não precisar entrar naquele modo mental de “template + expressão” toda hora. No React, embora tudo esteja dentro do JavaScript, ainda existe aquela mistura constante entre JSX e lógica de renderização. No Compose, a interface já é código Kotlin desde o começo. Então você usa if, when, for e outras estruturas da linguagem de forma direta, sem sentir que está alternando entre marcação e lógica o tempo todo.

Input controlado continua sendo input controlado

Essa parte foi das mais tranquilas pra mim porque lembra muito o React. Se você já trabalhou com input controlado, não tem muito mistério. O valor vem do estado, o onValueChange atualiza esse estado, e a UI reage.

@Composable
fun NameForm() {
    var name by remember { mutableStateOf("") }

    Column(
        modifier = Modifier.padding(16.dp)
    ) {
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Nome") }
        )

        if (name.isNotBlank()) {
            Text("Hello, $name")
        }
    }
}

Pra mim, o que muda de verdade aqui não é o conceito de estado, e sim o vocabulário que o Compose usa para lidar com isso. Se no React a gente pensa em useState e no ciclo de renderização do componente, no Compose essa conversa passa muito por remember, mutableStateOf e rememberSaveable. O remember eu comecei a enxergar como aquele estado que continua existindo entre recomposições. Já o rememberSaveable fica mais próximo daqueles casos em que você quer preservar melhor a informação da tela, por exemplo em uma rotação, sem simplesmente perder tudo que o usuário já fez.

LazyColumn foi onde o Compose começou a ficar familiar

Quando cheguei em lista, tudo começou a parecer menos “mundo novo”. No Compose, LazyColumn é aquele componente que você naturalmente usa pra listas maiores, renderizando só o necessário. E aí entra uma coisa que pra quem vem do React já deveria soar conhecida a identidade do item importa. Se existe um id, usa esse id.

data class Hero(
    val id: String,
    val name: String
)

@Composable
fun HeroList(
    heroes: List<Hero>,
    selectedId: String?,
    onSelect: (String) -> Unit
) {
    LazyColumn(
        contentPadding = PaddingValues(8.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        items(
            items = heroes,
            key = { it.id }
        ) { hero ->
            SelectableCard(
                selected = hero.id == selectedId,
                onClick = { onSelect(hero.id) }
            ) {
                Text(hero.name)
            }
        }
    }
}

O padrão stateful/stateless me ajudou bastante

Outra coisa que eu trouxe do React foi separar melhor o que segura estado do que só renderiza, me ajudou muito pensar assim:

a tela principal segura o estado
os componentes menores recebem dados e callbacks

@Composable
fun ChooseHeroScreen(heroes: List<Hero>) {
    var selectedId by rememberSaveable { mutableStateOf<String?>(null) }

    Scaffold(
        topBar = {
            TopAppBar(
                title = { Text("Qual é seu herói favorito?") }
            )
        }
    ) { innerPadding ->
        HeroList(
            heroes = heroes,
            selectedId = selectedId,
            onSelect = { selectedId = it },
            modifier = Modifier.padding(innerPadding)
        )
    }
}

Isso conversa muito com state hoisting, que é outro conceito que no começo parece nome bonito pra algo simples deixar o estado subir para um nível mais apropriado.

O que mais me atrapalhou vindo do React

Algumas coisas me fizeram perder mais tempo do que eu gostaria:

Achar que Modifier era só estilo

Não é. Ele mexe com layout, interação e até semântica.

Ignorar a ordem das coisas

No Compose, a ordem muda bastante o resultado.

Colocar estado cedo demais no componente errado

Quando eu deixava componente pequeno segurando regra demais, rapidamente ficava chato de reaproveitar.

Subestimar rememberSaveable

Tem tela em que perder estado por besteira é irritante.

Tratar Compose como XML com sintaxe diferente

Esse foi provavelmente o maior erro de todos.

No fim das contas

Hoje, se eu tivesse que explicar Jetpack Compose de um jeito simples, eu diria que ele me pareceu uma mistura de três coisas:

a mentalidade declarativa que eu já conhecia de React
a estrutura forte de uma UI nativa Android
a praticidade de escrever tudo em Kotlin, sem ficar alternando demais de contexto

O que mais me ajudou a sair da trava inicial foi parar de tentar decorar API e focar em entender alguns blocos básicos:

Row, Column e Box
Modifier
remember e rememberSaveable
LazyColumn
state hoisting

Depois disso, o resto começou a parecer menos intimidador.

Compose ainda tem muita coisa que eu estou aprendendo. Mas, honestamente, depois que esse modelo mental encaixa, a experiência fica bem melhor do que eu imaginava quando comecei.

Client-Side Rendering (CSR)

Marcos Anjos — Thu, 24 Oct 2024 00:53:53 +0000

Client-Side Rendering (CSR) é uma técnica comum no desenvolvimento Web moderno, usada para criar aplicações interativas e dinâmicas. Com essa técnica retiramos do servidor a responsabilidade de renderizar a página e trazemos para o lado do cliente, deixando o servidor cuidar do que é mais importante para ele, as regras de negócio. Fazendo essa separação se fez possível oferecer uma experiência de usuário mais fluida, dinâmica e possibilita a criação de novos tipos de aplicações. As vantagens são diversas, mas ao mesmo tempo há trade-offs que devem ser avaliados em cada projeto se vale ou não a pena adotar essa técnica.

O que é Client-Side Rendering (CSR)?

Client-side rendering ou apenas CSR, é uma técnica de desenvolvimento de aplicações dinâmicas onde a renderização da interface ocorre no lado do cliente (navegador). Diferente de como era feito antes dessa técnica se tornar popular, onde o servidor era responsável por fazer esse papel de renderizar a página, retornando ao cliente um arquivo HTML com todo o conteúdo já montado.

Com o CSR passamos o papel de renderizar a página para o navegador (cliente). O servidor apenas envia um arquivo HTML básico que internamente contém links para arquivos Javascript. Ao receber esse HTML o navegador faz download dos arquivos Javascript referenciados que são os responsáveis por renderizar o conteúdo da página. A vantagem do CRS é que uma vez carregado os arquivos Javascript o conteúdo pode ser atualizado dinamicamente sem depender de novas requisições ao servidor. Deixando a experiência de navegação mais fluida para usuário. O CSR é geralmente utilizado em aplicações onde há a necessidade de interações em tempo real ou conteúdos muito dinâmicos como, por exemplo, em single-page applications (SPA). Sendo uma solução para páginas internas, dashboards, ou sistemas onde não há a necessidade de SEO.

Como Client-Side Rendering funciona?

Um exemplo de fluxo de renderização utilizando Client-Side Rendering, seria:

O usuário acessa uma página web, que internamente envia uma requisição ao servidor.
O servidor recebe a requisição e responde enviando um HTML básico contendo praticamente apenas links para arquivos JavaScript e CSS.
O navegador faz o download desse HTML e, assim que terminado, envia novas requisições para baixar os arquivos JavaScript e CSS que estavam referenciados no HTML.
Com os arquivos JavaScript tendo sido baixados eles serão executados e o processo de renderizar a página será realizado.
A partir desse ponto, o JavaScript controla toda aplicação e as interações do usuário, atualizando o conteúdo da página de forma dinâmica, sem novas requisições ao servidor.

Vantagens do Client-Side Rendering

Velocidade: A navegação entre as páginas dentro de uma CSR é extremamente rápida, pois não há a necessidade de fazer várias requisições ao servidor após o carregamento inicial.
Experiência do Usuários: uso CSR são altamente inteiráveis e apresentam ótimo desempenho, proporcionando uma experiência semelhante a aplicativos nativos.
Separation of Concerns: O CSR possibilita a separação entre o Front-end e Back-end, permitindo que o Front-end seja completamente gerido pelo JS, enquanto Back-end cuida apenas dos dados e da lógica do negócio.

Desvantagens do Client-Side Rendering

Alta carga de JS: Em aplicações grandes, os arquivos JS podem se tornar muito pesados, o que pode prejudicar a experiência do usuário, especialmente no carregamento inicial da aplicação.
Problemas de SEO: Como o conteúdo da página renderizado no lado do cliente, os motores de busca têm dificuldades em indexar o conteúdo, já que eles precisam do HTML renderizado e numa aplicação com CSR o HTML está praticamente vazio. Isso pode ser uma desvantagens para aplicações que dependem de SEO como landing pages e e-commerces.
Dependente do cliente: Como a aplicação é executada no lado do cliente, há uma dependência de quanto recurso o mesmo possui, podendo afetar negativamente a experiência do usuário caso seu dispositivo tenha poucos recursos. Além disso, se o dispositivo estiver com a execução de JavaScript desabilitada a aplicação não ira funcionar.

Conclusão

Neste artigo, apresentamos principais pontos importantes sobre o uso do CSR, apresentando os fundamentos e suas vantagens e desvantagens. Através do fluxo CSR, conhecemos as etapas principais como que funciona o ciclo de vida do CSR. Podemos perceber a importância do JavaScript para proporcionar as aplicações que rodam inteiramente no lado do cliente. Apesar dos benefícios do CSR relacionados a experiência do usuário, fica evidente que esse técnica de renderização possui algumas desvantagens relacionado alta carga de JavaScript e problemas relacionados a SEO.

Para contornar as limitações do CSR, temos soluções como o Static Site Generation (SSG) e Server-Side Rendering (SSR). No SSG, as páginas são geradas de forma estática durante o período de build, resultando em HTML já pronto para ser entregue ao cliente. E no caso do SSR, a renderização é feita no lado do servidor que responde com um HTML já renderizado para o cliente.