-
Notifications
You must be signed in to change notification settings - Fork 267
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
React Native Windows support #1007
Comments
I'm currently stuck on a Haste issue. When I launch via Debug UWP, I get this error: :1 - - [28/Jun/2019:23:32:51 +0000] "GET /App.windows.bundle?platform=uwp HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36" I'm trying to reverse engineer metro but having difficulties even just attaching a debugger. |
I debugged the Haste issue with Andrew, we now understand what's going on. The vnext implementation has its own cli.js which overrides the metro config with custom Haste paths, these include the "lib" directory. The "normal" cli.js that comes with react-native doesn't have this override. What this means is we currently only build bundles correctly if we launch metro with our custom version of cli.js. This can produce some confusion as well, as the haste map gets cached in %temp%, and so depending on which cli.js you run first, you'll get either the "correct" haste map or the "incorrect" haste map in the cache. The fix for the haste issue we're pursuing for this is to no longer use the "lib" directory to hold these certain files, instead just use the standard Libraries directory. Andrew already has this change checked in with microsoft/react-native-windows#2727. After that we still have the remaining issue that the vs code extension is looking for index.bundle?platform=windows, instead of app.bundle?platform=uwp. We are considering renaming vnext to windows, but in the short term I think it makes sense to change the bundle URL to app.bundle?platform=uwp. I may attempt this, or have someone on the crew take it from me if I don't have cycles. |
Is this dead? |
Hi @sportshead . It is not dead, just some of the issues are tracked in https://github.com/microsoft/react-native-windows . If you have any questions about React Native for Windows support in React Native Tools extension - please let us know about them. |
I think that it is better to close this issue since the extension can work with the RNW apps with the only gaps of Show DevMenu and Reload App commands which will be added as soon as DevMenu functions will be added in NativeModules. |
Some time ago experimental support for React native Windows was introduced and at that moment debuging of both UWP and WPF platforms were added. Since that time no further work were continued.
Currently, React Native Windows has two main implementations: "current" which is C#-made and will be cosidered as deprecated in the future and "vnext" which is targeted to future React Native versions and will be rewritten in C++ to engage new RN architectural features such as JSI (react-native-community/discussions-and-proposals#91).
Here are the list of things that must be done to support newer React Native Windows versions that were made after retesting extension for RNW apps (
"react-native-windows": "^0.58.0-vnext.101"
):Error: jest-haste-map: Haste module naming collision:
for "vnext" UWP appReproduction steps:
rnw_app_058
directory in VS CodeAttach to packager
debug configuration in drop down list and press play buttonlocalhost:8081/index.bundle?platform=windows
toApp.windows.bundle?platform=uwp
(Issue tracked here on RNW)The RNW application generates app.bundle instead of index.bundle, this causes a prewarming issuesCouldn't run "current" UWP app due to severalSupport for "current" is going away. Is there any documentation about this?Couldn't find source file
errors while runningreact-native run-windows
(Need help from RNW team)Couldn't add WPF platform on new RNW version because looks like it's not supported yet (Need clarifications from RNW team)WPF support is going to be dropped off. Is there any documentation about this?"Attach to packager" scenario doesn't work (Need investigation)Reproduction steps:
debugger-ui
tab is opened and app is loaded, then close Chrome tabrnw_app_058
directory in VS CodeDebug UWP
debug configuration in drop down list and press play buttonDebug Console
windowThe text was updated successfully, but these errors were encountered: