Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add WKWebViewIOS component #10456
This diff adds a new component WKWebViewIOS, which wraps WKWebView.
WKWebView is Apple's recommended WebView and has several advantages over UIWebView (such as speed, due to Nitro). However it does not have feature parity with UIWebView and is missing useful features such as NSURLProtocol support. Swapping out one for the other therefore doesn't make sense. Some existing React Native users may need to stick with UIWebView whilst others may find WKWebView the more optimal choice.
Some promising WKWebView implementations for React Native already exist (such as https://github.com/CRAlpha/react-native-wkwebview). I've tried to follow their structure where possible.
This pull request implements a basic version of WKWebView with an interface that mimics the existing WebView component as much as possible. My intention is to keep this request as small as is practical, incorporating additional WKWebView features over time. (I was on the fence about including onMessage support given that it does bump up the line count a bit).
Not sure what best practices are for testing new React Native components. I've added a new section to UIExplorer for WKWebViewIOS, which demonstrates its functionality.
Looking at similar diffs, @mkonicek do you think you could review this from a JS perspective?
One open question remaining from @jacobp100's comments is maintaining API compatibility with WebView's onMessage. The advantage would be, well, compatibility. The disadvantage would be needing to inject JS. Dunno if you have opinions on that.
Or perhaps even just removing the onMessage stuff to simplify this PR?
Why not make this a separate library that you can install with
referenced this pull request
Oct 25, 2016
I guess my reasoning for putting it in React Native is that this is a very general component that is preferable to UIWebView in most cases but we're prevented from deprecating the current implementation as we can't reach feature parity.
There seems to be broad consensus for taking this approach. See, e.g. #321.
There also seems to be precedent for community-maintained components in React Native. As someone who plans to use this component extensively I'm willing to commit to maintaining it.
Is there a downside to making it a separate module, though? I think the previous consensus that this would make sense in the core happened before separate modules were as fully-featured as they are now. Now that react-native link works pretty well, I believe the ideal strategy is to only put modules in the core when there is a particular reason they should be in the core. @mkonicek is going to spin out some modules, for example.
Hey, thanks a lot for working on this! Please release this as a module to npm - it will be super easy for anyone to use your module thanks to
There are so many high-quality modules out there and we shouldn't merge of all them into the RN repo: https://js.coach/react-native
We're even switching to a 3rd party module as the default implementation of MapView and removing the MapView from the RN repo, check out: #10500
I think @lacker summarized it well too.
For inspiration on how to release this as a library, check out for example https://github.com/EstebanFuentealba/react-native-share and https://github.com/frostney/react-native-create-library
Thanks again for understanding and for working on this!
Good point, if there's a lot of feedback the default WebView in React Native is not good, we should probably deprecate and remove it, same as what we're doing with MapView. And maybe the module in this PR will become the new default?
I understand having code directly in the RN repo increases discoverability but then we'd have to pull in all those other great modules that are on npm, which doesn't scale very well.
By having your own Github repo you'll be able to move faster - the code in the RN repo is synced with the internal fb codebase and you'd need to wait for someone to review changes while you're working on a module.