React-hot-loader: Discuss: native TypeScript support?

[elsassph]

The suggestion to add babel-loader, or even completely replace the TypeScript loader is rather disappointing - there surely is another way.

Although the approach is different, because I haven't looked long enough at the Babel plugin, I've implemented native-TypeScript React HMR, using react-proxy and a TypeScript transformer: https://github.com/elsassph/react-hmr-ts

I'll continue looking at the Babel plugin to see whether it can be written as a TS transform but I don't understand it completely yet...

[theKashey]

Don't look how it written - look what it does:

• register all top-level variables
• inject eval into classes (this would not be needed in a future)

Reliable HMR feature based on Dan Abramov's react-proxy,

react-proxy is not reliable. If you want to keep using it - try (react-stand-in)[https://github.com/theKashey/react-stand-in], which is currently used in React-Hot-Loader.

PS: Every day it's harder and harder __not__ to use Babel. Some translation libraries, like js-lingui, or SSR-friendly code splitting requires it. So - why not to use? It does not slow the build time.

[elsassph]

Thanks,

I was looking at the generated code but found really weird the eval injection. Also I was wondering whether that was blanket registering all the exports.

Aside from that thanks for pointing out the react-proxy alternative. Never had issues for the latter but happy to use a more actual one.

Long term it may be an option to use Babel but I can't swap it atm, and surely I don't feel like pulling a second JS transpiler and double the JS processing "just" to add a few code tweaks which TS is now able to do natively since around 2.4.

Well I'll have a go at a transformer then :)

[theKashey]

So - the only difference between babel and webpack plugin (in this scope) - injecting eval to classes to be able to update arrow functions if they are not transpiled, or just inject something in the same function scope.
That's something we have to do, to make onClick handlers work. And that's something we __shall not do__, as long as function scope is invalid. It's like a dead end. Finita la comedia. See v5 for details - https://github.com/gaearon/react-hot-loader/issues?q=is%3Aopen+is%3Aissue+milestone%3Av5

I am looking forward to overtake this limitation, and then only simple _top level variables registering_ would be required (to remove false positives during updates). And yes - transformer also would be not needed.

[elsassph]

I'm thinking the arrow functions fields could be rewritten before generation into bound prototype functions which the proxy can update.

[elsassph]

So I've progressed well in my implementation and we're trialing it internally on a sizeable production codebase.

I changed the language to recommend aliasing react-proxy with react-stand-in when targeting ES6 (we still default to transpiling to ES5).

Also I've revised the API and could offer to further make it drop-in compatible with RHL runtime, because my transformations are now comparable. I transform the arrow function fields so they can be updated by the proxy.

Are you open to RHL project proposing a TS transformer or do you want to enforce Babel?

[theKashey]

My current stack is TS -> ES6 -> Babel -> ..., I dont use "Babel TS", which is _recomended_ in the README, and open to any variants.

I just thought the there are no _transformations_ possible for TS - could you share some docs?

[elsassph]

There is almost no documentation and blog posts about it for sure:

• https://github.com/Microsoft/TypeScript/pull/13940
• https://43081j.com/2018/08/creating-a-typescript-transform
• https://blog.scottlogic.com/2017/05/02/typescript-compiler-api-revisited.html

And of course you can look at my implementation:
https://github.com/elsassph/react-hmr-ts/blob/master/lib/transformer.ts

[elsassph]

I'm much simplified my implementation and adjusted the language (hmr->hot), so the module has a new name now: https://github.com/elsassph/react-hot-ts

[theKashey]

What do you think about moving it to hot-loader/typescript?

[elsassph]

What is that?

[elsassph]

Oh that's the react-dom patching approach you mentioned. Is it? It kind of lack description. Does it replace patching createElement?

[theKashey]

No, it's just an organization I've created to distinguish _hot_ stuff.