Alors elle donne pour le membre qu’on recherche:
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.
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.
Avec VueJS, ce n’est pas un problème 
Regarde par exemple, la preuve de concept qu’on a commencé à faire avec notre première requête graphQL 
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.
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.
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
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 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.
Désolé, c’est un terme mathématique, utilisé notamment en algèbre, mais aussi informatique (Réusinage de code — Wikipédia).
j’avais cru que c’était comme la factorisation en maths
genre a x b + a x c = a.(b + c)
Ça a l’air plus large comme définition.
Ben oui, c’est pareil. On n’écrit qu’une fois une partie qui se répète.
Duniter semble forker sur coinduf.eu. J’ai essayé de réparer, mais ça n’a pas l’air d’avoir marché. Quelqu’un peut jeter un coup d’œil ?
@gerard94 pour éclaircir le problème soulevé ici (Plus de 100 certifications?), j’ai cherché à avoir le point de vue de WotWizard. Est-il possible de modifier cette requête pour obtenir le résultat au bloc 262773 ?
{
idSearch(with: {hint: "PiNguyen"}) {
ids {
uid
hash
sent_certifications {
to {
uid
}
block {
number
}
expires_on
}
}
}
}
Pour l’instant, non. Mais les données existent et il suffit de les organiser. Peux-tu reformuler ta demande pour envisager un outil de portée plus générale, comme un nouveau système de types GraphQL ?
On pourrait envisager un nouveau type graphql du type « at(block_number) » dans lequel on pourrait insérer toute requête au format actuel afin d’obtenir son résultat à un bloc défini. Par exemple:
at(block: {number: 262773}) {
idSearch(with: {hint: "PiNguyen"}) {
ids {
uid
hash
sent_certifications {
to {
uid
}
block {
number
}
expires_on
}
}
}
}
Ta proposition pose bien le problème, mais me paraît un peu difficile à mettre en œuvre. Je proposerais plutôt que l’argument with de idSearch présente deux nouveaux paramètres facultatifs contenant deux numéros de blocs : after et before. Seules seraient sélectionnées les identités existant quelque part entre ces deux blocs. Ces mêmes paramètres pourraient apparaître dans les appels de Identity.all_certifiersIO et de Identity.all_certifiedIO pour les certifications.
Cela demanderait du travail et du temps. Il faudrait notamment modifier un index important, avec tous les effets de bord possibles qui en résulteraient, et, peut-être, créer de nouveaux index. De plus, le temps de calcul risquerait d’être sensiblement augmenté.
Est-ce que tu penses que ces nouvelles possibilités seront vraiment utilisées ?