Namespacing dello schema

Fai in modo che tutti i tipi e le interfacce aggiunti allo schema dai plugin ricevano automaticamente un namespace.

Il namespacing dello schema evita i conflitti di nomi, che si verificano quando proprietari diversi (ad es. team differenti in azienda, o tra plugin di terze parti) usano lo stesso nome per un tipo o un'interfaccia.

Ad esempio, supponiamo che l'azienda "AwesomeWP" abbia un team Tutorial e un team Vendite, e che entrambi creino un tipo Product per lo schema GraphQL dell'azienda, generando un conflitto.

Applicando il namespacing allo schema, i due tipi verrebbero automaticamente convertiti in AwesomeWPTutorialsProduct e AwesomeWPSalesProduct, evitando il conflitto senza dover modificare manualmente lo schema né far interagire i team tra loro.

​

Le entità del modello dati di WordPress non sono soggette a namespace

Il modello dati di WordPress è considerato canonico, e i suoi tipi di schema GraphQL (come Post e User) e le interfacce (come Commentable e WithMeta) non sono soggetti a namespace.

​

Namespacing dello schema negli endpoint

Esistono 2 livelli ai quali è possibile definire se lo schema sarà soggetto a namespace o meno. In ordine di priorità:

​

1. Nella configurazione dello schema

Il namespacing dello schema per un custom endpoint o una persisted query può essere definito tramite la corrispondente configurazione dello schema:

​

2. Modalità predefinita, definita nelle Impostazioni

Se la configurazione dello schema ha il valore "Default", verrà utilizzata la modalità definita nelle Impostazioni:

​

Visualizzare lo schema con namespace

Usa il client Voyager per visualizzare lo schema con namespace.

Quando il namespacing è disabilitato, lo schema WordPress appare così:

Quando è abilitato, i tipi e le interfacce aggiunti dai plugin sono soggetti a namespace e appaiono così:

​

Interrogare nomi di tipi (non-)soggetti a namespace

Una volta abilitato il namespacing, i tipi possono essere interrogati usando sia il nome con namespace sia quello senza. Pertanto, solo le queries che coinvolgono tipi in conflitto devono essere modificate, non tutte.

Ad esempio, se il team Vendite di AwesomeWP ha anche un tipo Discount, una query che richiede questo nome di tipo funziona comunque:

query {
  discounts {
    ...DiscountProps
  }
}
 
fragment DiscountProps on Discount {
  price
  dateRange
}Copy

Solo il tipo in conflitto Product dovrebbe essere aggiornato in AwesomeWPSalesProduct nella query, per eliminare qualsiasi ambiguità:

query {
  products {
    ...ProductProps
  }
}
 
fragment ProductProps on AwesomeWPSalesProduct {
  price
  dateRange
}Copy

​

Specifica GraphQL

Questa funzionalità non fa attualmente parte della specifica GraphQL, ma è stata richiesta in:

• Issue #163 - Namespaces.