Hot Reloading TypeScript component triggers rendering of ancestor TypeScript components
ajcrites opened this issue · 10 comments
I'm not sure that this is directly related to this transformer, but this is quite frankly the best documentation for working with React Native and TypeScript that I can find, so I'm hoping that it can either be fixed in the transformer directly or at least someone has some advice.
It seems like if you make a change to a TypeScript, .tsx component it triggers a render of any ancestors during hot reloading. If you make a change to a .js component, it won't do this -- even if the ancestors are .tsx components.
You can see an example of this here: https://github.com/ajcrites/TsHotReload
Thanks for the report, and for submitting a repro ❤️
This issue slipped off my radar, apologies for that. I'll try to take a look some time this week.
Just had a very quick look, one thing we discovered the other day was that the target and module options in tsconfig.json are important for hot reloading. You need to set both of them as es2015.
Don't have time to test right now.
Thanks so much, seems like that does make it work! I honestly don't really understand the target / module stuff well ... are there any other consequences to changing these?
At the moment, this transformer uses babel as a secondary transpiler, so the only limitation is that the target needs to be supported by the babel config in your project. I'm not aware of any features that TS's most advanced target, ESNext would output that RN's default babel config could not cope with, so maybe it doesn't matter. That could be wrong, or it could change in the future, so es2015 is a safe bet for now.
I should just make the transformer overwrite the target and module options to prevent these issues in the future.
Actually jest / ts-jest (haven't narrowed it down) seem to require commonjs or else I'll get "Unexpected token import" when running tests. It's not a huge deal since I can use a different configuration when testing vs. building, but wondering if you have any insight into that that might help me or others.
Hmmmm good point. I hadn't considered that. I know it's possible to use babel as a secondary transpilation step with ts-jest too, maybe I should encourage that. Otherwise, yes, the two-different-configs thing is easy enough to do. I'm going to leave this issue open to remind me to do something about this.
Jest requires commonjs, not a ts-jest thing.
@GeeWee can you explain a bit more about what you mean or provide an example repo?
I mean that jest requires the transpiled code to be in the CommonJS module format - so in ts-jest we try to ensure that the module format is set to that as the standard, unless the user explicitly overrides it (because they're using babel to do it themselves eg)
Did that make sense?