Sorgente dati endpoint

Panoramica

Tutti i componenti remote caricano le opzioni tramite fetchFn. Da @pzeta/vue-form 2.6 esiste una seconda strada: dichiarare la risorsa con endpoint e lasciare che sia il componente a comporre la chiamata PostgREST, riusando filter e filterFields.

// Con fetchFn — pieno controllo, nessuna dipendenza aggiuntiva
props: {
  fetchFn: fetchClienti,
  optionLabel: 'ragionesociale',
  optionValue: 'idcliente'
}

// Con endpoint — la chiamata la compone il componente
props: {
  endpoint: 'anagrafica.clienti',
  select: 'idcliente,ragionesociale,idprovincia',
  order: 'ragionesociale.asc',
  optionLabel: 'ragionesociale',
  optionValue: 'idcliente'
}

Forma dell'endpoint

L'endpoint si scrive come [schema.]risorsa:

Lo schema è opzionale e il punto non è mai ambiguo: le tabelle PZeta sono minuscole e senza separatori.

Props

Il client http della shell è già same-origin, quindi baseUrl serve solo dove il gateway sta sotto un prefisso (es. /apiV1).

Filtri

filter è il filtro statico applicato a ogni richiesta, filterFields elenca i campi del form da osservare: quando il loro valore cambia, i dati vengono ricaricati.

Forma breve ed estesa

Nella forma breve il nome del campo coincide con la colonna e il confronto è eq. La forma estesa serve quando il campo del form ha un nome diverso dalla colonna, o quando il confronto non è un'uguaglianza:

props: {
  endpoint: 'anagrafica.clienti',
  filter: { attivo: true },
  filterFields: [
    'idprovincia',
    { field: 'ricerca', column: 'ragionesociale', operator: 'ilike' }
  ]
}

Con formData = { idprovincia: 12, ricerca: 'rossi' } la richiesta diventa:

GET /clienti?attivo=eq.true&idprovincia=eq.12&ragionesociale=ilike.*rossi*

Come vengono tradotti i valori

Un valore di ricerca senza wildcard viene cercato come "contiene". I valori che contengono caratteri strutturali vengono racchiusi tra apici: 'Rossi, Bianchi' diventa eq."Rossi, Bianchi".

Operatori ammessi: eq, neq, gt, gte, lt, lte, like, ilike, match, imatch, in, is, isdistinct, fts, plfts, phfts, wfts, cs, cd, ov, sl, sr, nxr, nxl, adj.

Da dove arriva il trasporto

Il componente non richiede configurazione: al montaggio cerca un trasporto nell'ordine seguente.

1. Contesto MFE della shell, fornito con la chiave di @pzeta/mfe-contracts — copre gli MFE montati dal portale, che ereditano auth, refresh 401 e X-Tab-Id del client http della shell.
2. Contesto MFE con chiave stringa 'mfeContext', per gli MFE che lo espongono anche in quella forma.
3. Client fornito esplicitamente con provide('postgrestClient', client).
4. Singleton configurato con initPostgRESTClient(), per le app standalone.

Se nessuno risponde, il componente mostra il proprio stato d'errore e il messaggio spiega quale delle quattro strade manca.

Peer dependencies

I moduli PostgREST sono caricati con import() alla prima richiesta: chi usa solo fetchFn non ne paga né il peso né la risoluzione, e non deve installare nulla. Chi usa endpoint ha bisogno delle due peer opzionali:

npm install @pzeta/postgrest @pzeta/mfe-contracts

Limiti

• La richiesta non viene annullata. Il signal non è propagato, perché né PostgrestMfeService né il repository del client lo accettano. Le risposte superate da una richiesta più recente vengono comunque scartate, quindi non si vedono dati stantii: semplicemente la richiesta abbandonata arriva a compimento sulla rete.
• Nessuna paginazione. Per elenchi grandi imposta limit, oppure usa fetchFn con la paginazione del servizio.
• Nessuna ricerca server-side nel dropdown. showFilter filtra le opzioni già caricate; per cercare sul server usa filterFields con operatore ilike legato a un campo del form.

Componenti che la supportano

SelectRemote · ListboxRemote · RadioGroupRemoteInput · TreeRemote · InplaceSelectRemote · OrderListRemote · PickListRemote