Add React Native support

[mjackson]

We should introduce a createNativeHistory method that creates a history object that can be used with React Native. Instead of sessionStorage, a native history should use React Native's AsyncStorage module to persist state.

[ryanolsonx]

I've been working a lot with AsyncStorage lately in React Native. I might want to give this one a go.

[mjackson]

@ryanolsonx That would be great! Thank you!

Probably the trickiest piece of this will be incorporating some tests. I know that Travis is able to run tests for Objective-C code, but I'm not sure if that will work for React Native or not.

@ryanolsonx Do you have any experience running automated tests with React Native?

[mjackson]

On second thought, @vjeux wisely suggested that we just mock AsyncStorage and go from there.

Shouldn't be too difficult! #famouslastwords

[ryanolsonx]

Alright, sweet. I'll look into adding the support for React Native and adding those tests with a mock AyncStorage. Here's to hoping it's not too difficult ;)

[ryanolsonx]

I probably won't have too much time to work on this issue during this week and so if anyone else has time and wants to pick it up, feel free.

[threepointone]

I took a crack at implementing a mock asyncstorage object https://github.com/threepointone/asyncstorage-mock hope this helps, let me know if I can fix/change anything.

[mjackson]

Looks great, @threepointone! We can probably use that...

[mjackson]

I just pushed a partial implementation. AFAICT, the private getCurrentLocation method needs to be async in NativeHistory because AsyncStorage forces us to readState asynchronously. This won't change the other implementations much. They'll still execute synchronously. It only changes the signature of getCurrentLocation.

[brentvatne]

👍 exciting to see that this is in progress, will keep an eye out for any way I can pitch in here

[threepointone]

anything I can do to help here? plsthx.

[grabbou]

@mjackson Been recently going through the codebase to see the latest updates on the React Native solution. Would you mind giving a quick update on where we are? I've tried few potentially good approaches to implement React Router in Native, but that was before history/React Router 1.0 were announced, so no longer applicable. If there's no major work being done at the moment, I am happy to take it over and re-submit a new pull request in approximately a week or two (too many #confrences soon to invest more time unfortunatelly)

Speaking test-wise, I am successfully using CircleCI iOS beta feature to run both unit and automated tests as well as build and ship the bundle to the App Store, so I think that can work quite nice. But probably best to just mock the storage implementation by either using Jest or fake object we ship with and then, just use good old mocha to test things out.

The only disadvantage of having such implementation of router in React Native I can see for now is having ability to do these native UINavigationController like animations, like push pop and presentModally. I think it might be quite handy to realease rackt/router-animations library or something just to provide users with a built-in methods.

[grabbou]

There is also a very nice thing about Settings API that's currently private (I guess, @brentvatne ?) as it stores all the things in NSUserDefaults which makes it super easy to access the elements from Native code, e.g. user preferences or opt-in/out for newsletter. I think that it's worth checking the performance in such case as I can see few benefits of having such ability.

[mjackson]

AFAICT @grabbou nobody is actively working on this.

React Router 1.0 doesn't have anything to do with managing history state. Instead, all that is the responsibility of this library (history). In theory, React Native support should be as easy as adding a createNativeHistory method here that conforms to the same API and then just using that on a native device (instead of browser history).

One of the major native-specific features I'd like to implement would be confirming transitions using UIAlertView on iOS < 8 and UIAlertController on iOS 8 (see also my comment here).

[grabbou]

Yep, that's one of the things I really like in latest release. Should be pretty straight forward.

Confirmation-wise, I guess it's just a matter of using either AlertIOS or AlertAndroid once it's released like below:

AlertIOS.alert(
  'Are you sure?'
  [
    {text: 'Yes', onPress: () => ...},
    {text: 'No', onPress: () => ...},
  ]
)

without worrying about breaking iOS8 changes to UIAlertController etc.

Few weeks ago I've been thining about shimming window.alert and window.confirm in React Native, but since the confirm is syncronous in browsers, there's no way to replicate such functionallity.

[taion]

I would split this out into a separate project. While we can make a createNativeHistory that behaves similarly to the web ones, it wouldn't be all that useful.

One main, distinct, challenge of mobile routing and history management is that there isn't a single history stack, but rather multiple stacks that are parallel and/or hierarchical. Following something like remix-run/react-router#743 (comment), an abstraction that offers an interface that works for native app development needs to have a different API.

We cannot abstract away the differences between web and mobile because the expected navigation/history paradigms are fundamentally different.

We're fine to leave the note in the README as-is, but making a createNativeHistory that replaces sessionStorage with AsyncStorage is solving the wrong problem.

[taion]

I'm going to close this issue as out of scope, and in light of further discussion on React Router. Replicating a web history API does not seem like a route that gets us to a general mobile routing solution.

When we get a chance, the right move would be to spin up a separate native-history library that offers a similar enough API to interoperate with something like React Router, while supporting mobile history paradigms rather than web ones.

Let's continue the discussion on remix-run/react-router#743 as needed.