React Native: v0.6.0-rc Release

168 commits, 48 contributors.

We just shipped 0.6.0-rc and 0.5.0 proper to npm.

Last Friday, @brentvatne, @ide, @jsierles, @christopherdro, @dsibiski and @ccheever organized a big issue triage. They closed more than 200 issues, and properly tagged and found call to actions on the 200 remaining. In addition, they came up with a very useful document which lists the top 10 problems that are affecting the community. This is going to be very useful to prioritize our work.

Inspect Element

When you are working on a large codebase, one developer cannot fit all the code in his or her head. So, when you want to work on something, the first thing that you need to figure out is where is the code that rendered this piece of UI. @jaredly and @frantic made this super easy by implementing Inspect Element.

In order to use it, press Command+D > Inspect Element > Tap anywhere on the screen.

It is loaded with features such as showing you all the styles applied to the element, the dimensions/padding/margin and ability to go up the hierarchy. This has the potential of greatly increasing your productivity! Let us know if you have more ideas on how to make it even more useful.

Switch to Babel

Facebook has been one of the first big adopters of ES6 and we have several people participating in the TC39 committee that designs the spec. Since the JavaScript transform landscape was almost inexistent several years ago, we implemented and used our own transpiler called jstransform.

Unfortunately, jstransform has a big architectural issue: it takes an AST as an input and plain text as an output. The consequence is that you cannot compose transforms easily, which is very problematic when you want to try out new language features. We started working on a new version that solves this problem with a project called Recast, which is doing AST -> AST transforms.

Recast is the framework powering esnext and regenerator. While those projects were moving along, a new player entered called Babel (previously 6to5) and all the people working on esnext and regenerator joined forces with Babel.

At this point, Babel supports more features than jstransform, has a better architecture and a super active community. We already switched to Babel for React and we followed suite on React Native thanks to @amasad, @DmitrySoshnikov and @jaredly.

Another advantage is that we can now run the awesome ESLint on the raw source instead of the transformed source which is going to make it much more useful.

It shouldn't impact you right now as we did not enable any new transforms, but we're looking into letting you configure which transforms you want to use.

Background Color Propagation

In all the popular UI frameworks such as web, iOS, Android, the default background color for elements is transparent. This is usually what the developer expects but it makes it a hard problem for the compositing engine: every element that needs to be displayed on screen can potentially be blended with the elements that are underneath. This means that you have to do multiple passes and lose some of the parallelism of the GPU.

What we found is that the vast majority of the time, what the developer wants is not to have a transparent background color but to inherit the background color of its parent. When doing that, the job of the compositing engine is much simpler: since the background has a solid color, it will not need to compute what's underneath to get that pixel color.

There are some rare but legitimate use cases when this propagation is not correct, for example if you want to overlay transparent images on-top of each others. In this case, you can write `style={{backgroundColor: 'transparent'}} to lose this optimization and go back to the platform default.

In order to figure out how much blending is happening, you can turn on the setting in your simulator:

<img src="https://cloud.githubusercontent.com/assets/197597/7776416/ae97971c-006f-11e5-8a3b-f1afcf70ca32.png" width="200">

This background color propagation mechanism existed since we open sourced. However, there were many cases where it didn't remove blending as expected. For example, it turned out that giving a solid background color to images did not help the compositing engine the way it was implemented. @nicklockwood fixed this particular case (and many more) and you can see that images are now green :)

<img src="https://cloud.githubusercontent.com/assets/197597/8008930/1f78d9ec-0b5a-11e5-81a1-6b90b3be7769.png" width="200"> <img src="https://cloud.githubusercontent.com/assets/197597/8008935/247b717a-0b5a-11e5-8dd0-a9ce495ec562.png" width="200">                     Before                                             After

As you can see, there's still some red in React Native part and some red in default iOS components. There's still work to do to improve blending, but the new defaults are much better :)

Performance Tooling

The best way to improve performance is to be able to measure and visualize what is happening. This is something that is challenging with React Native since we have to profile two completely different stacks: obj-c and js. @tadeuzagallo figured out that he could add profiling markers in the code and export it in a format that's compatible with Chrome Trace Viewer to be able to visualize it.

Having this new tool, it helped us find out inefficiencies in the code. For example, on every JavaScript round-trip, we found out that we traversed the entire view hierarchy on the main thread! The reason for that particular case is that we have a method called reactBridgeDidFinishTransaction that was used to do some cleanup for 3 components: ScrollView, TabBarIOS and NavigatorIOS. It was implemented in a naive way where we would traverse all the views and for each one check if it implements that method and if yes, call it. It took 10ms on an iphone 6 to traverse a view hierarchy of 5k elements!

Once we discovered that, we changed it to register those components so that we only traverse a list of a few elements and we fixed this big inefficiency as you can see in the screenshot below:

The process to get this trace is currently very manual but I wanted to let you know that we're working on it and that it is likely going to help us diagnose more performance issues in the future!

Breaking Changes

• The enum values StatusBarIOS.Style.default and StatusBarIOS.Style.lightContent were removed in favor of the strings "default" and "light-content", respectively

Please let me (@vjeux) know if you run into any trouble upgrading.

New Features

• Implement merge functionality on AsyncStorage
• Add custom delay props to <Touchable*>
• <ListView> now supports a renderSeparator prop
• Support fetching videos from Camera Roll

Bug Fixes

• Use a faster implementation of crc32
• Warn when trying to require a native component that doesn't exist
• Fix XHR.status which is a number and not a string
• Use JSC C API for a 10-15% perf improvement in this particular bridge function
• Add better error messages when using react-native-cli incorrectly
• Geolocation now invalidates timer after success or error callback
• Upgrade Travis to the latest version of Xcode
• Remove useless setInterval on ListView
• Many Navigator small fixes
• Fix accessibility issue with ScrollView
• Fix itemList updates on PickerIOS
• Better resolution rules for node_modules in packager and support packages with . in the name