TinyBase: estado local, persistência e sincronização sem atalhos

ANÁLISE EDITORIAL

Uma aplicação pode parecer funcionar offline até que a aba seja recarregada. Outra mantém os dados após o reload, mas não propaga alterações para um segundo dispositivo. A Skill Build With TinyBase ajuda a separar essas decisões antes de gerar ou modificar uma aplicação: estado em memória, persistência e sincronização não são a mesma coisa.

O que esta Skill faz

O procedimento do mantenedor orienta um agente a escolher a arquitetura TinyBase, consultar as opções atuais do gerador, preservar a ordem de inicialização dos recursos e verificar o comportamento pedido pelo usuário. Seu foco não é instalar uma base de dados pronta. É evitar que um projeto seja montado com peças incompatíveis ou que um build bem-sucedido seja confundido com prova de que dados sobreviveram ao recarregamento e chegaram a outro cliente.

A pasta oficial da Skill no commit auditado contém o arquivo principal e uma referência de arquitetura. O próprio texto manda consultar essa referência antes de escolher entre Store, MergeableStore, Persister e Synchronizer. O pacote local mantém essa relação de arquivos.

Para quem serve e quando não usar

Ela faz sentido para quem desenvolve uma aplicação JavaScript ou TypeScript com estado reativo, dados tabulares ou chave-valor, uso offline, persistência local ou sincronização entre instâncias. Pode ajudar tanto no começo de um projeto quanto na análise de uma aplicação TinyBase existente. O mantenedor também documenta integrações de interface com React, Solid e Svelte nos guias oficiais.

Não a trate como indicação automática de que TinyBase é a escolha certa. A Skill recomenda outro banco ou serviço quando o conjunto autoritativo é ilimitado, consultado principalmente no servidor ou depende de recursos gerenciados de backend. Se o problema é somente escolher um banco hospedado, esta Skill não substitui uma avaliação de requisitos de operação, acesso e capacidade.

Quatro peças que resolvem problemas diferentes

O detalhe mais útil da curadoria é a distinção abaixo. Os nomes vêm da referência de arquitetura original, não de um teste inventado pelo Bastidores.

Uma aplicação pode combinar persistência e sincronização. A documentação do TinyBase descreve MergeableStore e sincronizadores como partes complementares; a seção de persistência trata de salvar e carregar dados. A escolha do armazenamento depende do ambiente e da durabilidade exigida, não de um rótulo genérico como “offline”.

Origem, adoção e versão consultada

A fonte é tinyplex/tinybase, mantida pela equipe do próprio produto. Em 22/09/2026, a consulta ao repositório registrou 5.177 estrelas, licença MIT e estado não arquivado. Estrelas indicam interesse público, não comprovam adequação técnica, privacidade ou segurança de uma implementação. Fixamos o commit 6a3c7b6ed4d1dfe9c59090e0ba24fbe726c3c740 para tornar a auditoria reproduzível. O arquivo SKILL.md não declara um número próprio de versão.

O pacote documental fica preso a esse commit. Já npm create tinybase@latest aponta para uma versão variável do gerador. Por isso, opções e saídas precisam ser conferidas na instalação real. Não descrevemos uma execução local do gerador ou um benchmark que não fizemos.

Compatibilidade e pré-requisitos

Para ler a Skill, basta um agente compatível com instruções em SKILL.md e acesso ao documento references/architecture.md. Para criar um projeto, é necessário ter Node.js e npm disponíveis e autorizar a execução do gerador. Para estender um projeto existente, o agente precisa ler o package.json, os imports TinyBase e a configuração de Store, Persister e Synchronizer antes de editar. A versão instalada da biblioteca deve orientar a consulta à documentação, pois exemplos do site atual podem divergir de uma dependência antiga.

Framework de UI, persistência, sincronização e instalação de dependências são decisões separadas. A documentação oficial mostra os caminhos disponíveis; ela não garante que todos estejam presentes na versão do seu projeto.

Instalação segura do pacote documental

Baixe build-with-tinybase.zip e confira o SHA-256 ea44921e4d4a76fb5c3f4cc8cebcbff318cfcd34b1cc0a9598cdd9aade22f19f. No PowerShell, use Get-FileHash .\build-with-tinybase.zip -Algorithm SHA256; no Linux ou macOS, sha256sum build-with-tinybase.zip. O valor deve coincidir antes da extração.

O ZIP contém apenas build-with-tinybase/SKILL.md, build-with-tinybase/references/architecture.md, LICENSE e ORIGEM.md. Extraia para inspeção, leia a licença e o registro de origem, então copie a pasta build-with-tinybase para o diretório de Skills aceito pelo seu agente. Consulte a documentação do agente antes de escolher entre escopo pessoal e escopo de projeto. Este download não instala TinyBase nem executa npm.

Há também um botão separado para abrir o repositório oficial. Compare o conteúdo fixado se preferir obtê-lo diretamente do mantenedor.

Configuração antes do primeiro uso

Defina três respostas em linguagem simples: onde o dado precisa existir durante o uso, onde deve continuar após fechar ou recarregar a aplicação, e se outras instâncias devem receber alterações. Registre também o runtime, o framework, a versão TinyBase já instalada, se há dados sensíveis e quem pode autorizar downloads ou mudanças. Sem isso, o agente pode escolher um gerador ou armazenamento por conveniência e criar uma arquitetura que não corresponde ao produto.

Para uma aplicação existente, peça primeiro um mapa dos arquivos que criam a Store, carregam dados persistidos, iniciam o salvamento e iniciam a sincronização. A referência oficial recomenda carregar o conteúdo persistido antes de começar o salvamento automático; inverter a ordem pode sobrescrever a cópia durável com o estado inicial em memória.

Primeiro uso em um projeto novo

Um pedido útil é: “Compare Store e MergeableStore para uma lista de tarefas que precisa sobreviver ao reload e sincronizar entre dois navegadores. Ainda não instale nada. Mostre a arquitetura proposta, os dados que precisam ser protegidos e o que será testado.” Isso permite revisar a decisão antes de criar arquivos.

Se a criação for aprovada, a Skill orienta consultar as opções atuais com npm create tinybase@latest -- --list-options. Esse comando pode baixar e executar código do registro npm, portanto revise o pacote, use um diretório controlado e siga as políticas da sua organização. A geração não interativa deve explicitar as escolhas e desabilitar instalação e inicialização automáticas com --installAndRun false. Não reutilize opções copiadas desta página sem conferir a saída real do gerador.

Depois, leia o AGENTS.md e o README.md gerados, localize o arquivo principal da Store e só então faça alterações específicas. Instale dependências apenas quando essa etapa estiver autorizada. Um build do cliente confirma compilação; ele não prova que persistência, sincronização ou reconexão funcionam.

Primeiro uso em uma aplicação existente

Antes de mudar código, inventarie dependências e imports, veja onde o estado nasce e termina, e encontre a inicialização e o descarte de Persister e Synchronizer. Consulte a documentação correspondente à versão instalada. Se a aplicação já possui outra fonte de verdade em estado de componente, esclareça qual camada é autoritativa antes de duplicar os dados no TinyBase.

Uma mudança pequena pode ser testada em três passos separados: alterar um valor, recarregar a aplicação e observar se permaneceu; abrir duas instâncias e verificar propagação nos dois sentidos; interromper e recuperar a conexão para examinar o comportamento após reconexão. Registre o ambiente, os dados usados e o resultado. Se algum teste não puder ser feito, declare essa lacuna em vez de substituí-la por “compilou”.

Resultado esperado e limites

O resultado esperado da Skill é uma decisão arquitetural justificável, seguida de uma aplicação gerada ou modificada apenas no escopo aprovado e de evidências dos comportamentos relevantes. Para dados efêmeros, uma Store pode bastar. Para durabilidade, é preciso persistir e recuperar. Para múltiplas cópias, é preciso testar a sincronização. A existência de um MergeableStore não configura automaticamente controle de acesso, hospedagem, backup ou política de resolução adequada a todo negócio.

O site oficial mantém demonstrações reais do produto para inspeção visual e funcional. A capa desta página é uma ilustração editorial original, não uma captura dessas demos nem prova de que o Bastidores executou a aplicação.

Permissões, privacidade e riscos

A leitura do ZIP não precisa de conta, chaves nem acesso a um projeto. Já o primeiro comando npm é uma execução externa e pode modificar o diretório de trabalho. Evite usá-lo em um projeto com mudanças não salvas. Não coloque tokens, senhas, dados de clientes ou outras informações sensíveis em instruções do agente, exemplos públicos, repositórios ou arquivos de download.

Persistência no navegador não equivale a armazenamento seguro de segredos. O MDN explica o comportamento de localStorage, inclusive diferenças por origem e sessão privada. Para dados pessoais ou confidenciais, avalie autenticação, autorização, criptografia, minimização, retenção e exposição por scripts da aplicação separadamente. Se houver sincronização em rede, reveja endpoint, transporte, escopo de acesso e vazamento de dados. A Skill ajuda a estruturar a implementação, não entrega essas garantias por si só.

Erros comuns e como corrigir

• “Salvou, mas desapareceu no reload”: confira se existe Persister, se a carga foi concluída antes do salvamento automático e se o armazenamento escolhido é o mesmo na leitura e na escrita.
• “Funciona em uma aba, mas não em outra”: confirme se o requisito realmente pede sincronização, se ambas as instâncias usam uma configuração compatível e se o teste envolve dois clientes.
• “Compilou, então está pronto”: execute testes de reload, troca bidirecional e reconexão, conforme o comportamento esperado. Build é uma evidência diferente.
• “Opção do gerador não existe”: consulte --list-options na versão disponível e revise o comando, sem forçar uma opção lembrada de documentação antiga.
• “Dados locais precisam atender toda a empresa”: reavalie se o conjunto autoritativo cabe no runtime e se um serviço gerenciado ou outro banco é necessário.

Licença, integridade e escopo do download

A licença MIT do repositório permite redistribuir os documentos com o aviso preservado. O arquivo ORIGEM.md registra URLs, commit e hashes dos bytes originais. O espelho não inclui biblioteca, templates, scripts, binários, dependências npm, banco de dados, demonstrações ou credenciais. A versão da Skill é o commit fixado; a versão do produto em um projeto deve ser verificada no próprio package.json.

O Bastidores mantém páginas individuais de Skills fora da indexação e sem anúncios enquanto este formato de catálogo estiver sob revisão editorial. O catálogo de Skills permanece a entrada pública. Esse estado de indexação não muda as permissões ou a licença da fonte original.

Checklist antes de adotar

• Confirme que TinyBase atende ao tamanho, runtime e autoridade dos dados.
• Separe explicitamente estado, persistência e sincronização no desenho.
• Leia os dois documentos do pacote e compare-os com o commit informado.
• Autorize downloads e criação de projeto antes de rodar o gerador.
• Revise privacidade e segurança dos dados, especialmente no navegador e na rede.
• Valide reload, duas instâncias e reconexão quando esses comportamentos forem requisitos.

Fontes oficiais consultadas

Foram conferidos o repositório do mantenedor, o SKILL.md fixado, a referência de arquitetura, a licença MIT e os guias oficiais de persistência e sincronização. Consulta feita em 22/09/2026. Os exemplos de uso desta página são instruções para avaliação, não resultados de teste.