-
Notifications
You must be signed in to change notification settings - Fork 78
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
transform JSX.Element to React$Node or React.Node #76
Comments
Yeah, I agree 👍 |
The current output is pretty broken in many ways. Desired output for above would be roughly something like this:
So there are actually quite a bunch what needs to be mapped from TS to Flow when transforming component definitions. How would you approach implementing better React support? |
@villesau I tried |
And it's roughly same as |
@villesau its not jsx props, they should be camelCase. Someone should pick up this PR facebook/flow#6727 to typecheck native elements first |
On the other hand in the mean time this should be sufficient: https://github.com/facebook/flow/pull/6727/files#diff-ce626ccb6b8eb922c17388db8d33cbabR281 |
Fixed in #77 |
@villesau but this is types from PR :) |
Yeah exactly. If it's not yet part of Flow builtin libdefs, it's still possible to type without. |
Hi, great work with Flowgen!
I tried to convert some React component definitions yesterday that has
JSX.Element
types. I think proper way to handle these types is to transform them to React$Node or React.Node automatically instead of global$JSX$Element. I think it's safe assumption in Flow since Flow assumes all the JSX to be React anyways, which means only JSX you can have in Flow codebase is React. Where this kind of logic would belong in the code base if I would want to give it a try?Here is an example input and output of current behaviour:
Input:
Output:
The text was updated successfully, but these errors were encountered: