What is the difference between .jsx and .tsx?
A .jsx file is plain JavaScript with JSX syntax. A .tsx file is TypeScript with JSX syntax — the same component author surface plus type annotations, interfaces, generics, satisfies, as assertions, and decorators. Renaming the file extension from .jsx to .tsx is the trivial part of migration; the real work is filling in types so the TypeScript compiler can verify props, state, hooks, and event handlers.
How does the converter infer props?
It runs a regex over the source for the pattern props.X — every X that looks like an identifier is collected into a Set. The set becomes an interface Props block with each property typed as `any` and a TODO comment instructing you to replace each `any` with a concrete type. Inference is intentionally shallow: this is a starter skeleton, not a full type-flow analysis.
Why does every prop default to `any`?
Because regex extraction tells us which props are read but not what type they hold. We could guess (a prop named children → ReactNode, a prop named onClick → MouseEventHandler) but those guesses fail in 30% of real codebases. `any` is honest — it surfaces the migration as a TODO in your editor with a clear tag, and a TypeScript-aware IDE will offer quick-fixes once you replace it with a concrete type.
Does it handle destructured props?
Yes — the signature rewrite covers function Foo({ a, b }) -> function Foo({ a, b }: Props). However, props that are read only via destructuring (never as props.X) will not be detected by the regex pass and will not appear in the generated interface. After conversion, scan for unused or missing keys and refine the interface manually.
Does it preserve imports?
Yes. The converter detects the import block at the top of the file (lines starting with import or const X = require(…)) and inserts the generated interface immediately after the last import. Default exports, named exports, and side-effect imports all stay in place, untouched.
Will it convert class components?
Class components are detected via the class keyword, but the converter does not auto-annotate them. The pattern class Foo extends Component<Props, State> requires both a Props and a State interface — auto-generating both reliably is out of scope for this regex-based pass. Convert class components manually after the file extension and Props skeleton are in place.
Will it migrate to React.FC<Props>?
No — current React + TS guidance discourages React.FC because it implicitly adds children and complicates default props. The converter emits the modern function Foo(props: Props) form. If your codebase uses React.FC, run a search-and-replace after conversion.
Is my code uploaded to your servers?
No. Conversion runs entirely in JavaScript inside your browser. JSX containing API keys, proprietary algorithms, or unreleased features never leaves the device. Open DevTools → Network and click Convert to verify no requests are made.