@esfaenza/flow-builder 20.3.12 → 20.3.14

package/README.md

@@ -90,7 +90,7 @@ l'attributo di scope di Angular, quindi un CSS incapsulato non li raggiunge.
 | `version` | la versione da aprire; assente → l'attiva se c'e', altrimenti l'ultima (§6.1) |
 | `author` | registrato sulla versione e mostrato nell'elenco |
 | `defaultProcessType` | `processType` iniziale di un flow nuovo |
-| `inspectorMode` | `'dialog'` (predefinito) apre il dettaglio dell'elemento in una finestra sopra il canvas, come il flow builder di Salesforce; `'panel'` lo tiene nel pannello laterale |
+| `inspectorMode` | `'dialog'` (predefinito) apre il dettaglio dell'elemento in una finestra sopra il canvas; `'panel'` lo tiene nel pannello laterale |
 
 | Output | Quando |
 |---|---|
@@ -334,10 +334,29 @@ vuoto resta "non lo so" — primitiva non esposta, tipo senza valori dichiarati,
 da scegliere — e allora il valore si digita; con l'elenco popolato un valore fuori elenco e' un
 **avviso**, perche' nessun codice della §7 lo blocca ed e' l'editor ad accorgersene prima del runtime.
 
-Perche' l'editor conosca il tipo della destinazione serve saperlo: in un Assignment arriva da
-`getWritableReferences` (per corrispondenza esatta del nome: su `Cliente.Stato` resta ignoto), in una
-condizione e in un filtro dal riferimento o dal campo a sinistra, in un Transform dal **membro** della
-classe di destinazione. Dove il tipo non si sa, il campo resta generico invece di indovinare.
+**Un campo a `null` e' assente.** Il valore ha un campo per tipo e va valorizzato **uno e un solo**
+campo (§4.2); la §2 dice che cio' che non c'e' si omette, ma un backend che serializza tutte le
+proprieta' — `System.Text.Json` senza `IgnoreNullValues` lo fa di default — manda
+`{"enumValue": "InIstruttoria", "formulaExpression": null, …}`: un solo valore e sette caselle piene
+di niente. Riconoscere il campo con `!== undefined` faceva vincere il primo letto, cioe'
+`formulaExpression`: l'editor apriva la **formula** (vuota) e il valore, pur presente nel documento,
+spariva dalla vista — e il conteggio dei campi accusava `VALUE_AMBIGUOUS`. La regola sta in
+`core/flow-value.util.ts` (`isValued`, `valuedFieldOf`, `valuedFieldsOf`) e la usano l'editor del
+valore e quello delle condizioni: `null` e `undefined` significano la stessa cosa, mentre
+`booleanValue: false`, `numberValue: 0` e `stringValue: ''` restano valori.
+
+Perche' l'editor conosca il tipo della destinazione serve saperlo, e i percorsi non fanno eccezione:
+`POST /flows/references` elenca le **radici** e non i percorsi, quindi su `Richiesta.Stato` la
+corrispondenza esatta del nome non trova niente. Il tipo si ricava allora navigando la catena —
+`core/reference-path` innesta l'elenco dei riferimenti su `core/path-navigation`: trova il prefisso
+dichiarato piu' lungo (§4.1), naviga il resto un segmento alla volta e prende il tipo dell'**ultimo**
+segmento. Lo usano l'Assignment (su `getWritableReferences`), le condizioni e i filtri sui record —
+dove la radice e' l'entita', quindi `Cliente.Citta` si risolve come il campo che e'. In un Transform
+il tipo viene dal **membro** della classe di destinazione, che l'inspector già descrive.
+
+Dove il tipo non si sa — catena interrotta, catalogo assente, segmento inesistente, percorso radicato
+sull'output automatico di un elemento (che il backend non verifica, §7) — il campo resta generico
+invece di indovinare: un elenco chiuso di valori sbagliati e' peggio di una casella di testo.
 
 Lo stesso controllo, nella variante `<fb-name-picker>`, vale per **ogni altro nome che il flow
 prende da fuori**: tipo di action e action, script, form, i nomi dei loro parametri di ingresso