Discussion :

[Sodium]

Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.
Tu pourrais être un peu moins agressif, d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.

[Marco46]

Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.

Documentation TypeScript sur les interfaces, 1er paragraphe :

One of TypeScript’s core principles is that type checking focuses on the shape that values have. This is sometimes called “duck typing” or “structural subtyping”. In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.

Tu pourrais être un peu moins agressif

Désolé je réponds vite et je vais à l'essentiel parce que j'ai peu de temps et que je ne peux pas laisser des inepties sans réponses sur ce forum quand j'en lis parce qu'il y a des gens qui nous lisent.

Du coup c'est possible que la forme n'y soit pas je m'en excuse.

d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.

A la question initiale pas littéralement ça mériterait un autre sujet mais c'est quand même très lié.

Un défaut courant des devs Java / .NET c'est d'aller vers TS en pensant se retrouver dans le même style de langage. C'est une erreur. Une vraie erreur de débutant. J'ai vu des devs Java se lancer dans Angular sans lire la doc TypeScript en partant du principe que c'était du TS donc ce qui était vrai en Java était vrai en TS. Je crains également que beaucoup de décideurs qui choisissent des stacks J2EE / Angular ou .NET / Angular aillent vers ce genre de stack avec des profils fullstack en pensant faire des économies, notamment de formation sur la partie JS / TS. C'est une erreur et ça peut couter cher en maintenance à l'arrivée.

[Sodium]

En pratique, je me sers effectivement principalement des interfaces généralement pour valider des structures de données JSON... ça n'empêche pas qu'elles ont les même fonctionnalités que dans d'autres langages.

Quant à confondre TypeScript et Java... ça me paraît tout de même assez évident que deux langages n'auront jamais exactement la même syntaxe et logique, je ne vois pas un développeur ayant un minimum d'expérience se dire qu'il va pouvoir installer TypeScript et coder du Java tranquillou.

[Marco46]

En pratique, je me sers effectivement principalement des interfaces généralement pour valider des structures de données JSON...

Tu te sers des interfaces pour valider des données au runtime ?

ça n'empêche pas qu'elles ont les même fonctionnalités que dans d'autres langages.

Ben non puisqu'elles n'existent pas au runtime. Ça ne sert qu'au développeur à la phase de transpilation pour lui dire qu'il essaie de faire rentrer un rond dans un espace prévu pour un carré.

Quant à confondre TypeScript et Java... ça me paraît tout de même assez évident que deux langages n'auront jamais exactement la même syntaxe et logique, je ne vois pas un développeur ayant un minimum d'expérience se dire qu'il va pouvoir installer TypeScript et coder du Java tranquillou.

C'est pas qu'ils n'ont pas exactement la même syntaxe et logique, c'est qu'ils n'ont pas du tout la même syntaxe et logique.

Et je t'assure qu'il y a une quantité pas croyable de devs dits "fullstack" qui pensent pouvoir se passer de lire la doc TS sous prétexte qu'ils font du Java ou du .NET.

[Sodium]

Tu te sers des interfaces pour valider des données au runtime ?

Vu que ce n'est pas moi qui gère le backend c'est bien pratique si le mec en charge oublie de me dire qu'il a changé sa structure de données en phase dev.
Puis c'est pratique aussi pour faire le mappage entre les noms de champs tout pourris de notre bdd du genre srgptg et les miens qui veulent dire des trucs

[Marco46]

Mais l'interface n'existe pas au runtime.

Si ton interface c'est par exemple :

Code typescript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
export interface IMonInterface {
    prop1: string;
    prop2: string;
}

Et que ton JSON contient uniquement prop1, tu n'auras aucune erreur sur prop2 sauf si tu testes manuellement le truc.

C'est uniquement pour déclarer explicitement les contrats de tes paramètres d'entrée et tes retours de fonctions. C'est tout.

[Engiwip]

C'est pas qu'ils n'ont pas exactement la même syntaxe et logique, c'est qu'ils n'ont pas du tout la même syntaxe et logique.

c'est bien beau de mettre en gras et surligner tout en essayant de convaincre mais au final on a une syntaxe proche à 80% et une logique d'abstraction equivalente.

Et je t'assure qu'il y a une quantité pas croyable de devs dits "fullstack" qui pensent pouvoir se passer de lire la doc TS sous prétexte qu'ils font du Java ou du .NET.

c'est un autre pb .
quand j'achete un aspirateur , je ne regarde pas forcément la notice. çà doit marcher comme tous les autres aspirateurs. puis au final c'est bien plus intuitif de jouer avec et regarder le manuel après.

TS fait de l'objet assez proche de Java avec les meme concepts.
On peut etre en désaccord sur les buts recherchés de chacun mais c'est un autre débat.

[Marco46]

c'est bien beau de mettre en gras et surligner tout en essayant de convaincre mais au final on a une syntaxe proche à 80% et une logique d'abstraction equivalente.

[...]

TS fait de l'objet assez proche de Java avec les meme concepts.

Ah bah carrément pas. Typage structurel d'un côté, nominal de l'autre, sans aucune info de typage statique au runtime pour TS le contraire pour Java, fonctions first-class pour TS, les classes comme brique de base pour Java, ...

Ça fait déjà de très très grosses différences.

(EDIT :Et je parle même pas de la gestion de l'asynchrone qui est catastrophique avec Java, on pourrait parler aussi de l'event loop JS que l'on soit browser side ou server side contre la gestion en threads côté Java, fin bref ... Les différences sont très nombreuses et fondamentales.)

c'est un autre pb .
quand j'achete un aspirateur , je ne regarde pas forcément la notice. çà doit marcher comme tous les autres aspirateurs. puis au final c'est bien plus intuitif de jouer avec et regarder le manuel après.

J'ai bien compris que tu voulais utiliser TypeScript sans lire la notice. C'est bien le problème

[Engiwip]

Ah bah carrément pas. Typage structurel d'un côté, nominal de l'autre, sans aucune info de typage statique au runtime pour TS le contraire pour Java, fonctions first-class pour TS, les classes comme brique de base pour Java, ...

En pratique, le nez dedans ce n'est pas si important. vraiment. je dis pas de faire un projet opengl avec non plus hein?

(EDIT :Et je parle même pas de la gestion de l'asynchrone qui est catastrophique avec Java, on pourrait parler aussi de l'event loop JS que l'on soit browser side ou server side contre la gestion en threads côté Java, fin bref ... Les différences sont très nombreuses et fondamentales.)

on s'egare de la discussion , on ne compare pas Node avec J2ee....

J'ai bien compris que tu voulais utiliser TypeScript sans lire la notice. C'est bien le problème

la notice quelle notice ?