Manual: construir extensões de browser

Priya — perguntaste-me na semana passada se o vigilante de queda de preços que estás a criar deveria simplesmente verificar a página do produto a cada minuto "para garantir". Antes de o incluíres no build, deixa-me explicar-te tudo, porque o intervalo de verificação é, na verdade, a decisão mais pequena aqui, e acertar na estrutura logo de início vai poupar-te um ou dois ciclos de revisão antes do lançamento.

Comece pelo próprio prompt. Disse-me "uma extensão que vigia esta página e me avisa quando o preço desce", e é uma boa ideia mas ainda não é uma especificação — o construtor precisa de saber quando atua, não apenas o que faz. O seu vigilante é o terceiro de três tipos de gatilho, e vale a pena conhecer os outros dois mesmo que não precise deles, porque o tipo determina as permissões e as permissões determinam o seu prazo de revisão.

• Clicar para agir é o mais económico: um popup que corre uma vez na página atual quando alguém clica no ícone da barra de ferramentas — pense em "reunir todos os preços desta página numa lista".
• Script de conteúdo sempre ativo corre automaticamente num padrão de URL que especifica — bom para algo como destacar o nome de um concorrente em todas as páginas de um domínio, mas tem de indicar o padrão explicitamente, porque "nos nossos sites internos" acaba por ser interpretado de forma mais restrita do que pretendia.
• O seu caso é o terceiro: um vigilante em segundo plano, estado que persiste esteja ou não o separador aberto, a correr num service worker sob o MV3, marcando o ícone quando algo muda.

Esse é o único tipo em que o construtor deve questioná-lo com uma pergunta de seguimento, e vai fazê-lo — porque o número de verificação é um verdadeiro compromisso, não uma formalidade.

O que me traz de volta ao seu instinto de "a cada minuto". Pedi praticamente o mesmo build há algum tempo — vigiar uma página, marcar o ícone numa alteração de preço — e a primeira versão verificava a cada 60 segundos. Funcionava bem para uma pessoa a testar localmente. Multiplique isso pelo número de pessoas que realmente instalam isto e está a martelar a página de produto de alguém sem motivo, porque os preços numa listagem de retalho normal não mudam mais do que algumas vezes por dia. Diga ao construtor "verificar a cada 30 minutos" no prompt. Não é um compromisso, é o pedido mais honesto — ninguém precisa de alertas ao segundo de uma extensão de navegador, e vai agradecer a si mesma mais tarde quando não tiver de explicar a um revisor porque é que a sua extensão contacta o servidor 1440 vezes por dia.

As partes em que não precisa de pensar

Mencionou estar nervosa com o manifesto — não fique, é a única coisa em que genuinamente não precisa de mexer. Ambas as lojas exigem agora o Manifest V3; o MV2 deixou de ser aceite para novas listagens e o Chrome tem vindo a retirar ativamente as extensões MV2 ainda ativas. A mudança principal com o MV3 é que a sua lógica em segundo plano corre como um service worker em vez de uma página de fundo persistente — ativa-se com um evento, o navegador pode terminá-la entre eventos, e o estado tem de passar por chrome.storage em vez de simplesmente viver numa variável. Esse é exatamente o tipo de pormenor de ciclo de vida que o construtor escreve corretamente por predefinição. Nunca vai ver um ficheiro de manifesto a menos que o vá procurar.

No que deveria mesmo concentrar a sua atenção é nas permissões, porque é isso que determina a rapidez da sua revisão, não o código. O seu vigilante precisa de alarms para as verificações periódicas e provavelmente storage para memorizar o último preço — não precisa de tabs ou <all_urls>, e se pedires "a capacidade de funcionar em qualquer site eventualmente" porque poderás expandi-lo mais tarde, o construtor vai construir para esse cenário e vais acabar a pedir acesso alargado a hosts para uma funcionalidade que ainda não existe. Essa é a linha mais assustadora na caixa de instalação — "ler e alterar dados em todos os sites que visitas" — e é também o que faz com que uma revisão automática passe a manual. Descreve o que faz hoje. Alarga depois, se realmente precisares.

Mais duas coisas que merecem trinta segundos de atenção antes de dar isto como terminado: a interface do popup e os ícones.

• Interface do popup — uma página de opções predefinida, caixas de verificação simples, sem hierarquia, é uma fonte real de avaliações de uma estrela que nada têm a ver com o funcionamento da extensão. A sua só tem algumas definições (o URL, talvez o intervalo), mas ainda assim deve parecer que pertence a um produto, e não que é um simples formulário atirado ao ecrã.
• Ícones — verifique o ícone em todos os quatro tamanhos do Chrome (16, 32, 48, 128px, com uma matriz ligeiramente diferente para o Firefox), porque um logótipo nítido a 128 transforma-se numa mancha a 16, que é exatamente onde vive numa barra de ferramentas apinhada a maior parte do dia.

Antes de tocar em qualquer uma das lojas

Testa isto a sério, não apenas na pré-visualização do chat. O que obténs do build é uma extensão realmente carregável, por isso vai a chrome://extensions, ativa o modo de programador, "carregar sem compactação" e testa-a na página real do produto que te interessa — não numa versão simulada dela. Verificaria especificamente duas coisas manualmente: se o pedido de permissão de instalação diz o que seria de esperar dado o que pediste, e o que acontece se o content script alguma vez encontrar uma página para a qual não foi construído — falha silenciosamente ou dá algum erro visível? Ambas demoram menos de um minuto e são o tipo de falha óbvia quando se olha e invisível quando não se olha.

Quando estiver pronta para lançar de facto, vai passar pelas suas próprias contas de programador em ambas as lojas — a listagem é sua, esta plataforma não a gere por si. E quero salientar que as duas lojas não são de todo simétricas, porque não quero que planeie a data de lançamento assumindo que são.

O kit de listagem gerado após o build terminar também vai produzir capturas de ecrã tiradas com a sua extensão realmente em funcionamento (não uma maquete), texto de listagem e respostas sobre práticas de privacidade verificadas contra o código real em vez de preenchidas de memória. Esta última parte é mais importante do que parece para algo que comunica com uma página externa: o questionário de privacidade do Chrome faz perguntas diretas de sim/não sobre o tratamento de dados, e responder "não" a "isto recolhe dados" quando o seu vigilante está a verificar e a guardar preços é o tipo de pequena desonestidade que leva à remoção depois do lançamento, e não apenas à rejeição antes dele. Ter as respostas verificadas contra o que o código faz fecha automaticamente essa lacuna por si.

Uma última coisa, já que a conheço — já está a pensar em adicionar "sincronizar a minha lista de vigilância entre dispositivos" e "acompanhar o histórico de preços ao longo do tempo" assim que isto for lançado. Tudo bem, mas saiba que cada uma dessas funcionalidades é uma nova permissão, e uma nova permissão pode significar uma revisão mais lenta do que a que acabou de passar. Se tiver a certeza de que quer a versão maior, é genuinamente melhor pedi-la já e aceitar uma revisão mais lenta do que ir adicionando permissões uma a uma. Se ainda não tiver a certeza, lance o que já tem — um vigilante com âmbito bem definido passa depressa, dá-lhe utilização real, e a utilização real vale mais neste momento do que uma lista de funcionalidades mais longa parada na fila do Chrome. Pode sempre pedir mais depois; não pode recuperar este lançamento depois de ficar preso em revisão manual por algo de que ainda não precisava.