1

Como inspecionar milhões de registros no React Native sem travar o app

Apps React Native offline-first podem acumular uma quantidade enorme de dados locais.

Pensa em apps usados por equipes de campo, entregadores, times de vendas ou auditores de varejo. Eles podem ficar horas offline enquanto armazenam:

  • registros no SQLite
  • respostas de API em cache
  • mutações pendentes
  • filas de upload
  • rascunhos de formulários
  • valores no MMKV e AsyncStorage

Em algum momento, alguém precisa inspecionar o que realmente está salvo no dispositivo.

A implementação mais óbvia é ler tudo, serializar e enviar uma cópia para um dashboard.

Isso funciona com vinte chaves.

Mas quebra completamente com centenas de milhares de registros.

O app gasta tempo lendo e serializando dados que talvez ninguém nunca vá olhar, enquanto o dashboard precisa processar e renderizar uma cópia que nem deveria existir.

O dataset deve continuar no dispositivo

Enquanto construía o NativeScope, decidi seguir uma regra simples:

Abra uma janela sobre os dados. Não crie outra cópia deles.

Em vez de transferir todo o armazenamento, o NativeScope busca apenas a página que está sendo visualizada no momento.

Se o dev está vendo trinta linhas, o sistema não deveria carregar trinta mil.

https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fegh3dicxjzfoe6pgy1nu.png

Isso muda o custo de algo proporcional ao dataset inteiro para algo proporcional principalmente à página e ao que está visível na tela.

Quatro decisões que tornam isso possível

1. Pré-visualizações limitadas

Valores grandes são mostrados como prévias pequenas.

O valor completo continua acessível, mas só é carregado ou transmitido quando o dev pede explicitamente.

2. Paginação por chave (keyset pagination)

Para tabelas grandes no SQLite, o NativeScope usa cursores em vez de OFFSET, que fica cada vez mais caro.

SELECT *
FROM events
WHERE id > ?
ORDER BY id
LIMIT 200;

A página 100.000 usa o mesmo formato de query da página 1.

3. Leituras cooperativas

Os dados são processados em pequenos lotes.

Entre um lote e outro, a execução volta para o event loop, permitindo que o app continue respondendo a toques, animações e callbacks de rede.

4. Virtualização da viewport

O dashboard só monta as linhas que estão visíveis na tela.

Uma tabela pode ter um milhão de registros sem criar um milhão de nós na interface.

https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F8pzpfglnosb02sk1xkq0.png

O debugger não deveria ser o gargalo

Essa arquitetura é especialmente útil para produtos offline-first, onde o armazenamento local não é só um cache temporário.

Muitas vezes ele é o coração do app.

O objetivo do NativeScope é tornar viável inspecionar SQLite, MMKV e AsyncStorage mesmo quando os dados crescem muito além do que um debugger tradicional consegue lidar bem.

O NativeScope é open source, totalmente local e feito especificamente para React Native.

Para ver a arquitetura completa, incluindo transporte limitado, streaming, paginação e controle de renderização, leia:

👉 Uma janela, não uma cópia

Como você está depurando grandes volumes de dados locais hoje nos seus apps React Native?

Carregando publicação patrocinada...