Est-il un inconvénient à l'utilisation .la tsx au lieu de .ts de tous les temps à la machine?

Vous pouvez utiliser tsx au lieu de ts avec très peu de différence. tsx permet évidemment de l'utilisation de jsx balises à l'intérieur de la machine, mais cela introduit une certaine analyse des ambiguïtés qui font de la tsx légèrement différente. Dans mon expérience, ces différences ne sont pas très grandes:

Type d'assertions avec <> ne fonctionnent pas comme c'est le marqueur d'une jsx tag.

Tapuscrit a deux syntaxes pour le type d'assertions. Ils ont tous deux faire exactement la même chose mais on est utilisable dans la 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

Je voudrais utiliser as au lieu de <> dans les fichiers ts pour des raisons de cohérence. as a effectivement été introduit dans la Machine, car <> n'était pas utilisable dans tsx

Générique flèche fonctions avec aucune contrainte ne sont pas analysé correctement

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

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

Vous pouvez contourner ce problème, soit en ajoutant une contrainte ou non à l'aide d'une flèche fonction :

 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;}

Note

Alors que vous pouvez utiliser de la tsx au lieu de ts, je vous recommande contre elle. La Convention est une chose puissante, des gens associent tsx avec jsx et serez probablement surpris d'apprendre que vous n'avez pas de jsx balises, bien de garder un développeur surprise à un minimum.

Tandis que les ambiguïtés ci-dessus (bien que probablement pas une liste complète) ne sont pas gros, ils n'ont probablement joué un grand rôle dans la décision d'utiliser un fichier dédié extension pour la nouvelle syntaxe afin de garder ts fichiers compatible.

La raison .jsx extension a été introduit, c'est que JSX est une extension de la syntaxe JS et donc .jsx fichiers ne contiennent pas de JavaScript valide.

Tapuscrit suit la même convention en introduisant .ts et .tsx extensions. Une pratique, la différence est que .la tsx ne permettent pas de <Type> type d'affirmations, car la syntaxe est en conflit avec JSX balises. as Type affirmations a été présenté comme un remplacement pour <Type> et considéré comme un choix préféré pour des raisons de cohérence dans les deux .ts et .la bourse de toronto. Dans le cas où le code de .ts est utilisé dans .tsx fichier, <Type> devront être corrigés.

L'utilisation de .tsx extension implique qu'un module est lié à Réagir et utilise JSX de la syntaxe. Dans le cas où il ne l'est pas, l'extension peut donner la fausse impression sur le module de contenu et le rôle dans le projet, c'est l'argument à l'encontre de l'aide .tsx extension par défaut.

D'autre part, si un fichier est lié à Réagir et a de bonnes chances de contenir JSX à un certain point, il peut être nommé .tsx depuis le début pour éviter le changement de nom plus tard.

Par exemple, les fonctions de l'utilitaire qui sont utilisés avec Réagissent composants peut impliquer JSX à tout moment et peut donc être utilisé en toute sécurité .la tsx des noms, alors que Redux de la structure de code n'est pas censé utiliser Réagir directement les composants, peut être utilisé et testé en dehors de Réagir et vous pouvez utiliser .ts noms.

.ts les fichiers ont un <AngleBracket> l'assertion de type syntaxe qui entre en conflit avec le JSX de la grammaire. Afin d'éviter la rupture d'une tonne de gens, nous utilisons .tsx pour JSX, et a ajouté l' foo as Bar syntaxe de ce qui est permis dans les deux .ts et .tsx fichiers.

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

Et l'autre est la syntaxe:

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

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