Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Got RN-Web platform-specific file extensions working manually, how could we automate this? #43

Open
mosesoak opened this issue Feb 6, 2018 · 7 comments

Comments

@mosesoak
Copy link

mosesoak commented Feb 6, 2018

Hi, thanks for this excellent project, makes setting up RN + TS a lot easier!

I've integrated this with React Native Web which supports file splitting by extension (.web.tsx / .native.tsx / .ios.tsx / .android.tsx). However, Typescript doesn't play nicely with that piece of magic.

I opened a similar issue at the RNW repo asking if anyone has the know-how to write a piece of magic that would get this under the hood? Or is this something that's already supportable?

Demo of my (hacky) system: https://github.com/mosesoak/react-native-web-ts-app

@mosesoak mosesoak changed the title Got file splitting working manually... Got RN-Web file splitting working manually... Feb 6, 2018
@mosesoak mosesoak changed the title Got RN-Web file splitting working manually... Got RN-Web platform-specific file extensions working manually, how could we automate this? Feb 6, 2018
@mosesoak
Copy link
Author

mosesoak commented Feb 6, 2018

^ made the repo public 😬

@skellock
Copy link

skellock commented Feb 6, 2018

My brain broke on this problem as well. The packager(s) are pacified, but TS isn't.

Thankfully, I was only writing a proof-of-concept prototype, but here's how I got around this.

Introducing...

Sadly-Typed Components

Say you're building the <Multi /> component.

Make it a directory that has it's contents look like this:

image

index.ts looks like this:

export * from './multi'

But you see how there's no .web.tsx? That's because the web version is .tsx. In fact, you want to not have .native.tsx as long as you can hold out.

For example: here's what most components should strive to look like:

image

Using Sadly-Typed Components

And here's how you use those components:

import { Multi } from "../some/path/to/multi"

Why These Are Sadly-Typed

It forces you to have the same public interface between both platforms. I ran into TS problems as soon I started doing things like: "ohai native component! you get an extra prop!".

TS is unlikely to get a solution to this as conditional imports goes against their whole #static-4-lyfe design.

This whole approach is wrong and you will burn in hell if you do it.

But, if nobody is watching you... this works well.

If you find the right way™, please let me know. I will email you a beer.

@mosesoak
Copy link
Author

mosesoak commented Feb 6, 2018

@skellock cool, thanks for sharing your system! Mine does indeed let you use platform specific extensions, like .web.tsx / .native.tsx. Check out my example repo!

What I'm struggling to figure out is how we could get TS to support this magic, possibly via an npm module. The problem is that prior to compiling to a platform, even if TS was aware of the special imports it still has no idea which path to follow to do its type checking. In reality it would be a union type of all of the various files' contents.

Perhaps I should start discussing this with the TS authors, was hoping to find someone who would know how to write this as a 3rd-party extension.

@ds300
Copy link
Owner

ds300 commented Feb 7, 2018

Sadly-Typed Components

😂

Not sure how to automate this. I think it would require a new TypeScript module resolution strategy which extends node. I imagine the MS folks would be OK with including something like that, they've made plenty of concessions for the React ecosystem already.

@mosesoak
Copy link
Author

mosesoak commented Feb 9, 2018

Cool. I've been able to simplify the system to just use index files without the weird shim file, retry the repo link above to see changes. Closing this issue here since I'd need to take this up with the Typescript team to get further with it

@liamjones
Copy link

@mosesoak Thanks for the workaround, using it for now. Was there a ticket raised on the TS repo I can follow regarding the changes discussed above?

@ds300
Copy link
Owner

ds300 commented Apr 24, 2018

@liamjones I found some discussion here: microsoft/TypeScript#8328

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants