Sie können tsxstatt tsmit sehr geringem Unterschied verwenden. tsxerlaubt natürlich die Verwendung von jsxTags innerhalb von Typoskript, aber dies führt zu einigen Mehrdeutigkeiten beim Parsen, die tsx etwas anders machen. Nach meiner Erfahrung sind diese Unterschiede nicht sehr groß:
<>Typzusicherungen mit funktionieren nicht, da dies die Markierung für ein jsx-Tag ist.
Typescript verfügt über zwei Syntaxen für Typzusicherungen. Beide machen genau das Gleiche, aber einer ist in tsx verwendbar, der andere nicht:
let a: any;
let s = a as string // ok in tsx and ts
let s2 = <string>a // only valid in ts
Ich würde verwenden , asanstatt <>in tsder Konsistenz als auch Dateien. aswurde tatsächlich in Typescript eingeführt, weil <>es in nicht verwendbar wartsx
Generische Pfeilfunktionen ohne Einschränkung werden nicht korrekt analysiert
Die Pfeilfunktion unten ist in Ordnung, tsaber ein Fehler in tsxas <T>wird als Beginn eines Tags in interpretierttsx
const fn = <T>(a: T) => a
Sie können dies umgehen, indem Sie entweder eine Einschränkung hinzufügen oder keine Pfeilfunktion verwenden:
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;}
Hinweis
Während Sie tsx anstelle von ts verwenden können, würde ich dagegen empfehlen. Übereinkommen ist ein mächtiges Ding, assoziieren Menschen tsxmit jsxund werden wahrscheinlich überrascht sein , Sie haben noch keine jsxTags, am besten keep Entwickler Überraschung auf ein Minimum.
Obwohl die oben genannten Unklarheiten (obwohl wahrscheinlich keine vollständige Liste) nicht groß sind, spielten sie wahrscheinlich eine große Rolle bei der Entscheidung, eine dedizierte Dateierweiterung für die neue Syntax zu verwenden, um tsDateien abwärtskompatibel zu halten .