Un database nella scheda. Il mockup resta sul tuo computer.

Il fatto che un’app si apra nel browser non dice ancora dove lavori. Può essere l’interfaccia di un servizio remoto, un documento statico con qualche interazione o un programma che esegue quasi tutta la logica sulla macchina dell’utente. Per capire che cosa succede ai file bisogna seguire il percorso dei dati, non fermarsi alla forma della finestra.

In Telario il documento scelto viene letto ed elaborato nel browser. Il server consegna l’applicazione: HTML, JavaScript, CSS e il modulo WebAssembly necessario a SQLite. Il progetto non viene inviato dall’editor a un servizio di conversione. Questa scelta risponde a un’esigenza concreta: aprire un archivio di lavoro senza trasformarlo in un allegato destinato a un altro server.

Dire «locale», però, non basta. Restano memoria, dipendenze, compatibilità, download e persistenza. Una scheda può eseguire un database e comunque perdere le modifiche quando viene chiusa. Un server sulla stessa macchina può servire l’app senza conoscere il documento aperto. Le differenze contano, soprattutto quando si passa da una demo riuscita a un file reale con molte pagine e immagini.

1. Il server porta gli attrezzi, non prende il progetto

Nel percorso Docker, Telario viene compilato e poi servito da Nginx. Il browser richiede i file dell’app e li esegue. Non occorre montare la cartella dei mockup nel container: la selezione del documento avviene dall’interfaccia del browser. Separare queste due fasi evita un equivoco comune, cioè pensare che ogni file aperto da una pagina web debba necessariamente transitare dal server che ha consegnato quella pagina.

Il primo avvio ha comunque bisogno di rete per scaricare immagini Docker e dipendenze. Dopo la compilazione, l’editor non richiede CDN o servizi esterni per lavorare sui documenti. Questa è una descrizione del percorso previsto dall’app, non una promessa generale su ogni processo presente nel sistema operativo. Un’estensione del browser, la cartella sincronizzata da cui scegli un file e il software della tua macchina hanno comportamenti propri.

La domanda utile è quindi precisa: quali richieste produce l’editor quando apro e modifico un documento? I test browser controllano anche richieste esterne inattese durante i percorsi previsti. Un controllo osservabile vale più della sola parola «privacy» stampata vicino al pulsante. L’architettura deve rendere la promessa verificabile nel codice e nel comportamento, non soltanto gradevole nel titolo della pagina.

2. Un .bmpr contiene più di un’immagine

Telario tratta il .bmpr come un archivio SQLite. Il lettore cerca le tabelle necessarie, legge le informazioni di formato e recupera risorse e pagine. Dentro una pagina ci sono dati che descrivono controlli: tipo, coordinate, dimensioni, proprietà e altre informazioni. L’immagine che vedi è una rappresentazione di questi dati, non un PNG semplicemente nascosto sotto un’estensione diversa.

La distinzione spiega perché un’apertura riuscita richieda più lavoro di una conversione del nome file. Bisogna interpretare la struttura, riconoscere gli elementi e scegliere come disegnarli. Un pulsante ha un testo e una geometria; una freccia ha estremi e stile; un gruppo contiene altri controlli. Alcuni dettagli sono riconosciuti, altri vengono conservati senza essere completamente rappresentati. Conservazione e visualizzazione sono capacità differenti.

Il lettore mantiene i byte originali e i JSON grezzi. Questa scelta permette di non ricostruire l’intero archivio soltanto a partire da ciò che l’interfaccia comprende. È importante per i campi sconosciuti: l’assenza di un comando nel pannello proprietà non deve diventare automaticamente la cancellazione di dati esistenti. La prima regola di un interprete parziale è non confondere «non lo uso» con «non serve a nessuno».

3. Perché SQLite può vivere nel browser

L’app usa sql.js per inizializzare SQLite attraverso un modulo WebAssembly distribuito insieme alla build. Il codice importa il percorso del file .wasm, lo passa all’inizializzazione e riutilizza il risultato. Se l’inizializzazione fallisce, la promessa memorizzata viene azzerata per consentire un tentativo successivo, invece di trasformare un errore temporaneo in uno stato irrecuperabile per l’intera sessione.

Quando l’utente seleziona un file, i byte diventano l’input di un database in memoria. Le query leggono tabelle e risorse senza richiedere un database remoto. Non serve installare un server SQLite separato, creare utenti o configurare una connessione aziendale. La complessità rimane nel programma e nelle risorse della macchina che esegue il browser.

Questa comodità non equivale a costo zero. Il contenuto deve stare in memoria, così come il modello usato dall’editor e la cronologia delle modifiche. Un documento grande può richiedere più risorse di quanto suggerisca la dimensione del download. Il limite di apertura è 100 MB, ma quella soglia è un controllo d’ingresso, non una garanzia di fluidità universale. La domanda sulle prestazioni va sempre collegata al file, all’operazione e al computer usato.

4. Il modello separa il documento dai gesti

Una volta letto l’archivio, il modello espone pagine e controlli con funzioni dedicate a testo, geometria e proprietà. L’interfaccia non deve conoscere ogni dettaglio delle query SQLite per spostare un elemento. Il renderer non deve decidere come viene scaricato il file finale. Questa divisione rende più semplice controllare il percorso delle informazioni e correggere un difetto nel punto adatto.

Nel repository la struttura è visibile: src/io si occupa dell’archivio; src/model dei dati e della geometria; src/render del disegno; src/editor della cronologia; src/export delle esportazioni; src/ui dei comandi e delle interazioni. Non sono sei prodotti separati. Sono responsabilità distinte dentro una piccola applicazione che deve rimanere comprensibile quando viene modificata.

Una modifica grafica non dovrebbe cambiare il writer. Una correzione agli alias delle icone non dovrebbe riscrivere gli identificativi nel documento. Un’aggiunta al pannello proprietà deve invece essere verificata anche rispetto ai dati che produce. Separare i livelli non elimina le regressioni, ma aiuta a scegliere test pertinenti e a capire quali effetti possono essere indiretti. L’ordine delle cartelle è utile quando corrisponde a un ordine delle responsabilità.

5. SVG come linguaggio del canvas

Il renderer disegna i controlli usando SVG. Questo permette di rappresentare geometrie, testi e tracciati come elementi vettoriali, trasformabili rispetto alle coordinate della pagina. Lo zoom cambia la vista; non richiede di sostituire ogni elemento con una nuova immagine raster. L’esportazione SVG può riutilizzare lo stesso sistema di rappresentazione, mantenendo una relazione leggibile tra ciò che l’app mostra e ciò che produce.

L’applicazione non usa le risorse grafiche proprietarie di Balsamiq per imitare esattamente ogni controllo. I font sono quelli disponibili nel sistema e varie forme hanno una resa indipendente. rough.js aggiunge uno stile sketch opzionale. Quel tratto disegnato a mano è una modalità visiva, non una certificazione di corrispondenza con il programma originale.

La scelta del vettoriale aiuta anche a incorporare le icone come tracciati, senza dipendere da un font remoto. Ma non risolve automaticamente tutti i problemi: testo ricco, tabelle, gruppi e curve possono richiedere interpretazioni approssimate. Il vantaggio è poter controllare il disegno elemento per elemento. Il limite è dover implementare davvero quelle regole, una alla volta, senza affidarsi al fatto che un file contenga già abbastanza informazioni per renderle ovvie.

6. Le immagini non sono tutte la stessa cosa

Le risorse incorporate supportate comprendono PNG, JPEG, GIF e WebP. Il lettore riconosce firme raster previste e costruisce dati utilizzabili nel browser. Le risorse esterne, i link e gli SVG incorporati non vengono caricati o eseguiti. È una scelta esplicita: aprire un archivio non deve trasformarsi automaticamente nell’esecuzione di contenuti attivi o nel recupero di indirizzi contenuti nel documento.

Questo comportamento può produrre una differenza rispetto a ciò che l’autore vede nel proprio ambiente. Un’immagine collegata esternamente potrebbe essere disponibile a lui e non comparire nell’interpretazione locale. La risposta corretta è identificare il tipo di risorsa e il limite, non promettere che ogni immagine assente sia recuperabile dall’app senza altre condizioni.

Per una segnalazione utile basta spesso sapere se la risorsa era incorporata, quale formato aveva e quale controllo la riferiva. Non serve pubblicare la fotografia del cliente per dimostrare un problema di decodifica. Un’immagine sintetica nello stesso formato può isolare il comportamento. Anche qui la conservazione dell’archivio e la resa visiva devono essere valutate separatamente: una risorsa non rappresentata non è necessariamente una risorsa cancellata.

7. La cronologia è memoria di lavoro

Annulla e ripeti permettono di esplorare modifiche senza trattare ogni gesto come definitivo. Telario mantiene una cronologia fino a cento operazioni. È una capacità utile durante la sessione, ma non un archivio permanente delle revisioni. Chiudere o ricaricare la scheda può perdere il lavoro non scaricato, anche se un attimo prima era possibile premere «annulla».

Questa differenza riguarda l’aspettativa dell’utente. Molte applicazioni web abituano a pensare che ogni modifica sia già stata salvata da qualche parte. In un editor locale senza autosalvataggio persistente, quella supposizione è sbagliata. Il risultato va esportato deliberatamente e conservato in una posizione riconoscibile. Il fatto che il browser continui a mostrare la pagina non prova l’esistenza di una copia durevole.

La cronologia serve a lavorare meglio, non a sostituire una politica di salvataggio. Per una prova lunga conviene produrre risultati intermedi proporzionati allo scopo: un’immagine, un JSON o una copia sperimentale verificata. Il formato giusto dipende dal passo successivo. Salvare tutto indiscriminatamente può creare confusione; non salvare nulla affida troppo alla sopravvivenza di una scheda. Fra i due estremi c’è una scelta consapevole e molto meno drammatica.

8. Sei esportazioni, sei domande diverse

SVG e PNG descrivono la pagina come immagine. Markdown recupera i testi di tutte le pagine. JSON offre una rappresentazione dei dati utile all’ispezione. Mermaid e draw.io cercano una struttura di diagramma, deducendo collegamenti dalla vicinanza degli estremi. Queste uscite non sono equivalenti e non andrebbero presentate come sei modi intercambiabili di conservare l’intero progetto.

Se devi mostrare una schermata, scegli un’immagine e controllane la resa. Se devi riutilizzare testi, parti da Markdown e ricostruisci il contesto. Se devi analizzare i dati, il JSON può aiutare. Se vuoi un diagramma modificabile altrove, verifica nodo per nodo le relazioni dedotte. Una freccia vicina a due forme non contiene necessariamente la stessa semantica di un collegamento dichiarato nel modello dell’altro strumento.

Il PNG viene contenuto entro 8192 pixel per lato e circa trentadue megapixel. Questo limita la dimensione della rasterizzazione, ma può comportare una riduzione per pagine molto grandi. Prima di usare l’immagine per una consegna controlla leggibilità, ritaglio e testi. L’esportazione riuscita è l’inizio della verifica del risultato, non la sua conclusione. Un file scaricato correttamente può ancora essere inadatto allo scopo per cui lo stai preparando.

9. Dieci prove per capire l’architettura senza leggerla tutta

Segui le richieste della pagina

Apri gli strumenti di sviluppo del browser e osserva la rete durante il caricamento dell’app. Poi seleziona un documento di prova. La distinzione da cercare è tra richieste per gli attrezzi dell’editor e invio del contenuto del progetto. Non pubblicare automaticamente schermate degli strumenti: URL, percorsi e altri dettagli possono rivelare informazioni che non servono alla verifica.

Usa prima la demo, poi un file sintetico con un nome riconoscibile. Annota cosa succede quando cambi pagina o esporti. Se una richiesta inattesa compare, identifica chi l’ha prodotta: codice dell’app, estensione del browser o altro contesto. Il test dovrebbe essere ripetibile con un ambiente pulito. Lo scopo non è dimostrare una parola assoluta come «sicuro», ma verificare un comportamento concreto: l’editor non carica il documento su un servizio remoto per elaborarlo. È una domanda più piccola e proprio per questo può ricevere una risposta fondata.

Apri un archivio non valido

Un file con estensione .bmpr non è automaticamente un database supportato. La prova con un file non valido serve a controllare come l’app comunica il problema e se mantiene il progetto già aperto. Un errore di ingresso non dovrebbe trasformarsi silenziosamente in una perdita del contesto di lavoro esistente.

Prepara dati sintetici e osserva il messaggio. Non serve rinominare un documento importante per fare la prova. Dopo l’errore torna alla pagina precedente e verifica che sia ancora disponibile. Questo test riguarda una proprietà dell’interfaccia e del lettore insieme: il nuovo tentativo di apertura deve fallire in modo riconoscibile, senza essere scambiato per un progetto vuoto. La qualità degli errori fa parte dell’esperienza locale. Quando non esiste un operatore remoto a cui chiedere cosa sia successo, il programma deve almeno distinguere il problema dal successo.

Confronta due pagine della demo

La demo sintetica è utile perché non contiene dati aziendali ed è riproducibile. Navigare fra due pagine permette di capire il rapporto tra elenco, selezione e canvas. Prova uno zoom e osserva se stai modificando la vista o i dati di geometria. Sono operazioni diverse, e l’interfaccia dovrebbe consentire di distinguerle.

Questa familiarità evita errori nelle prime prove su un progetto reale. Se non trovi un elemento, potrebbe essere fuori dalla vista, appartenere a un’altra pagina o non essere rappresentato come ti aspetti. Usare «adatta» e verificare il nome della pagina sono controlli semplici prima di concludere che un contenuto sia sparito. Una demo non dimostra la compatibilità con tutti gli archivi, ma offre un terreno stabile per imparare i gesti. È il posto adatto per sbagliare un clic senza trasformarlo in una domanda sul progetto del cliente.

Cambia un testo e annulla

Scegli un’etichetta della demo, cambia il contenuto e usa annulla. Poi ripeti l’operazione con ripeti. Osserva il testo sul canvas e nel pannello proprietà. La prova verifica che interfaccia, modello e cronologia descrivano lo stesso stato, invece di aggiornarsi ciascuno per conto proprio.

Non è necessario modificare dieci campi contemporaneamente per capire la funzione. Una variazione riconoscibile è più facile da osservare e da riportare in caso di errore. In seguito puoi provare una sequenza più lunga con spostamento e ridimensionamento. Mantieni però un obiettivo per ogni prova: quale relazione stai controllando? Un test manuale utile produce un’osservazione specifica. Cliccare molte cose fino a quando qualcosa sembra strano può scoprire un problema, ma lascia spesso un lungo lavoro di ricostruzione. Anche l’esplorazione beneficia di una piccola disciplina, soprattutto quando i dati vivono soltanto nella sessione.

Esporta lo stesso elemento in SVG e PNG

Le due uscite servono a confrontare vettoriale e rasterizzazione. Aprile fuori dall’editor e guarda bordi, testo, immagini e sfondo. Verifica che la pagina prevista sia quella esportata e che il nome non crei ambiguità con un risultato precedente. Il download riuscito non garantisce da solo la qualità dell’immagine finale.

Se trovi una differenza, descrivi dove compare: soltanto nel PNG, anche nell’SVG o già sul canvas. Questa distinzione aiuta a localizzare il problema fra rendering condiviso e rasterizzazione. Non correggere il documento prima di aver capito il livello coinvolto. Un testo tagliato soltanto nell’immagine raster richiede un’analisi diversa da un testo già interpretato male nel modello. La prova insegna una regola generale dell’architettura: confrontare più uscite dello stesso dato rende visibile il punto in cui una trasformazione introduce la differenza.

Prova una risorsa raster sintetica

Un’immagine di esempio permette di verificare un formato senza esporre contenuti reali. Confronta una risorsa incorporata supportata con un riferimento esterno, sapendo che quest’ultimo non viene caricato dall’editor. La differenza attesa va definita prima della prova; altrimenti un limite intenzionale può essere segnalato come comportamento casuale.

Osserva anche come l’immagine si comporta nell’esportazione SVG e PNG. Il risultato dovrebbe essere valutato nel flusso completo che userai davvero. Se la risorsa compare nel canvas ma non nell’uscita, il problema è diverso da una mancata lettura iniziale. Quando prepari una segnalazione, conserva questa distinzione. Uno schema minimo con un solo controllo e un’immagine sintetica può risultare più utile di un archivio pieno di pagine. Ridurre il caso non serve a sminuire il problema: serve a renderne visibile la causa.

Misura un’operazione, non un’impressione

Se vuoi capire le prestazioni, scegli un evento osservabile: apertura, cambio pagina, trascinamento o esportazione. Una sensazione generale di lentezza mescola attività con costi molto diversi. Annota dimensione indicativa del documento, numero di pagine coinvolte e presenza di immagini, senza includere dettagli privati nel resoconto pubblico.

Ripeti la stessa operazione in condizioni simili e considera il primo caricamento separatamente dai successivi. Un’inizializzazione WebAssembly non è la stessa cosa di ogni cambio pagina. Evita di convertire una singola misura in una promessa valida per tutti i computer. L’obiettivo della prova è individuare un vincolo concreto, non costruire una classifica improvvisata. Un risultato come «il PNG di questa pagina richiede più tempo del cambio pagina» è modesto ma informativo. Può guidare una correzione o semplicemente aiutarti a scegliere il formato più adatto alla consegna.

Ricarica soltanto dopo aver esportato

Questa prova rende evidente la differenza fra memoria e persistenza. Su dati sintetici, modifica un elemento, esporta il risultato necessario e poi ricarica. L’app non offre autosalvataggio persistente del progetto. Se ti aspettavi di ritrovare il lavoro automaticamente, hai appena identificato un’aspettativa da correggere prima di una sessione importante.

Non usare un documento reale per dimostrare a te stesso che puoi perdere modifiche. La demo è sufficiente. Controlla invece che il file scaricato sia presente e leggibile, perché quello è il risultato durevole della tua azione. La memoria della scheda è comoda per lavorare, ma non è una cartella nascosta che garantisce recupero. Dare un nome preciso a questa differenza permette di costruire un’abitudine semplice: prima di chiudere, verificare cosa è stato effettivamente conservato fuori dall’app. Il gesto richiede poco tempo e previene un tipo di sorpresa del tutto evitabile.

Leggi il JSON senza confonderlo con una specifica

L’ispezione dei dati può aiutare a capire un controllo sconosciuto o una proprietà che il renderer non gestisce. Vedere un campo nel JSON, però, non significa conoscere automaticamente tutte le sue regole. Può appartenere a una versione, a un tipo di controllo o a un contesto che richiede ulteriori verifiche.

Usa i dati per formulare ipotesi osservabili: quale identificativo viene letto, quali coordinate sono presenti, quale proprietà distingue due casi? Poi confronta con il comportamento. Evita di pubblicare l’intero JSON di un progetto privato per fare una domanda su una sola icona. Una struttura ridotta con valori sintetici è spesso sufficiente. L’ispezione è uno strumento diagnostico, non un invito a considerare ogni campo come documentazione ufficiale del formato. Una buona analisi mantiene separati ciò che è stato osservato, ciò che è stato dedotto e ciò che deve ancora essere verificato.

Confronta il codice con il testo del sito

Una pagina di presentazione può invecchiare più velocemente del software. Quando una funzione ti serve davvero, confronta la descrizione con README, limiti documentati e comportamento della versione usata. Il sito deve facilitare questa verifica, collegando le fonti del progetto invece di chiedere fiducia soltanto al tono della pagina.

Se il testo promette una cosa e la build ne fa un’altra, la discrepanza è un problema da correggere anche quando il codice funziona come previsto. La documentazione è parte dell’interfaccia fra progetto e utilizzatore. Nel caso di Telario il confine più importante rimane chiaro: prima versione funzionante, rendering parziale per vari controlli e salvataggio .bmpr sperimentale. Un’architettura interessante non rende meno necessari questi avvisi. Anzi, più è facile avviare una demo, più è utile spiegare cosa quel successo dimostra e quali verifiche non sostituisce.

10. Cosa cambia quando il file diventa grande

Un’architettura in memoria sposta il lavoro verso il dispositivo dell’utente. Immagini incorporate, numero di controlli e quantità di stati mantenuti nella cronologia possono aumentare il consumo di risorse. Due archivi della stessa dimensione non sono necessariamente equivalenti: uno può contenere poche immagini pesanti, l’altro molte pagine con geometrie e testi. Il comportamento va osservato sulle operazioni che contano per il tuo flusso.

Il limite di 100 MB evita alcune aperture eccessive, ma non è una valutazione preventiva completa della complessità. Per una prova iniziale scegli un archivio rappresentativo e conserva il materiale originale. Controlla prima le pagine essenziali, poi le esportazioni richieste. Non è necessario esercitare ogni funzione soltanto perché il file si è aperto. Una prova proporzionata produce informazioni migliori di una sessione casuale molto lunga.

Se emergono rallentamenti, descrivi il punto del percorso: lettura, costruzione del modello, cambio pagina, disegno o produzione dell’uscita. Non sempre l’utente può isolare il livello preciso, ma può almeno dire quale gesto ha preceduto l’attesa. Questa informazione consente a chi sviluppa di cominciare dal posto giusto, invece di cercare genericamente «nel browser». Il browser è la stanza; per trovare il problema serve sapere quale attrezzo era in uso.

11. Un perimetro leggibile è una funzione

Una piccola app non deve fingere di essere un sistema completo. Telario non gestisce utenti, non offre collaborazione online e non sincronizza progetti. Il server non riceve i mockup e non costituisce un archivio condiviso dei documenti. Questi confini riducono alcune complessità e ne lasciano altre a chi organizza il lavoro: conservazione, revisioni, accesso alla macchina e verifica delle consegne.

Il vantaggio dell’elaborazione locale è concreto quando corrisponde al problema. Posso aprire un documento senza predisporre un servizio di conversione e senza trasformare una piccola esigenza personale in un’infrastruttura di gestione file. Il costo è accettare i limiti della sessione e dell’interprete. Non è una formula universale; è una scelta coerente con un’attività precisa.

12. Aggiornare l’app senza confondere programma e documenti

Una build nuova modifica gli attrezzi con cui leggi il progetto. Non aggiorna magicamente i file che hai già scaricato, non corregge le immagini precedenti e non porta con sé le modifiche rimaste nella memoria di un’altra scheda. Prima di aggiornare la pagina o ricompilare durante una sessione, conserva quindi i risultati che ti servono. La separazione fra software e documento è utile finché viene rispettata anche nelle operazioni quotidiane.

Per confrontare due versioni dell’app usa lo stesso archivio di ingresso e la stessa pagina. Se cambi contemporaneamente software, file e procedura, una differenza diventa difficile da attribuire. Registra la versione o il commit della build quando il confronto serve a verificare una regressione. Non occorre farlo per ogni consultazione informale, ma è importante quando il risultato guida una correzione del renderer o del writer.

Una buona verifica comprende anche ciò che non deve cambiare. Un aggiornamento alle icone può migliorare la visualizzazione senza alterare gli identificativi conservati nel progetto. Una modifica al CSS dell’interfaccia non dovrebbe cambiare la geometria del documento. Se l’effetto atteso è ben delimitato, è più facile scegliere una prova significativa e accorgersi di un effetto collaterale. I confini delle responsabilità diventano così criteri concreti per il controllo della qualità.

13. Dipendenze locali non significa dipendenze invisibili

L’app incorpora librerie con compiti distinti: React per l’interfaccia, sql.js per SQLite, rough.js per lo stile sketch e Font Awesome Free per il catalogo di icone. Il fatto che questi componenti vengano serviti localmente non elimina i loro autori o le loro licenze. Le attribuzioni sono parte del pacchetto distribuito e devono seguire gli aggiornamenti delle dipendenze.

Questo dettaglio ha anche una conseguenza tecnica: fissare una provenienza e una versione aiuta a riprodurre il risultato. Se un’icona cambia nome o un componente modifica un comportamento, sapere quale release era inclusa rende il confronto meno ambiguo. La riproducibilità non riguarda soltanto il codice scritto nel progetto; riguarda gli elementi esterni su cui quel codice si appoggia. Una build comprensibile racconta anche da dove arrivano i suoi attrezzi.

Per lo stesso motivo il catalogo delle icone viene ricavato da una release precisa della fonte ufficiale e distribuito insieme all’app. Non è necessario chiedere un tracciato a un servizio remoto ogni volta che appare un controllo sul canvas. L’assenza di quella richiesta migliora l’autonomia dell’editor dopo il caricamento, ma comporta una dimensione iniziale maggiore della build. È uno scambio concreto fra risorse distribuite e indipendenza durante l’uso, da valutare con misure e non con una preferenza astratta per file sempre più piccoli.

Queste scelte restano modificabili nel tempo. Ciò che deve rimanere stabile è il modo di descriverle: quali componenti sono inclusi, quale lavoro svolgono, quali richieste fanno e quali dati attraversano il confine della macchina. Se sappiamo rispondere a queste domande, «locale» smette di essere un aggettivo rassicurante e diventa una proprietà osservabile del percorso dei dati.

Per provarla, parti dalla guida di avvio e confronta le funzioni con la pagina di compatibilità. Il codice dell’app permette di seguire il percorso dai byte al canvas. La parte più interessante di questa architettura, per me, non è il database dentro una scheda. È il fatto che quella scheda possa finalmente mostrarmi il documento e lasciarmi tornare al lavoro, con le informazioni necessarie per capire anche ciò che non sta facendo.