v0.7.0-rc

255 commits, 57 contributors.

After a few days of unavoidable delays, 0.7.0-rc and 0.6.0 proper have been shipped to npm! 0.6.0 proper is up on Cocoapods as well, and the 0.7 stable release will be pushed to it next week.

I want to send out a big thanks to everyone who submitted issues and pull requests this time around! Your efforts are much appreciated.

Improved Profiler

We mentioned in the v0.6.0-rc release notes that @tadeuzagallo had been working on improving the performance tooling, and now with v0.7.0-rc it's available for you to use!

The profiler integrates with Chrome Trace Viewer to give you fine-grained insight into both the JavaScript and Objective-C stacks in one place. You can also visualize VSync/frame deadlines (iOS is VSynced at 60fps) and enable "Flow events", which draws arrows to indicate function calls flowing into one another.

Install Google Trace Viewer

You will need to have trace2html in your PATH in order to use the profiler.

brew update && brew install trace2html

Using the Profiler

Command+D > Start Profiler, perform whatever actions that you would like to profile in your app, then Command+D > Stop Profiler.

After a short delay the results will be opened up automatically in Chrome. Let's look at the results from the profile we recorded above.

Not very useful at this high level, but we can tell that there are a couple places where we clearly exceeded the frame deadline of 16.67ms (60fps). You probably noticed this in the gif above - clicking the button did not immediately change the background color. In this case, it was because I inserted for (var i = 0; i <= 100000000; i++) { i * i } into the onPress handler to slow it down; in practice, this could be due to an actual performance issue in your app.

Clicking on DispatchFrameUpdate reveals that it took over 500ms to calculate the frame - more than 30x what it should take. But the time spent on DispatchFrameUpdate itself (the "self time") is insignificant, so we dig deeper.

Everything looks good except for the function call at the very bottom - there we find that the code for responding to the touch event is responsible for egregiously missing the frame deadline. If we were to move the slow code down into the render function, we would see this instead:

We can also select "Highlight VSync" to see where VSync is occurring:

And if we select "Flow Events" we can see how functions flow into one another.

Note: the simulator is unreliable for this kind of profile because the timing is not the same as on the device; you might notice the VSync values on the UI thread and JS threads are completely different in simulator profiles.

Breaking Changes

• Removed contextual navigation from Navigator (4690983). If you use nested Navigator components, you must explicitly call navigation methods like push, pop, and replace on the parent Navigator instead of relying on the child to automatically delegate the call to its parent.
• XHR requests will throw an error if the response is anything other than text (see #1870)
• The packager follows Node's require resolution algorithm much more closely. When in doubt, specify the path to modules the same way you would with Node.
• The Facebook-proprietary @providesModule directive is now scoped to each npm package instead of your entire app. This means that if you were requiring modules from another package using its @providesModule name, this will no longer work. Instead, require the modules using the package's name like you would with Node.
• All require statements for React Native modules should go through the public interface:

// This may pull in an unexpected version of `RCTDeviceEventEmitter` and `NativeModules`
var RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
var RNKeyboardEventsManager = require('NativeModules').RNKeyboardEventsManager

becomes

// This will ensure that you require the correct modules, via the react-native package
var {
  DeviceEventEmitter,
  NativeModules: {
    RNKeyboardEventsManager,
  },
} = require('react-native');

Deprecations

• onWillFocus and onDidFocus have been deprecated in favor of adding event listeners to the navigator: this.props.navigator.addListener('willfocus', this._onWillFocus); and this.props.navigator.addListener('didfocus', this._onDidFocus);

New Features

• Add assetRoots and projectRoots flags to the bundle CLI command to conform with packager
• Add support for incremental updates to XMLHttpRequest (e00b9ac and UIExplorer for more details)
• Add map type property (standard, satellite, hybrid) to MapView
• Add getScrollResponder to ScrollView-based components, such as ListView, to allow for better composability
• File upload via XHR FormData
• Support textAlign: 'justify' on iOS
• Add support for JavaScript async functions to RCT_EXPORT_METHOD (90439ce - also see @ide's blog post)
• Documentation added for Animations, Direct Manipulation (setNativeProps), Navigator vs NavigatorIOS comparison, ActionSheetIOS, Accessibility and various other improvements.
• Add scale support for base-64 encoded images
• Automatically dismiss red box error screen on live reload for a better development experience
• Packager has a new module resolution algorithm that more closely matches Node's for node_modules
• Improved packager performance by lazily building the dependency graph asynchronously

Bug Fixes

• Allow external libraries to define React Native modules instead of previously requiring everything to be compiled together as one library (e9095b2)
• Text layout bug on screen rotation
• Update curRenderedRowsCount when data source changes - fixes need to sometimes force a re-render of ListView
• Fix AnimationExperimental for 32bit devices when fromValue is double
• Enable textAlign for TextInput

v0.6.0-rc

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:

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 :)

                    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

v0.5.0-rc

45 commits and 21 contributors.

New Features

FPS Monitor

One of the reason you may want to use React Native is because you can build applications that perform well with it. As React Native matures in term of features, we are starting to invest a lot more into performance. If you open the developer panel via Cmd+Ctrl+Z, you will see a new option called "Show FPS Monitor".

When activated, you will see two FPS counters, one for the UI thread and one for the JS thread. The best way to make an application fast is to fix the slow parts. This is where performance investigation tooling is required. This one lets you do a first triage between issues from the UI thread and the JS thread. This is the first of a series of performance tooling we're working on.

Please, do not ever profile on simulator as it doesn't reflect at all what on device performance is going to be. Also, make sure that you dev mode is turned off as it introduces non trivial overhead to provide great developer warnings.

Accessibility

Facebook is being used by 1.4 billion people around the world and we want every single one of them to have the best experience possible. Accessibility features are an important tool and one that has traditionally been very developer unfriendly.

Our goal with React Native is that if you write your app without thinking about accessibility: it will be 80% there. We want you to fall into the pit of success.

In order to make an app accessible via Voice Over, you need to identify all the interactive elements and mark them as accessible with a label. It turns out that if you follow React Native best practices, most of your interactive elements are going to be implemented via <TouchableHighlight>, <TouchableOpacity> or <TouchableWithoutFeedback>. We made sure to mark those as accessible. In order to compute the label, we traverse the hierarchy and concatenate all the text nodes. Most of the time it gives a good result. The place where it breaks down most often is when the button is an icon. In those cases, you need to specify the label yourself via the accessibilityLabel prop.

To check if your app is accessible, you can enable the Accessibility Inspector by doing: Hardware > Home > Settings > General > Accessibility > Accessibility Inspector. And go back to your app via Hardware > Home > Your app.

All the text outside of touchable elements is also marked as accessible by default as the user is likely going to want to know about it. Since React Native uses native components such as UIScrollView and UIButton, you also get their great accessibility features.

As you can imagine, those heuristics do not work all the time. You can polish the accessibility via the following props: accessible, accessibilityLabel, onAcccessibilityTap, onMagicTap, accessibilityTraits.

This is an area that's often overlooked and where we hope React Native can shine. If you are interested in helping out with this effort, please let us know.

Breaking Changes

• AdSupport is no longer linked by default. The mere existence of code that uses the advertising id in your app triggers an additional verification step during the App Store review process :( If you are using it, you'll need to manually link it to continue using it.

Bug Fixes

• Add RCTNativeAppEventEmitter as mentioned in the documentation
• Add a warning when trying to react-native init in an already initialized folder
• onLayout is now available on <ActivityIndicatorIOS> and <TextInput>
• Update Jest to 0.4.5
• Fix RCTBatchedBridge main thread invalidation
• Fix exception when creating a native component with no propTypes
• Fix edge cases in <Navigator>
• Red box if JSC throws a syntax error not previously caught by the packager

v0.4.4

Bug Fixes

• Unbreak Chrome debugger and Websocket

v0.4.3

91 commits, 23 contributors, 9 days

New Features

• Websocket polyfill
• AlertIOS.prompt()
• letterSpacing style property for <Text>
• borderTopLeftRadius, borderTopRightRadius... style property on <View>

Breaking Changes

• ref.getNativeHandle() and ref.getNodeHandle() no longer exist. The replacement is React.findNodeHandle(ref)
• If you were using the undocumented createReactIOSNativeComponentClass or ReactIOSViewAttributes to create iOS wrappers, now you should use requireNativeComponent

Updates

• Update flow to 0.11
• Update jest to 0.4.2

Bug Fixes

• Fix packager with folders that have space inside
• Fix thread safety for RCTImageLoader
• Properly support overflow: 'visible' on <ScrollView>
• measure callback can no longer be invoked if the component has unmounted
• No longer require ruby dependency
• UIExplorer icon shows up on the home screen
• Changing left icon now works on <NavigatorIOS>
• Fix edge cases in <Navigator>

v0.4.2

0.4.2

v0.4.1

0.4.1

v0.4.0

0.4.0

v0.3.11

0.3.11

v0.3.8

0.3.8