[Solved]-Is there any downside to using .tsx instead of .ts all the times in typescript?-Reactjs

.ts files have an <anglebracket> type assertion syntax which conflicts with the jsx grammar. in order to avoid breaking a ton of people, we use .tsx for jsx, and added the foo as bar syntax which is allowed in both .ts and .tsx files.

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

and the other is the as-syntax:

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

we can use .ts with as-syntax but <string>somevalue is cool!

i believe with the .tsx files you could use the all jsx (javascript xml) code. whereas in the .ts file you can only use just typescript.

the reason why .jsx extension was introduced is that jsx is an extension of js syntax and thus .jsx files don't contain valid javascript.

typescript follows the same convention by introducing .ts and .tsx extensions. a practical difference is that .tsx don't allow <type> type assertions because the syntax is in conflict with jsx tags. as type assertions was introduced as a replacement for <type> and considered a preferred choice for consistency reasons in both .ts and .tsx. in case the code from .ts is used in .tsx file, <type> will need to be fixed.

the use of .tsx extension implies that a module is related to react and uses jsx syntax. in case it doesn't, the extension may give false impression about module contents and the role in the project, this is the argument against using .tsx extension by default.

on the other hand, if a file is related to react and has good chances to contain jsx at some point, it can be named as .tsx from the beginning to avoid renaming later.

for instance, utility functions that are used together with react components may involve jsx at any point and thus can be safely use .tsx names, while redux code structure isn't supposed to use react components directly, can be used and tested apart from react and can use .ts names.

it's kind of a convention to use x in the end when your javascript is in jsx harmony mode. that is, when this is valid:

dosomething(<div>my div</div>);

however, your file extension doesn't really matter, as long as your pre-processors are aware of your decision (browserify or webpack). i, for one, use .js for all my javascript, even when they are react. the same applies for typescript, ts/tsx.

edit

now, i would strongly recommend using jsx for javascript with react syntax and tsx for typescript with react because most editors/ides will use the extension to enable or not the react syntax. it is also consider it to be more expressive.

you can use tsx instead of ts with very little difference. tsx obviously allows the usage of jsx tags inside typescript, but this introduces some parsing ambiguities that make tsx slightly different. in my experience these differences are not very big:

type assertions with <> don't work as that is the marker for a jsx tag.

typescript has two syntaxes for type assertions. they both do the exact same thing but one is usable in tsx the other is not:

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

i would use as instead of <> in ts files as well for consistency. as was actually introduced in typescript because <> was not usable in tsx.

generic arrow functions with no constraint are not parsed correctly

the arrow function below is ok in ts but an error in tsx as <t> is interpreted as the start of a tag in tsx:

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

you can get around this either by adding a constraint or not using an arrow function:

 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

while you can use tsx instead of ts, i would recommend against it. convention is a powerful thing, people associate tsx with jsx and will probably be surprised you don't have any jsx tags, best keep developer surprise to a minimum.

while the ambiguities above (although probably not a complete list) are not big they probably played a big part in the decision to use a dedicated file extension for the new syntax in order to keep ts files backward compatible.