Repository navigation
Conversation
|
By analyzing the blame information on this pull request, we identified @odino, @mkonicek and @nicklockwood to be potential reviewers. |
|
My biggest doubt here is that this guy is android-specific. I think we already have something working on IOS so I would prefer to see both working in the same way. Anyhow, let me know what you guys think. |
|
Saw @astreet comments on #6478 (comment) and I agree that regex patterns might be a good, viable solution. Though, what if we need to run cb when a pattern is matched? |
There was a problem hiding this comment.
nope, sorry -- copypasta :)
|
In the example, you have: |
|
This is what I meant -- we could pass some object like this: let routesToIntercept = {
'myApp://some-action': () => console.log(123),
'myApp://*': () => console.log(456)
}
return <Webview
routesToIntercept={routes}
/>and run the cbs based on the route we intercept. But I'm not 100% sure on how to do it in RN -- I might need some help / hints there. The problem I see with my PR is that IOS / android implementations will vary quite a bit, which sucks. So Im open to consider changing the implementation in favor of something that can work longer term. Let me know your thoughts. |
Android devs have been relying for ages on intercepting custom HTTP calls made by the webview, to map them to native actions, [like here](https://www.caphal.com/android/communication-between-application-and-webview/). Say that we have a "close" button in our web interface. We first detect if we're running on web or within a webview -- if on web, we simply call `window.close()`. If we're running within the app things get a bit more complicated, but we can simply call `app://exit` and the app will be able to intercept this call and close the webview for us. Now, this PR adds the ability of doing it on RN. You basically specify a protocol for messages that should be forwarded to RN (ie. `rn`) and then, when your webview loads a resource from `rn://xyz` the `onMessage` callback will be called. You can access the URL etc etc through `event.nativeEvent.url`. Example: ``` javascript let onMessage = (event) => { let {url} = event.nativeEvent; if (url.endsWith('exit')) { BackAndroid.exitApp(); // just sayin'... } } return <Webview source={...} messageProtocol={'myApp'} onMessage={onMessage} > ``` Or something of that sort. Communicating between the webview and RN / the ability to intercept resources loaded within the webview has been already discussed but I feel we need a very simple implementation rather than creating a full-blown messaging pattern which will just hurt (maintainability, complexity) in the long run. Also, my Java is pretty rusty ;-)
0d74c6f to
5bb43b9
Compare
|
@odino updated the pull request. |
|
@odino updated the pull request. |
|
@stereodenis that wont work for legacy implementations that are based on calling custom URLs :) even though I think it's a good solution I was aiming at taking care of the practice of using custom URLs since there's a lot of android + webview implementations that use that method. |
|
@mkonicek would you mind taking a look at this pull request? It's been a while since the last commit was reviewed. |
|
@odino will it be replacement for react-native-webview-bridge? |
|
@stereodenis well, I would like to see a default way to implement some sort of communication between webviews and RN :) |
|
Sorry for the delay on reviewing this - there's now a related proposal using |
Summary: JS API very similar to web workers and node's child process. Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged. I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.  Closes #9762 Differential Revision: D4008260 fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
|
Since the |
Implement a postMessage function and an onMessage event for webviews … Summary: JS API very similar to web workers and node's child process. Work has been done by somebody else for the Android implementation over at react#7020, so we'd need to have these in sync before anything gets merged. I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.  Closes react#9762 Differential Revision: D4008260 fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary: JS API very similar to web workers and node's child process. Work has been done by somebody else for the Android implementation over at react#7020, so we'd need to have these in sync before anything gets merged. I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.  Closes react#9762 Differential Revision: D4008260 fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Android devs have been relying for ages on intercepting custom HTTP
calls made by the webview, to map them to native actions,
like here.
Say that we have a "close" button in our web interface. We first detect
if we're running on web or within a webview -- if on web, we simply call
window.close().If we're running within the app things get a bit more complicated, but we can
simply call
app://exitand the app will be able to intercept this call andclose the webview for us.
Now, this PR adds the ability of doing it on RN. You basically specify a
protocol for messages that should be forwarded to RN (ie.
rn) and then,when your webview loads a resource from
rn://xyztheonMessagecallbackwill be called. You can access the URL etc etc through
event.nativeEvent.url.Example:
Or something of that sort. Communicating between the webview and RN / the ability
to intercept resources loaded within the webview has been already discussed but I
feel we need a very simple implementation rather than creating a full-blown
messaging pattern which will just hurt (maintainability, complexity) in the long run.
Also, my Java is pretty rusty ;-)