This has a feel of it solved a race condition due to scheduling something on a few ticks later. So it might accomplish not only running something on the main queue but also sneakily after something else finished. For example if you call something like this at the end of view did load, other code that also runs on the main thread may run before it. It's async.
Having said that, it kind of feels hacky. I have certainly seen this in various codebases and I can't comment on react native but just with standard iOS programming it often points to a lack of understanding of lifecycle or similar order of when things are happening.
Isn't this the standard "Let the queue pump events" technique for dealing with the async UI elements in iOS that don't always behave like you expect them to - such as the system alerts? I mean, I'm not justifying this code, which looks quite weird, but one of the reasons for it may be that the framework has to allow events to pump through the iOS queues, such that events propagate all the way through to the system alerts ..
I think it's probably related to issues that arise when performing view actions/animation in the RN equivalent of `-viewWillAppear:` while segue animations are playing. (Short version: it occurs because the RN JavaScript execution thread is asynchronous.)
A concrete example of a problem I had was when setting a text field to be first responder when displayed. The result was that the keyboard was trying to appear a split second after the push segue animation fired.
(IIRC you can reproduce it fairly trivially in a pure native app by calling `-becomeFirstResponder` asynchronously inside a `viewWillAppear:` block. The result was two animations fighting for screen layout, and a giant white empty block where the keyboard should be.)
The solutions were to: a) wait, or b) fire synchronously in `-viewWillAppear:`. Airbnb seem to have chosen a).
I've definitely seen an animation issue where the typical _async -> main didn't work, but _after (0.001 seconds or so) on main did. Though I don't remember if it was on Mac or on iOS, or really what the issue was.
Those animation issues pop up often, and you can get around them by using DispatchQueue.main.asyncAfter(.now() + 0.1) but often you can figure out what the actual issue is (i.e., you're likely attempting to present something in the wrong place) and you should do that instead.
That's a horrible fix, introduces jank, and doesn't work cross device.
You normally want a CoreAnimation completion block ([CATransaction setCompletionBlock:^(){}], with an enclosing [CATransaction begin] and [CATransaction end].
The problem with all the JS based navigation stacks for React Native (react-native-router-flux, react-router, React Navigation) that I have tried is that if you need to have a back stack, they keep the previous scene in memory. i.e if you look at the 3D view hierarchy in XCode you will see the screen prior to the one you pushed.
This really sucks for overdraw perf and completely breaks accessibility on Android. See:
This was a pretty interesting presentation at React Conf. Basically, the Airbnb app started off being totally developed in native code, and they only added React Native later on, so it was really important that their navigation solution be able to handle transitions between screens implemented in native code and screens implemented in React Native.
I liked Leland's metaphor of calling apps like Airbnb which started out without React Native as "brown field" development and calling apps that start out as React Native "green field" development.
> I liked Leland's metaphor of calling apps like Airbnb which started out without React Native as "brown field" development and calling apps that start out as React Native "green field" development.
FWIW those are pre-existing industry terms (not React Native or mobile specific)
I'm seeing a lot of people being confused with many of the comments in React Native posts. Some people in these comments now aren't sure if the "right" navigation solution is React Navigation or Native Navigation. I think a good document to follow to understand Facebook's plans with the project is React Native's Roadmap [1].
In there you'll see that React Navigation is a solution aimed at "Green Field" projects (as Leland Richardson from Airbnb calls new React Native projects) and replaces Navigator, Navigation Experimental, and Ex-Navigation. On the other hand, Native Navigation is aimed at "Brown Field" projects (like Airbnb's app, which was built in native much before React Native was open sourced) and replaces NavigatorIOS.
You can also see that various features in the roadmap are in collaboration with other organizations (Expo for Create React Native App and Airbnb for React Native Maps).
Indeed React Native has been moving extremely fast but after our decision to go with it over a year ago we've never thought even once about going back.
Congrats to the team at AirBnB on the exciting launch! As somebody who has thought a lot about navigation on React Native, I'm super excited to see an easier way to utilize the native navigation views on each platform.
React Navigation, released a few weeks ago, includes a customizable JS re-implementation of the native views, and it also provides routers that make it very easy to plug your navigation logic into redux. Because each screen makes no assumption about the surrounding app, it will be very easy to switch from React Navigation to AirBnB's native-navigation.
The RN community has been consolidating efforts between several navigation solutions. React Navigation is an alternative to Navigator, Ex-Navigator, NavigationExperimental, and Ex-Navigation. And now, thanks to native-navigation, the community has a great alternative to NavigatorIOS.
React Navigation is a module for React (which has been around for four years). Instead of having to DIY navigation, you now can use the native system's (iOS/Android) navigation layout. Ex: https://reactnavigation.org/
You're not replacing your tools. You're just getting someone else to coat your drill bits for you to save time.
I just started using React today, so I may be off here, but I think it's pretty straightforward if you googled it.
Otherwise, if you're referring to how "bleeding edge" the guy has to be, I'd imagine he's in a competitive field (or passionate about his projects).
Hell, I'm not in either of those categories, but I think I'll start using this because it looks really helpful.
There you go again. You're saying 'several months' like someone else might say "years."
These are insanely short time-frames. (Which is what I was pointing out.) These developers are adjusting much, much more quickly than other developers in other domains. That's all I was pointing out :)
Native navigation is definitely a great addition to the community. It's good to see a company, like Airbnb, driving its feature development by their use-cases. Having such a solution in production, used at such scale, is definitely going to secure stability of navigation - something that we were missing for quite a while.
React Navigation seems to be the framework that is endorsed by the react native team. However, Airbnb's React Native Navigation library seems to be more proven since they had been using it in production. I am wondering if anyone know what are the benefits of using React Native Navigation vs React Navigation
My team is in the process of swapping out the navigation stack in one of our apps (we are going with the one from wix for now). Something you might want to consider is the following (copy pasted from my other comment):
"The problem with all the JS based navigation stacks for React Native (react-native-router-flux, react-router, React Navigation) that I have tried is that if you need to have a back stack, they keep the previous scene in memory. i.e if you look at the 3D view hierarchy in XCode you will see the screen prior to the one you pushed."
The docs for airbnb's new navigation stack says the following:
"React Native Navigation by Wix engineering is an alternative library that uses "Native" navigation components of each platform, and has been around longer than Native Navigation. If you need a stable / production-ready navigation library today that uses native platform based navigation components, we recommend you check this library out."
They also claim they are not using this library in their main app yet.
I'll be writing up a blog post about my experiences with the wix nav stack migration once we get our app out.
It's a shame the situation around navigation stacks with React Native is so confusing right now.
React Navigation seems to be the framework that is endorsed by the react native team.
The React Native team respects Airbnb's work here a lot as well. I think we will end up with an "official recommendation" that says each of react-navigation and native-navigation is better for a different set of use cases. It's probably too early to figure out precisely what the line is.
Roughly, react-navigation is more customizable, native-navigation works better for native <-> RN transitions, and they should each be easier to use than the "first generation" of navigation solutions like Navigator / NavigatorIOS / NavigationExperimental.
I also been testing navigator and also react navigation. Original navigator need more code compare to react navigation .. Now i'm unsure which one to moved on while few weeks ago people arguing react navigation is better.. I also have seen the wix version but i haven't done some testing how it work.
Everything in React Native is "native" views. The issue is that the RN community seems to be pretty heavily divided with respect to exactly where the API boundary should be.
AirBnB's native-navigation library literally has native iOS and Android code to create views, transitions etc.
react-navigation on the other hand is mostly JS driven, instead using the core functionality of React Native, which does generate native views.
The problem with react-navigation (and many libraries using a similar approach) is that you don't get a true native feel once you start interacting with the UI. This is because the JS -> native bridge is async, meaning you literally can't handle events as quickly as they're dispatched in native code - particularly if the events are synchronous.
I'm a huge fan of AirBnb's approach. Doing things in JS just because you "can" is inherently broken (as described above). Checkout the following Github issue for a demonstration of the issue: https://github.com/react-community/react-navigation/issues/1...
I was also confused regarding this. But a good indicator is always if you need to add native components when installing the library, or if it's just a simple npm install
This looks great. I wonder when a dominant library will emerge for navigation.
Also, I am a little bit confused, because react-navigation makes it sound like there are going to be merged into core once stable:
Once stable, NavigationExperimental will be deprecated in favor of React Navigation. React Navigation is a collaboration between people from Facebook, Exponent and the React community at large. [1]
Another thing to consider about Airbnbs nav stack is that it's written in swift.
This is important because Apple can still make changes to Swift which can break language backward compatibility.
This happened last wwdc. So if you use any third party libraries that are written in swift they won't work till the authors or you update them to the new language conventions.
The wix native library which they reference is written in objective c so this won't have that problem.
Maybe a little tangential- but with all the talk about Progressive Web Apps, what should we expect to happen with web/native hybrids like React Native? Mobile computing power is at the point where there shouldn't be much problem using simple Javascript and (gasp) jQuery to build an app, then wrapping it with PWA functionality.
Am I the only one wondering what the heck this actually is? The page this linked to just goes right into a guide on how to use it but doesn't explain what it is. The github page has a nifty looking guy on it, but once again it's just a jumble of buzzwords I do not understand at all. Why does the Javascript community make me feel stupid?
App-wide support for 100% native navigation with an easy cross-platform interface. For iOS, this package is a wrapper around react-native-controllers, but provides a simplified more abstract API over it. This abstract API will be unified with the Android solution which is currently work in progress. It also fully supports redux if you use it.
Kind of seems like you're trolling here but in case you're serious - it's odd to quote the middle of the docs and then complain that knowing nothing about the space you don't understand a given line.
Did you try the first sentence?
> Native Navigation is a navigation library for the React Native platform.
There you go, that's what it is.
If you don't have this problem and/or don't work on React Native apps, move on. If you're trying to learn and don't know what problems a navigation library solves, or don't know what view controllers in iOS development are, or don't know what redux is, or something else in the line you posted, try googling it and then looking at the examples in the library.
App-wide support for 100% native navigation with an easy cross-platform interface. For iOS, this package is a wrapper around react-native-controllers, but provides a simplified more abstract API over it. This abstract API will be unified with the Android solution which is currently work in progress. It also fully supports redux if you use it.
It sounds to me, after reading the above and googling "React Native" for <10 minutes, that this library handles the UI navigation for mobile phone apps written in React Native, and it does so in a way that allows your code to work across multiple operating systems (presumably iOS and Android). This library is also compatible with redux, a very popular state manager.
React Native is a popular method for creating semi-native, JavaScript-based iOS and Android apps, based on the very popular React library.
There's no one standard routing/navigation library in the community. As that's quite an important part of almost every app, a new high quality solution is something that any React Native dev would be interested in.
I'm sure you know who AirBnB are. They've spent the last year (?) building part of their mobile apps with React Native, and this is their home-grown navigation library.
Now, most React Native components (including navigation libraries) are built almost entirely in JavaScript, but this one is one of a few which "bridge" the native iOS and Android APIs, potentially resulting in a more natural and familiar feel.
There's one other semi-native nav option out there, Wix's React Native Navigation[1]. I've not personally tried either of them, but it's nice to have choices.
There are lots of JavaScript-based routing systems out there. React Navigation[2] is the closest we've got to an officially sanctioned package in a while, being the successor to two very popular libraries (Facebook's own NavigationExperimental[3] and Exponents Ex-Navigation[4]).
There's also React Native Router Flux[5], which is quite popular, and the very popular React Router[6] has support for React Native in their recently released v4.
As you can see, there are quite a few options available, and there are even more if you want to delve deeper[7]
It's just a navigation library, it (on a basic level) lets you change pages when making an App with React Native. What's nice is that this works for both iOS and Andriod as the standard built in one has issues (from my experience) with Android. Also, I agree that sentence is terribly written.
Which part do you not understand? It sounds like this will work on more than one platform, it acts as a simple interface for some other tool. Also, they are working on this for Android.
...would appreciate an explanation here.
[0]: https://github.com/airbnb/native-navigation/blob/91ae656192d...