Reprise du message précédent :

export type Document = Order | Estimate | Invoice;

const getClient = (document: Document) => {
 
if (document.contact) {
return document.contact.firstname
}
 
return document.clientFirstname // Property 'clientFirstname ' does not exist on type Estimate
 
}

Le problème vient du fait que contact peut être falsy tout en existant, donc le compilateur ne peut rien conclure du test if (document.contact). Il suffit je suppose de changer le test en !== undefined

 
Le problème est sur la ligne de la fin. Le code fonctionne, c'est juste typescript qui connait pas clientFirstname sur Estimate donc me lève une erreur, mais sinon ça fonctionne.
 
Du coup à moins de cast en type Order la dernière ligne, je sais pas si y'a mieux.

export type Document = Order | Estimate | Invoice;

const getClient = (document: Document) => {
 
if (document.contact) {
  return document.contact.firstname
}
 
return document.clientFirstname // Property 'clientFirstname ' does not exist on type Estimate
 
}

Mais "contact" est sur tous les types? Il est censé se passer quoi s'il est à `null` sur un `Estimate`, ça renvoie implicitement `undefined`?
 
Sinon tu peux ptet checker `"clientFirstName" in document` ou `typeof document.clientFirstName !== 'undefined'`. Ou bien par un moment je pense que `document["clientFirstname"]` ne checkait rien, je sais pas si c'est encore le cas.

Ca m'intéresse si tu trouves.  

Jokes are supposed to be funny

Pourquoi t'implémentes pas une méthode getClient dans tes objets ? J'ai l'impression que c'est monté à l'envers non ?

Contact est sur tous les types oui. Mais on pourrait imaginer un monde où il ne l'est pas et que je me retrouve avec le même type d'erreur. Et il ne peut plus être pas être à null.
En fait au début de l'appli, les attributs du client était dans un seul type de document (Order) et ils servaient juste pour imprimer un PDF. Maintenant il existe une table Contact et donc une vraie relation qui va avec.

Ma fonction d'exemple regarde juste si il existe la relation, sinon c'est que c'est un vieux document, donc on recup les infos via les anciens attributs.

Du coup, c'est pas le code le problème, c'est juste la compilation si je type le document. Le code fonctionne très bien sans le typage.
Donc le typeof ne règle pas le soucis car typescript me souligne le problème dans le typeof.
Par contre le document["clientFirstname"] est assez étrange. Ca fonctionne dans mon ide, TS me dit rien, mais quand je test sur le playground online, il me sort une erreur.

Parce que en fait mon type de document c'est l'entité en BDD et que la méthode getclient que j'ai donné en exemple n'existe pas. En vrai c'est une fonction qui me retourne un objet spécifique pour formatter un PDF via pdfmake.

Faut mater la vidéo du lien

je reviens juste de dépouillement
je ferai un truc comme ça :
https://www.typescriptlang.org/play [...] xJ9gpdoiAA

return (doc as  Estimate).contact?.firstname ?? (doc as Order).clientFirstname
//  éventuellement en coupant avec un if / else si tu trouve que la ligne est un peu longue
let estimate = doc as Estimate
if(estimate) {
   return estimate.contact.firstname // pas besoin de ? ici, on sait qu'order à un contact
} 
return (doc as Order).clientFirstname

Pourquoi ça ? Qu'est-ce qui te fait dire que cette propriété existe, alors qu'elle n'est pas dans le type que tu déclares ?

Si tu sais des trucs que tu dis pas au compilo, tu n'as pas d'autre choix que de lui dire d'aller se faire foutre avec un cast.

il vérifie que contact n'est pas falsy, donc avec le duck typing, ça passe

return (doc as  Estimate).contact?.firstname ?? (doc as Order).clientFirstname

Oui du coup il n'y a pas mieux que de faire du "as". Je cherchais un peu un truc magique plus haut dans la définition du type ou via autre chose. Merci en tout cas.

C'est compliqué de forcer le typage partout dans ce genre de cas. Car mes types de documents ont pas la même structure, je m'assure d'un if/else pour que mon code fonctionne, mais le typage ne plait pas à Typescript. Du coup si tu veux forcément typer tes variables mais que tu as une fonction un peu bateau avec des if/else selon la structure, t'es obligé de cast dans tous les sens. Ce qui est logique en soit, je m'attendais juste à un truc un peu plus sexy.

Parce que j'ai plusieurs tests avant, à la création d'un doc, il y a forcément une relation qui est créé via Contact. Mon exemple de code là c'était pour expliquer simplement le problème mais ça ne reflète pas vraiment la réalité, c'était juste pour catch des vieux documents qui ont forcément un attribut clientFirstname.

À ce compte là, plutôt qu'un cast perso je ferai document.foo ?? ''

C'est tout aussi dégueulasse mais ça évite les effets de bords du cast. (ça demande de rajouter foo explicitement sur les types de documents, en tant que propriété optionnelle)

alors je suis une bille en typescript, je commence juste à lire la doc en prévision d'un prochain poste . Il y a probablement plus élégant
là c'est juste une solution rigoureuse ( mais un peu trop verbeuse à mon gout)

Vu que les types sont des entités de bdd, ça va me créer des attributs inutiles en BDD.

Ou alors je rajoute un typage perso qui étend le type de base mais bon.

Excellent

export type Document = Order | Estimate | Invoice;

const getClient = (document: Document) => {
 
if (document.contact) {
  return document.contact.firstname
}
 
return document.clientFirstname // Property 'clientFirstname ' does not exist on type Estimate
 
}

je suis pas un expert Typescript, mais en C# (qui est proche de  TS), je ferais un truc du genre :

if (document.GetType == typeof(Order)) {
   return document.clientFirstName;
} else {
   return document.contact.firstName;
}

edit: je sais que j'aurais pu utiliser un opérateur ternaire, mais je déteste ça ! j'ai toujours trouvé que ça rendait le code moins facilement lisible

Alors que mettre plein de return c'est plus lisible

 
Moi j'aurais juste dégagé le else{} inutile

if (document.GetType == typeof(Order)) {
   return document.clientFirstName;
} else {
   return document.contact.firstName;
}

Comme dit plus haut, c'est pas le code le problème (ça compile très bien et ça fonctionne) mais le fait que Typescript dise qu'il connait pas cette propriété dans un des Type. Du coup je peux ajouter 12000 if/else, ça change rien.

je suis d'accord que c'est pas génial non plus, mais ça a au moins le mérite de permettre de visualiser le flow du code de façon un peu plus lisible que le ternaire
 
 

oh bordel, oui
 

 
Comment t'as pu passer à côté vu la taille de ton écran

j'ai passé un week-end difficile, chuis cassé de partout et j'ai trop de courbatures pour tourner la tête

 
Dans le cas où le ternaire est utilisé pour choisir entre deux valeurs, le flot de code est suffisamment trivial justement

Certes, mais Typescript ne dit rien du tout, c'est toi qui lui dis que cette propriété n'existe pas en lui donnant des types faux !

Certes, mais mes Types sont bon. Enfin c'est là tout le sujet de ma question : si j'ai une fonction qui prend plusieurs types de documents (donc qui ont des structures un peu différente), comment tu gères ce cas.

Pour le moment je vois 4 choix :

1. Avec un cast :

2. Avec un type custom :

3. Avec un check de type :

4. Différent du 3 mais qui marche :

Le 2 est à chier, le 1, 3 et 4 me paraissent pas mal et je demandais s'il existait une autre manière de faire.

Edit, ajout du 4.

yeah, nouveau traitement médical, 4 ème en un an \o/

 
Le 1 me semble tout à fait approprié.

Ça me semble correct. Effectivement c'est chiant d'écrire des type guards sur des objets dont on veut vérifier si ils ont une propriété. C'est pour ça qu'avoir des interfaces faciles à discriminer c'est chouette (avec un enum "Type", ou toutes les propriétés présentes mais de type undefined pour les interfaces qui ne l'ont pas), mais bon puisque tu ne contrôles pas tes interfaces, les deux choix me semblent acceptables, je suis d'accord avec toi que 2 c'est naze.

C'est un cast c'est jamais approprié.

Pourquoi ?

Du coup comment tu gères une route avec Express qui a mass attributs dans le body ou dans la query (genre un formulaire) ?

C'est la manière la plus simple que j'ai trouvé dans ce cas.

En théorie Request#body devrait être typé  RequestBody(Type) de base non?

De base c'est écrit ça : Request<ParamsDictionary, any, any, QueryString.ParsedQs, Record<string, any>>.body: any

Du coup j'ai tout en type any. Mon cast me permet d'avoir de vrais type du coup.

Je retire ce que j'ai dit, quand on n'a pas le choix on n'a pas le choix. Quand on interprète des données brutes, il faut bien les caster en entrée, c'est le meilleur endroit pour le faire (le plus tôt possible).

Après note bien que c'est pas parce que c'est pas approprié que je pense qu'il ne faut pas le faire. Dans ton cas, je pense que c'est défendable vue la verbosité de l'alternative sûre.

Après pour les détails, j'ai jamais pratiqué Express.

ok merci.

Sauf que afaik les casts typescript dont pas vérifiés (sur any/unknown). Ça déclare juste que la valeur est du type X sans se poser plus de questions.

Je boycott prime day pour la peine !

Oui, selon la confiance qu'on a à ce moment dans les données qu'on traite on doit vérifier que le type correspond. Avec des protobufs qui viennent de backend connus c'est en général pas un problème, le format a été conçu pour ça.

 
Le perso parfaitement caricaturé dans South Park quoi…
 

c'est pas sympa pour ceux qui perdent leurs cheveux  

 
J'aime beaucoup la pétition pour ne pas autoriser son retour sur Terre.

C'est exactement la réponse de ma meuf (le lien vers la pétition) quand j'ai envoyé le bout de texte cité de Jubi