Manuale: creare estensioni per browser

Priya — la settimana scorsa mi hai chiesto se il watcher dei cali di prezzo che stai costruendo dovrebbe semplicemente controllare la pagina prodotto ogni minuto "per sicurezza". Prima di implementarlo, lasciami spiegare tutto quanto, perché l'intervallo di polling è in realtà la decisione più piccola in gioco qui, e ottenere la struttura giusta fin dall'inizio ti risparmierà uno o due cicli di revisione prima del lancio.

Parti dal prompt stesso. Mi hai detto "un'estensione che controlla questa pagina e mi avvisa quando il prezzo scende", ed è una buona idea ma non è ancora una specifica — il builder deve sapere quando agisce, non solo cosa fa. Il tuo watcher è la terza delle tre tipologie di trigger, ed è utile conoscere anche le altre due anche se non ti servono, perché la tipologia determina i permessi e i permessi determinano i tempi di revisione.

• Click-to-act è la più economica: un popup che viene eseguito una volta sulla pagina corrente quando qualcuno clicca l'icona nella barra degli strumenti — pensa a "estrai tutti i prezzi di questa pagina in un elenco".
• Content script sempre attivo viene eseguito automaticamente su un pattern di URL che specifichi — utile per qualcosa come evidenziare il nome di un concorrente su ogni pagina di un dominio, ma devi indicare il pattern esplicitamente, perché "sui nostri siti interni" viene interpretato in modo più restrittivo di quanto intendessi.
• Il tuo caso è il terzo: un watcher in background, uno stato che persiste indipendentemente dal fatto che la scheda sia aperta, in esecuzione su un service worker sotto MV3, che mostra un badge sull'icona quando qualcosa cambia.

Questa è l'unica tipologia in cui il builder dovrebbe farti una domanda di approfondimento, e lo farà — perché il valore del polling è un vero compromesso, non una formalità.

Il che mi riporta al tuo istinto di "ogni minuto". Ho chiesto quasi esattamente la tua stessa build tempo fa — controllare una pagina, mostrare un badge sull'icona al variare del prezzo — e la prima versione faceva polling ogni 60 secondi. Funzionava bene per una persona che testava in locale. Moltiplica questo per quante persone effettivamente installano la cosa e stai martellando la pagina prodotto di qualcuno senza motivo, perché i prezzi su un normale annuncio al dettaglio non cambiano più di poche volte al giorno. Di' al builder "controlla ogni 30 minuti" nel prompt. Non è un compromesso, è la richiesta più onesta — nessuno ha bisogno di avvisi sotto il minuto da un'estensione del browser, e ringrazierai te stessa più avanti quando non dovrai spiegare a un revisore perché la tua estensione contatta il server 1.440 volte al giorno.

Le parti a cui non devi pensare

Hai menzionato di essere in ansia per il manifest — non esserlo, è l'unica cosa che davvero non devi toccare. Entrambi gli store ora richiedono Manifest V3; MV2 non è più accettato per le nuove schede e Chrome sta attivamente dismettendo le estensioni MV2 ancora attive. Il cambiamento principale sotto MV3 è che la tua logica in background viene eseguita come service worker invece che come pagina di sfondo persistente — si avvia su un evento, il browser può terminarlo tra un evento e l'altro, e lo stato deve passare attraverso chrome.storage invece di risiedere semplicemente in una variabile. Questo è esattamente il tipo di dettaglio di ciclo di vita che il builder scrive correttamente per impostazione predefinita. Non vedrai mai un file manifest a meno che tu non vada a cercarlo.

Ciò a cui dovresti effettivamente dedicare attenzione sono i permessi, perché è questo che determina la velocità della tua revisione, non il codice. Il tuo watcher ha bisogno di alarms per il polling e probabilmente storage per ricordare l'ultimo prezzo — non ha bisogno di tabs oppure <all_urls>, e se chiedi "la possibilità di lavorare eventualmente su qualsiasi sito" perché potresti espanderlo in seguito, il builder costruirà in base a quello e ti ritroverai a richiedere un accesso host ampio per una funzionalità che non esiste ancora. È la voce più spaventosa nella finestra di installazione — "leggi e modifica dati su ogni sito che visiti" — ed è anche ciò che fa passare una revisione automatica a una manuale. Descrivi cosa fa oggi. Ampliala più avanti se ne hai davvero bisogno.

Altre due cose che meritano trenta secondi di attenzione prima di considerare finito il lavoro: l'interfaccia del popup e le icone.

• Interfaccia del popup — una pagina di opzioni predefinita, caselle di controllo spoglie, nessuna gerarchia, è una vera fonte di recensioni a una stella che non hanno nulla a che vedere con il funzionamento dell'estensione. La tua ha solo un paio di impostazioni (l'URL, forse l'intervallo), ma dovrebbe comunque sembrare parte di un prodotto, non un modulo buttato lì.
• Icone — fai controllare l'icona in tutte e quattro le dimensioni di Chrome (16, 32, 48, 128px, con una matrice leggermente diversa per Firefox), perché un logo nitido a 128 diventa una macchia sfocata a 16, che è esattamente dove vive per gran parte della giornata in una barra degli strumenti affollata.

Prima di toccare uno dei due store

Provalo per davvero, non solo nell'anteprima della chat. Ciò che ottieni dal build è un'estensione effettivamente caricabile, quindi vai su chrome://extensions, attiva la modalità sviluppatore, "carica non pacchettizzata" e testala sulla pagina prodotto reale che ti interessa — non una versione simulata. Controllerei manualmente due cose in particolare: il prompt di permesso di installazione dice quello che ti aspetteresti in base a ciò che hai richiesto, e cosa succede se il content script incontra una pagina per cui non è stato costruito — fallisce silenziosamente o genera un errore visibile? Entrambe richiedono meno di un minuto ed entrambe sono il tipo di bug ovvio nel momento in cui lo guardi e invisibile se non lo fai.

Quando sarai pronta a pubblicare davvero, passerai attraverso i tuoi account sviluppatore su entrambi gli store — la scheda del prodotto è tua, questa piattaforma non la gestisce al posto tuo. E voglio segnalarti che i due store non sono affatto simmetrici, perché non voglio che tu pianifichi la data di lancio assumendo che lo siano.

Il kit di pubblicazione generato al termine della build produrrà anche screenshot presi dalla tua estensione realmente in esecuzione (non un mockup), i testi della scheda del prodotto e le risposte sulle pratiche relative alla privacy verificate rispetto al codice reale invece di essere compilate a memoria. Quest'ultimo punto è più importante di quanto sembri per qualcosa che comunica con una pagina esterna: il questionario sulla privacy di Chrome pone domande secche di sì/no sul trattamento dei dati, e rispondere "no" a "questo raccoglie dati" quando il tuo watcher sta effettuando polling e salvando prezzi è il tipo di piccola disonestà che porta alla rimozione dopo il lancio, non solo al rifiuto prima. Avere le risposte verificate rispetto a ciò che fa il codice colma automaticamente questo divario.

Un'ultima cosa, visto che ti conosco — stai già pensando di aggiungere "sincronizza la mia lista di controllo tra dispositivi" e "tieni traccia dello storico prezzi nel tempo" una volta lanciata. Va bene, ma sappi che ciascuna di queste è un nuovo permesso, e un nuovo permesso può significare una revisione più lenta di quella appena affrontata. Se sei sicura di volere la versione più ampia, è davvero meglio richiederla ora e affrontare una sola revisione più lenta piuttosto che aggiungere permessi uno alla volta. Se non sei ancora sicura, pubblica quello che hai — un watcher con permessi ben delimitati viene approvato in fretta, ti fa ottenere un utilizzo reale, e l'utilizzo reale vale di più in questo momento rispetto a un elenco di funzionalità più lungo bloccato nella coda di Chrome. Puoi sempre chiedere di più in seguito; non puoi riavere questo lancio una volta bloccato in revisione manuale per qualcosa di cui non avevi ancora bisogno.