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.
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.
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.
Readit News
...would appreciate an explanation here.
[0]: https://github.com/airbnb/native-navigation/blob/91ae656192d...
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.
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).
Deleted Comment
https://github.com/wix/react-native-navigation
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:
https://react-native.canny.io/feature-requests/p/navigator-b...
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)
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.
[1] https://github.com/facebook/react-native/wiki/Roadmap
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.
Wow, you guys have a tight curve you're staying ahead of :-)
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.
In case you're implying this was a "beat them to market" situation, it wasn't. Both navigation projects have been on React Native's public roadmap for several months: https://github.com/facebook/react-native/wiki/Roadmap/_compa...
Improved navigation has been one of the RN community's highest-voted feature requests: https://react-native.canny.io/feature-requests/p/better-navi...
http://airbnb.io/native-navigation/docs/guides/basic-usage.m...