[LinkingIOS] Improve deep linking payload sent to JS on openURL

[arasmussen]

Prior to this commit, just the URL string is sent to JS.

_handleOpenURL(event) {}

where

event = {
  url: 'Scheme://Host/Path?Query=Parameters',
}

This leaves JS to parse the URL when we already have a great parsing
tool (NSURLComponents) in iOS from Apple.

Test Plan - tested the following URLs

1. url = 'reactnative://foo.bar/baz?a=b&c=d'

event = {
  host: 'foo.bar',
  parameters: {
    a: 'b',
    c: 'd',
  },
  path: '/baz',
  scheme: 'reactnative',
  url: 'reactnative://foo.bar/baz?a=b&c=d',
}

2. url = 'reactnative://'

event = {
  host: '',
  parameters: {},
  path: '',
  scheme: 'reactnative',
  url: 'reactnative://',
}

[facebook-github-bot]

By analyzing the blame information on this pull request, we identified @vjeux, @nicklockwood and @tadeuzagallo to be potential reviewers.

[satya164]

_handleOpenURL looks like a private method. So I think we should not specify the name.

[arasmussen]

@satya164 _handleOpenURL is just from the example above, it isn't an internal API or anything. Perhaps I should clear up the wording?

[satya164]

@arasmussen Oh, didn't notice that. But yeah, the wording can be better.

[arasmussen]

Updated, let me know if that's better.

[facebook-github-bot]

@arasmussen updated the pull request.

[ide]

We should do this processing in JS for x-platform support (see https://facebook.github.io/react-native/docs/intentandroid.html and #4546), or even push it into userspace.

[arasmussen]

@ide Ah I see that Android deep linking has similarly formatted URLs. Doing the processing in JS makes sense. Looks like URI.js would work great (besides not parsing out the query params for you).

Though I'd argue that since LinkingIOS is iOS only, this change is still net win until we have a more x-platform deep linking module.

[facebook-github-bot]

@arasmussen updated the pull request.

[facebook-github-bot]

@arasmussen updated the pull request.

[arasmussen]

Another interesting tidbit is that urijs is about 7KB gzipped. Why required the developer to add an extra library when this comes for free in native? It'd be awesome of RN saved you the trouble.

[nicklockwood]

@arasmussen It turns out that the query param parsing part of NSURLComponents is iOS8+ only, so we can't use it. (I replicated it in only a few lines in RCTUtils though, so maybe it still makes sense to do that part natively if the rest of the code is native?)

[nicklockwood]

NSURLComponents.queryItems is an iOS8+ api, and we need to support iOS7+ (We got burned by this once already :-))

[satya164]

@arasmussen Any updates on this?

[arasmussen]

@nicklockwood Thanks for the feedback, definitely agree.

@satya164 Haven't made time for this recently, probably won't be able to for a while. Doesn't seem far from something shippable though. :/

[facebook-github-bot]

@arasmussen updated the pull request.

[facebook-github-bot]

@arasmussen updated the pull request.

[arasmussen]

Don't have time to fix this one up. :/