web-dev-qa-db-fra.com

Y a-t-il des inconvénients à utiliser .tsx au lieu de .ts à chaque fois en dactylographie?

Je viens de commencer à travailler sur un projet de réaction avec TypeScript et je me demande ce que je dois faire avec les fichiers de classe ordinaires. devrais-je utiliser des fichiers .ts ou .tsx et je n'aurais alors trouvé aucune raison de ne pas utiliser le fichier .tsx tout le temps, même s'il ne s'agissait pas d'un projet à réaction! Existe-t-il une raison ou une situation spécifique pour laquelle nous ne devrions pas utiliser de fichiers .tsx? Si non, pourquoi l'équipe TypeScript ajoute-t-elle une nouvelle extension? 

javascriptreactjstypescript
44
Ostad

C'est en quelque sorte une convention d'utiliser x à la fin lorsque votre JavaScript est en mode JSX Harmony. C'est-à-dire quand cela est valide:

doSomething(<div>My div</div>);

Cependant, l’extension de votre fichier n’a pas vraiment d’importance, à condition que vos pré-processeurs soient informés de votre décision (browserify ou webpack). Pour ma part, j'utilise .js pour tout mon JavaScript, même lorsqu'ils sont React. La même chose s'applique pour TypeScript, ts/tsx.

42
André Pena

Vous pouvez utiliser tsx au lieu de ts avec très peu de différence. tsx autorise évidemment l'utilisation des balises jsx dans TypeScript, mais cela introduit certaines ambiguïtés qui rendent tsx légèrement différent. D'après mon expérience, ces différences ne sont pas très grandes:

Les assertions de type avec <> ne fonctionnent pas car c'est le marqueur d'une balise jsx.

TypeScript a deux syntaxes pour les assertions de type. Ils font tous les deux exactement la même chose mais l'un est utilisable dans tsx l'autre ne l'est pas:

let a: any;
let s = a as string // ok in tsx and ts
let s2 = <string>a // only valid in ts

J'utiliserais as au lieu de <> dans les fichiers ts également pour des raisons de cohérence. as a été réellement introduit dans TypeScript car <> n'était pas utilisable dans tsx

Les fonctions de flèche génériques sans contrainte ne sont pas analysées correctement

La fonction de flèche ci-dessous est ok dans ts mais une erreur dans tsx en tant que <T> est interprétée comme le début d'une balise dans tsx

 const fn = <T>(a: T) => a

Vous pouvez contourner ce problème en ajoutant une contrainte ou en n'utilisant pas de fonction de flèche:

 const fn = <T extends any>(a: T) => a
 const fn = <T,>(a: T) => a // this also works but looks weird IMO
 const fn = function<T>(a: T) { return a;}

Remarque

Bien que vous puissiez utiliser tsx au lieu de ts, je vous le déconseille. La convention est une chose puissante, les gens associent tsx avec jsx et seront probablement surpris de ne pas avoir de balises jsx, il est préférable de garder la surprise du développeur au minimum.

Bien que les ambiguïtés ci-dessus (bien que probablement pas une liste complète) ne soient pas grandes, elles ont probablement joué un grand rôle dans la décision d'utiliser une extension de fichier dédiée pour la nouvelle syntaxe afin de conserver les fichiers ts compatibles avec les versions antérieures. 

10
Titian Cernicova-Dragomir

La raison pour laquelle l'extension .jsx a été introduite est que JSX est une extension de la syntaxe JS et que les fichiers .jsx ne contiennent donc pas de code JavaScript valide.

TypeScript suit la même convention en introduisant des extensions .ts et .tsx. Une différence pratique est que .tsx n'autorise pas les assertions de type <Type> car la syntaxe est en conflit avec les balises JSX. Les assertions as Type ont été introduites en remplacement de <Type> et ont été considérées comme un choix préféré pour des raisons de cohérence dans les fichiers .ts et .tsx. Si le code de .ts est utilisé dans un fichier .tsx, <Type> devra être corrigé.

L'utilisation de l'extension .tsx implique qu'un module est lié à React et utilise la syntaxe JSX. Dans le cas contraire, l'extension peut donner une fausse impression sur le contenu du module et le rôle dans le projet. Il s'agit de l'argument contre l'utilisation de l'extension .tsx par défaut.

Par contre, si un fichier est lié à React et a de bonnes chances de contenir JSX à un moment donné, vous pouvez le nommer dès le début .tsx pour éviter de le renommer ultérieurement.

Par exemple, les fonctions utilitaires utilisées avec les composants React peuvent impliquer JSX à tout moment. Vous pouvez donc utiliser en toute sécurité les noms .tsx, tandis que la structure de code Redux n'est pas censée utiliser directement les composants React, elle peut également être utilisée. testé en dehors de React et peut utiliser des noms .ts.

3
estus

Je crois qu'avec les fichiers .tsx, vous pouvez utiliser tout le code JSX (JavaScript XML). Alors que dans le fichier .ts, vous ne pouvez utiliser que TypeScript.

2
theITvideos

Les fichiers .ts ont une syntaxe d'assertion de type <AngleBracket> qui entre en conflit avec la grammaire JSX. Afin d'éviter de briser une tonne de personnes, nous utilisons .tsx pour JSX, et nous avons ajouté la syntaxe foo as Bar qui est autorisée dans les fichiers .ts et .tsx.

let someValue: any = "this is a string";
let strLength: number = (<string>someValue).length;

Et l'autre est la syntaxe as:

let someValue: any = "this is a string";
let strLength: number = (someValue as string).length;

Nous pouvons utiliser .ts avec as-syntax mais <string>someValue c'est cool!

0
Arjun Kava