864 karma · joined June 18, 2017
Maybe the Chrome/Firefox DevTools don't, but the standalone React DevTools most definitely depend on WebSockets. My custom React renderer can't connect to them without shimming in a WebSockets implementation, for example.
https://github.com/facebook/react-native/issues/10027
The issue has been locked and is still open.
https://github.com/shirakaba/nside
NativeScript is a project to provide bindings for all native APIs (in the case of iOS: UIKit, AVFoundation, etc.) to a JavaScript context.
I have many more cool examples to share in time! Really surprised that NativeScript hasn't taken off in the same way that React Native has.
The macOS version is built in React Native, using the react-native-macos community project. I write the code in Swift (for native) and TypeScript (for the React Native JSContext). Ideally I'd have liked to have delivered a click-to-OCR feature, but saving a copy of the file (hence the drag-and-drop) was the only way I could find to overcome both:
* CORS issues, with loading the image data into Tesseract; and * the App Transport Security policy, which prevents mixed content in-browser and HTTP downloads by NSURLSession.
As a bonus, though, this methodology supports OCR of files dragged in from the file system.
Happy to talk about any part of it. Always striving to make foreign-language websites more readable.
Not Electron involved at all. The point of RN is that it is native; no overhead of running headless Chromium. The fact that Microsoft are putting their weight behind it means great things for RN, desktop, and macOS. They say they've finished rewriting most of their core apps with RN; this is the first indication of the codebase they likely used to target macOS. It's come out of nowhere, too: there's a same-named repo with 14k+ stars, for comparison.
See my full narrative, explaining why 'quietly' in the original thread: https://news.ycombinator.com/item?id=17728515
They've revealed that they're using RN for all their main products now, but never explained how they were targeting macOS. This is the repo they must have been using; and surprisingly, it's unrelated to the repo of the same name that has 14k+ GitHub stars.
What's brilliant too is that they are indeed open-sourcing it.
https://news.ycombinator.com/item?id=17728515
Check the 0.51-macos branch if you missed it; it's got ~350 changed files specifically to support macOS.
HN title lengths are very restrictive, so perhaps it was unclear, but what I was trying to say was that this repo is likely receiving merges of the very same codebase that Microsoft is using to build their RN Mac apps. This is the first indication of which fork they're using for it (and it's surprisingly not derived from the fork that has 14k+ stars!).
https://news.ycombinator.com/item?id=17728515
Pretty shameless.
I asked for clarification on how they were approaching macOS support in React Native, both:
1) in that Twitter thread (to no answer): https://twitter.com/LinguaBrowse/status/1006834843416657920
2) and in the subsequent Reddit discussion: https://www.reddit.com/r/programming/comments/8qqhlz/office_... (to an answer ignoring the macOS part of my question).
Microsoft are clearly going all-in on React Native:
1) TypeScript 3 has plenty of oddly React-specific features (e.g. defaultProps and PropTypes support): https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...
2) react-native-windows is thriving: https://github.com/Microsoft/react-native-windows
3) WinObjC is looking formidable: https://github.com/Microsoft/WinObjC
I think the future is bright for Microsoft, cross-platform development, and the React universe..!