O Problema: O custo invisível das buscas
Muita gente comete o erro de criar um tipo de dado (Data Type) chamado Produto e colocar tudo lá dentro: nome, descrição longa, 10 imagens, histórico de preços, fornecedores, etc.
O resultado? Toda vez que você faz um Repeating Group para mostrar apenas o nome do produto, o Bubble "carrega" todos os campos pesados na memória, queimando suas WUs e deixando o app lento.
O Tutorial: Técnica de Data Splitting (Divisão de Dados)
Em 2026, a regra de ouro é: Busque o leve, carregue o pesado sob demanda.
Passo 1: Separe as informações
Em vez de um único Data Type Produto, crie dois:
- Produto_Header (Leve): Apenas o essencial para buscas (Nome, Preço, Categoria, Foto Miniatura).
- Produto_Details (Pesado): Informações densas (Descrição longa, Galeria de Fotos, PDFs, Logs).
Passo 2: Crie a conexão
No tipo Produto_Header, crie um campo chamado Detalhes que aponta para o tipo Produto_Details. No tipo pesado, faça o mesmo apontando para o cabeçalho.
Passo 3: Otimize o Repeating Group
No seu Repeating Group, faça a busca apenas pelo Produto_Header. Como os dados são leves, o carregamento será instantâneo e o consumo de WUs por linha será mínimo.
asso 4: O "Pulo do Gato" (Carregamento sob demanda)
Crie um Popup ou um Group de detalhes. Apenas quando o usuário clicar em um item da lista, você define o conteúdo desse grupo como Current Cell's Produto_Header's Detalhes.
Por que isso é genial? O Bubble só vai gastar recursos para baixar a "Descrição Gigante" e a "Galeria 4K" do produto que o usuário realmente clicou.
Por que isso é vital em 2026?
Com a estrutura de preços atual, eficiência não é mais um luxo, é sobrevivência. Se você tem 10.000 registros, carregar 50 campos por linha em uma busca é o caminho mais rápido para o prejuízo.
Vantagens Reais:
- Velocidade: Seus Repeating Groups vão voar, mesmo em conexões 4G/5G instáveis.
- Economia: Redução de até 60% no consumo de WUs em páginas de listagem.
- UX: O usuário tem uma percepção de que o app é "nativo" pela rapidez na resposta.
Dica Bônus de Especialista
Sempre que possível, use Option Sets para categorias ou status que não mudam com frequência. Option Sets não consomem WUs para serem carregados, pois ficam no "cache" do navegador do usuário.
O que achou dessa abordagem? Se você aplicar essa técnica de divisão de dados no seu próximo projeto ou até mesmo refatorar um app atual, a diferença na performance é visível logo no primeiro "refresh". Na Itadigital, esse é o padrão que usamos para garantir que nossos clientes tenham escala sem sustos na fatura.
Se tiver alguma dúvida sobre como estruturar essa relação entre as tabelas, é só me chamar!