Summary:
Simply add an `onLayout` callback to a native view component, and the callback
will be invoked with the current layout information when the view is mounted and
whenever the layout changes.
The only limitation is that scroll position and other stuff the layout system
isn't aware of is not taken into account. This is because onLayout events
wouldn't be triggered for these changes and if they are desired they should be
tracked separately (e.g. with `onScroll`) and combined.
Also fixes some bugs with LayoutAnimation callbacks.
@public
Test Plan:
- Run new LayoutEventsExample in UIExplorer and see it work correctly.
- New integration test passes internally (IntegrationTest project seems busted).
- New jest test case passes.
{F22318433}
```
2015-05-06 15:45:05.848 [info][tid:com.facebook.React.JavaScript] "Running application "UIExplorerApp" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF"
2015-05-06 15:45:05.881 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":123,"x":12.5,"width":140.5,"height":18}}
2015-05-06 15:45:05.882 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":122,"width":50,"height":50}}
2015-05-06 15:45:05.883 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":70.5,"x":20,"width":294,"height":204}}
2015-05-06 15:45:05.897 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":206.5,"x":12.5,"width":140.5,"height":18}}
2015-05-06 15:45:05.897 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":70.5,"x":20,"width":294,"height":287.5}}
2015-05-06 15:45:09.847 [info][tid:com.facebook.React.JavaScript] "layout animation done."
2015-05-06 15:45:09.847 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":82,"width":50,"height":50}}
2015-05-06 15:45:09.848 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":110.5,"x":60,"width":214,"height":287.5}}
2015-05-06 15:45:09.862 [info][tid:com.facebook.React.JavaScript] "received text layout event
", {"target":27,"layout":{"y":206.5,"x":12.5,"width":120,"height":68}}
2015-05-06 15:45:09.863 [info][tid:com.facebook.React.JavaScript] "received image layout event
", {"target":23,"layout":{"y":12.5,"x":55,"width":50,"height":50}}
2015-05-06 15:45:09.863 [info][tid:com.facebook.React.JavaScript] "received view layout event
", {"target":22,"layout":{"y":128,"x":60,"width":160,"height":337.5}}
```
Summary:
NavigatorIOS supports four new properties:
- **rightButtonImageSource:** The source of an image to display in the top right. This must be a static image since UINavigationController only supports UIImages. Adding support for UIImageViews (or arbitrary views) is more complicated because custom views do not fade on touch and do not have hit slop the same way that UIImage buttons do. Usage: `rightButtonImageSource: ix('ImageName')`
- **backButtonImageSource:** Use a custom image for the back button. This does not replace the back caret (`<`) but instead replaces the text next to it.
- **leftButtonTitle**: Text for the left nav button, which supersedes the previous nav item's back button when specified. The main use case for this is your initial screen/UIVC which has nothing to go back to (since it is the first VC on the stack) but need to display a left button. This does hide the back button if there would have been one otherwise.
- **leftButtonImageSource:** Image source for the left button, super
Closes https://github.com/facebook/react-native/pull/263
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
This provides a way to get notified when a bridge fails to load JS, allowing apps to handle the error.
Closes https://github.com/facebook/react-native/pull/1085
Github Author: James Ide <ide@jameside.com>
Test Plan: run the UIExplorer app with the packager server not running, and verify that the notification is posted.
Summary:
Simple one character change - add a missing space
Closes https://github.com/facebook/react-native/pull/1112
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
As per #941 - fixes bug with `TouchabeOpacity` always reseting child opacity to `1.0` after press.
A note about the code: we could probably use a general `getNativeProp(propName, callback)` function rather than `getOpacity` but just used that as it was simpler for this specific PR, perhaps that refactor could be left to another - or maybe there is a way to do this already that I missed.
Before:
![bug](https://cloud.githubusercontent.com/assets/90494/7287207/52d6a686-e907-11e4-8e16-04b2ddd0582c.gif)
After:
![after](https://cloud.githubusercontent.com/assets/90494/7287689/5aca4776-e90c-11e4-8c40-aa6bd3e822d8.gif)
Example code:
```javascript
'use strict';
var React = require('react-native');
var {
AppRegistry,
StyleSheet,
Text,
View,
TouchableOpacity,
} = React;
var TestIt = React.createClass({
render() {
return (
<View style={styles.container}>
<TouchableOpacity activeOpacity={0.3}>
<View style={styles.searchButton}>
<Text>
Closes https://github.com/facebook/react-native/pull/977
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
The default initialRoute was the first route, but it makes more sense for the default initialRoute to be the last route in the initialRouteStack.
Updated the docs to reflect that.
@public
Test Plan: Updated call sites and checked that they work. Not many places use initialRouteStack yet.
Summary:
@public
Currently, every time we call into the packager we have to change the ulimit to make sure
we don't hit the EMFILE error (the packager uses as much concurrency as possible).
Using graceful-fs, the fs module -- with monkey patching -- becomes intelligent enough to recover
from EMFILE errors.
Test Plan:
* set `ulimit -n 256*
* start server
* request from your browser: http://localhost:8081/RKJSModules/MainBundle/CatalystBundle.includeRequire.bundle
* it works
Summary:
jumpN will call enableScene for the dest scene, which makes sure the scene can be made visible, but we need to avoid resetting the opacity for it when it is already the presented scene. There is already a check to make sure we don't reset opacity for the transitioningFrom scene.
@public
Test Plan: Fixes the issue on Android device when jumping to a scene that is already presented
Summary:
Hi!
I have the same problem as described here https://github.com/facebook/react-native/issues/297
It could occurs after restarting `packager.sh` or `debuger-ui` page.
I found simple solution that works for me, but I am not 100% sure it will works for any user with this problem.
How could this be tested automatically?
Closes https://github.com/facebook/react-native/pull/1101
Github Author: Evgen Filatov <evgen.filatov@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
`XMLHttpRequest.getResponseHeader` is case-insensitive, therefor the React-Native implementation needs to mimic this behavior as to not break libraries that are dependent on this.
There is a corresponding issue in `superagent` but this is the root cause (https://github.com/visionmedia/superagent/issues/636).
Closes https://github.com/facebook/react-native/pull/1138
Github Author: Ryan Pastorelle <rpastorelle@yahoo.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Should resolve#1081
cc @ericvicenti
Closes https://github.com/facebook/react-native/pull/1082
Github Author: jmstout <git@jmstout.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Revert Plan: This seems legit, but I'm not qualified to review.
Summary:
When touches end or cancel, update self.state in
RCTTouchHandler to let iOS know that we are in an ended/canceled state.
This way we won't eat other touches because it still thinks we're in a
began/changed state.
@public
Test Plan:
Scrolling in the back swipe area no longer busts gesture
recognition in Wilde.