@esfaenza/flow-builder 20.3.48 → 20.3.49

package/README.md

@@ -435,7 +435,21 @@ Tre cose che il modello non mostra e il form dice:
 - `autoSelectSingleChoice` fa prendere al campo l'**unica** opzione risolta, quando e' una sola: e'
   la tendina che dipende da un'altra tendina — i CAP di un comune — dove chiedere di scegliere non
   decide niente. La spunta compare solo dove il tipo `acceptsChoices`, e altrove e'
-  `SCREEN_FIELD_CONFIGURATION_INVALID` (avviso).
+  `SCREEN_FIELD_CONFIGURATION_INVALID` (avviso);
+- `format` dice **che cosa** un campo di testo raccoglie — `Email`, `Url`, `Phone`, `MobilePhone`,
+  `LandlinePhone` — e serve a due cose insieme: il frontend ne ricava il tipo di input, il runtime
+  rifiuta l'invio sbagliato (`FORMAT_INVALID`). È l'unico dizionario **dichiaratamente aperto**
+  (`screenFieldFormats`): i pattern non stanno nel metadata — che cosa sia un cellulare valido e' una
+  regola del paese in cui il sistema gira — e l'host ne registra dei propri. Da lì le due gravita', che
+  sono l'eccezione alla regola di tutti gli altri cataloghi: fuori elenco e' un'**osservazione**
+  (`SCREEN_FIELD_FORMAT_UNKNOWN`), scritta senza il colore d'avviso, perche' bloccare l'attivazione per
+  un nome che la libreria non conosce sarebbe un falso positivo; su un campo che non raccoglie **un
+  solo testo** e' l'avviso `SCREEN_FIELD_FORMAT_NOT_APPLICABLE`, e il controllo non compare affatto —
+  la condizione e' il tipo di dato piu' la cardinalita', ed e' scritta una volta sola (`formatApplies`,
+  la stessa che applica il validatore della demo). Due cose che il formato **non** e': non e'
+  un'etichetta che il flow possa leggere — se a valle serve sapere che un numero e' un cellulare, quella
+  distinzione sta nel dato — e non riscrive il valore, che e' una trasformazione e la fa una screen
+  action.
 
 Il riordino e l'annidamento si fanno trascinando (`@angular/cdk/drag-drop`, senza drop list: il
 bersaglio si calcola dal DOM) oppure con i comandi «su / giu' / porta fuori».
@@ -473,6 +487,18 @@ cose che un editor ingenuo sbaglia lasciandole comporre per poi accusarle:
   variabile in `collectionReference`: il campo si sceglie da `<fb-structure-member-picker>` con
   `usage="writable"`, perche' un membro calcolato e' `TARGET_NOT_WRITABLE`.
 
+- **le righe minime e le righe iniziali non sono la stessa cosa**, ed e' la distinzione che serve piu'
+  spesso. `minInstances` e' un **vincolo**: sotto quel numero la sezione non scende, e con `1` il
+  runtime non lascia togliere l'ultima riga. `initialInstances` e' una **comodita'**: la schermata si
+  apre con qualche riga pronta, e chi non la vuole la elimina. Un modulo con un punto luce e un punto
+  gas gia' aperti, dove chi ha una sola commodity toglie quello che non gli serve, e'
+  `initialInstances: 1` con `minInstances: 0` — col minimo a 1 sarebbe un modulo che **obbliga** a
+  entrambe. Le righe iniziali si applicano **una volta sola**, e solo finche' nessuno ha scritto la
+  collection: righe arrivate da un ciclo o da una schermata precedente *sono* le righe iniziali e non
+  vengono diluite con righe vuote. Fuori dai limiti il runtime le riporta dentro, quindi l'editor lo
+  dice come avviso e non come errore: il difetto non e' che qualcosa si rompa, e' che il numero scritto
+  non e' quello che si vedra'.
+
 Nell'anteprima si disegna **una** riga, ed e' il modello: a runtime la schermata ne rende una copia
 per elemento. Disegnarne due sarebbe finto — quante siano lo decide chi compila.