Requêtes GraphQL à WotWizard

Oui, il y a un champ de plus dans “Received_Certifications” : “limit”.

1 Like

J’ai du mal à comprendre quels champs il faut mettre.

centrality marche tout seul

mais quality doit s’écrire:

quality {
ratio
}

1 Like

centrality: Float!

quality: Fraction!

et

"Fraction"
type Fraction {
	
	"Numerator"
	num: Int!
	
	"Denominator"
	denom: Int!
	
	"Value of 'num' / 'denom'"
	ratio: Float!

}

en gros les types de base (Int, Float, String…) sont accessibles immédiatement, mais les types composites définis par wotwizard (Fraction, Identity, Certification…) doivent être déstructurés jusqu’à arriver à des types de base.

1 Like

Ok, merci!

Mais du coup, on peut mettre plein de commentaires au typesystem? Qui agit un peu comme un executable qui a sa syntaxe?

J’avoue que j’ai du mal à voir quels champs mettre pour certains, comme memEnds

Il y a une sorte d’arborescence des questions qu’on peut poser, est-ce que ça s’explique en commentaires?

1 Like

Il y a en effet une arborescence de question à poser et on ne peut pas s’arrêter avant d’atteindre un type de primitif. Mais attention, certaines requêtes ("Query") prennent des paramètres (à ne pas confondre avec les champs des types).

Aujourd’hui j’ai travaillé dessus, et j’ai écrit une requête qui fait quasiment tout ce dont j’ai besoin:

{
  idSearch(with: {hint: "Jerome55"}) {
    ids {
       uid
       pubkey
       status
       sentry
       minDate
       limitDate
       quality {
       ratio
    }
       received_certifications {
        limit
        certifications {
          from {
            uid
          }
          expires_on
        }
      }
       all_certifiers
    {uid
     pubkey
     status
     sentry
     minDate
     limitDate
     quality {
      ratio
    } 
     received_certifications {
        limit
        certifications {
          from {
            uid
          }
          expires_on
        }
      }
     
    }
      all_certified
    {uid
     pubkey
     status
     sentry
     minDate
     limitDate
     quality {
ratio
}
    received_certifications {
        limit
        certifications {
          from {
            uid
          }
          expires_on
        }
      }
    }
    }
  }
} 


{
  idSearch {
    ids {
      uid
      hash
      status
    }
  }
}

Les dates apparaissent pas « en clair ».
En fait « juste » une mise en forme de ça avec des liens déroulants et des couleurs (genre jaune ça va bientôt plus être bon mais ça va orange c’est bientôt plus bon, rouge c’est plus bon, vert c’est bon) serait top!

Je n’ai pas réussi à trouver un moyen simple de voir les limites de certifications comme dans wot-wizard, la catégorie « Identity » de TypeSystem donne une limite d’adhésion (limitDate), mais pas de certification (ou j’ai pas vu!).

(edit: je viens de trouver quelque chose, « limit » sous la catégorie « received certifications »)

J’ai vraiment galéré à mettre ça sous curl, donc mon script n’a pas avancé et j’ai à la place une requête avec presque tout ce dont faisait mon script avant (et même un peu plus!)

4 Likes

Fallait demander :grinning:.

Je veux bien savoir comment on met une date « humaine » dans la requête.

Belle requête ! Bravo :slight_smile: Je m’en servirais bien pour faire une première vue dans Wotwizard-ui et m’entraîner à graphQL. Si je comprends bien, elle récupère les certifications d’un membre sur deux niveaux ?

Tu peux la formatter par programmation ensuite.

EDIT : Sinon, je viens de tomber sur cet exemple : The GraphQL query showing how to format a date! · GitHub

Alors elle donne pour le membre qu’on recherche:

  • son pseudo
  • sa clé publique
  • son statut membre ou autre
  • s’il est référent
  • la date à laquelle il peut envoyer la prochaine certif
  • la date limite d’adhésion
  • la « qualité »
  • un bilan des certifs reçues avec la limite de la 5ème certif et l’expiration de chaque certif

Puis cherche dans les certifés et certificateurs de ce membre, les mêmes paramètres.

Ah oui. Balèze. En réfléchissant, je me dit qu’on pourrait sûrement intégrer tes besoins exprimés dans ce post dans Wotwizard-ui directement. Tu pourrais contribuer au projet en exprimant les vues qui t’intéressent et en rédigeant les requêtes graphQL qui vont bien. Puis, avec @HugoTrentesaux par ex, on se charge de mettre ça dans l’appli. J’ai fait un topic sur le forum utilisateur à ce sujet.

1 Like

D’accord, je vais voir ça, et en parler.

Du coup cette requête répond au besoin que j’avais (à condition de savoir lire la réponse en JSON), mais après c’est la mise en forme et peut-être d’autres besoins d’un client plus global dont il faut discuter (et que ça aille à des gens peu à l’aise), du coup c’est bien d’en parler sur le forum.

1 Like

Avec VueJS, ce n’est pas un problème :wink: Regarde par exemple, la preuve de concept qu’on a commencé à faire avec notre première requête graphQL :stuck_out_tongue:

1 Like

C’est compliqué, les dates humaines. Le nombre de secondes depuis 01/01/1970, c’est beaucoup plus simple. Et tous les langages de programmation ont une fonction pour transformer ce nombre en une date lisible par un humain, et inversement.

2 Likes

Ok, en effet c’est bien il semble y avoir des possibilités!

Quand un même fragment se répète dans une requête, on peut factoriser ces parties identiques dans un “fragment”, qui est un concept bien pratique de graphQL. Tu en as des exemples dans la requête “IntrospectionQuery” que tu as déjà utilisée.

1 Like

En essayant de l’intégrer à Wotwizard-ui, j’ai considéré une page par membre. J’ai donc optimisé ta requête comme ceci (au lieu de requêter all_certifiers, tu aurais pu les intégrer dans received_certifications directement). J’ai aussi utilisé un fragment comme expliqué par @gerard94 :

query Search($hash: Hash!) {
  idFromHash(hash: $hash) {
	...memberAttributes
	pubkey
	isLeaving
	sentry
	minDate
	minDatePassed
	membership_pending
	limitDate
	quality {
	  ratio
	}
	distance {
	  value {
		ratio
	  }
	  dist_ok
	}
	received_certifications {
	  limit
	  certifications {
		from {
		  ...memberAttributes
		}
		expires_on
	  }
	}
	sent_certifications {
	  to {
		...memberAttributes
	  }
	  expires_on
	}
  }
}
fragment memberAttributes on Identity {
  uid
  hash
  status
}

Et je crois que c’est à peu près ce que tu veux :wink:

5 Likes

Oui en effet, j’aurais pu la voir cette redondance!

C’est bien en effet. Cette présentation avec pour chaque certifié ou certificateur des dates en couleur pour dire va bientôt manquer de certifs ou va bientôt devoir renouveler son adhésion ça serait top, et peut-être des infos en plus en survolant avec la souris, pour pas surcharger.

Bon il faut que je réfléchisse à quoi ça doit ressembler, comme il y aura une visio.

Je n’ai pas bien compris @gerard94 ce que c’est la factorisation, mais ça m’a l’air bien.

Regarde mon exemple :wink: C’est ce qu’on appelle des fragments. Ca évite de dupliquer des champs quand tu les demandes plusieurs fois. @gerard94 a aussi posté un exemple sur le forum utilisateur.

ok j’ai compris, et ça s’utilise bien.