Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
Summary:
The `ScrollView` sends important `updatedChildFrames` data to the `ListView` to be able to implement `onChangeVisibleRows` method. Coalescing operates very strongly on older devices like the iPhone 4s where this data is then lost.
Fixes#1782.
`ListView` has a method called `onChangeVisibleRows` that is called whenever the rows visible on screen change. This method is critical to be able to implement deletion/creation of views and hence be conservative in memory usage. I have an infinite scrolling view which uses this method to only render the full rows for what is visible on screen and put placeholders for everything else.
In the `RCTEventDispatcher`, we [coalesce events](522fd33d6f/React/Base/RCTEventDispatcher.m (L135-L152)) that are meant to be sent across the bridge. They are [dequeued](522fd33d6f/React/Base/RCTEventDispatcher.m (L180-L188)) on each
Closes https://github.com/facebook/react-native/pull/1783
Github Author: Param Aggarwal <paramaggarwal@gmail.com>
Summary:
@public
The API and implementation of `shouldInjectAJAXHandler` is very opinionated, and it does not solve many of the use cases that we'd like to address.
Since `shouldInjectAJAXHandler` is basically juts injecting JS to the web page, we should let developer inject whatever JS that address different issues that they want to fix.
Test Plan:
Test this snippet at <Playground />
```
<WebView
url="http://www.facebook.com"
injectedJavascriptIOS="document.body.style.border='solid 10px red'"
/>
```
Summary:
Hi,
I've updated the NavigatorIOS component to allow setting the translucent property.
usage is:
```
<NavigatorIOS
translucent={false}
/>
```
This is my first contrib to react-native, so apologies if I've missed something.
Cheers,
Owen
Closes https://github.com/facebook/react-native/pull/1273
Github Author: Owen Kelly <owen@novede.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
This adds the Keyboard animation type for when you want to animate UI based on the keyboard appearing/disappearing.
Closes https://github.com/facebook/react-native/pull/1366
Github Author: Stanislav Vishnevskiy <vishnevskiy@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Started from here - https://github.com/facebook/react-native/issues/1120. Most functionality for annotations were missing so I started implementing and somehow got caught up until the entire thing was done.
2 new events:
- callout presses (left / right)
- annotation presses
6 new properties for annotations:
- hasLeftCallout
- hasRightCallout
- onLeftCalloutPress
- onRightCalloutPress
- animateDrop
- id
1 new property for MapView
- onAnnotationPress
---
Now the important thing is, that I implemented all of this the way "I would do it". I am not sure this is the 'reacty' way so please let me know my mistakes 😄
The problem is that there is no real way to identify annotations which makes it difficult to distinguish which one got clicked. The idea is to pass a `id` and whether it has callouts the entire way with the annotation. I had to
Closes https://github.com/facebook/react-native/pull/1247
Github Author: David Mohl <me@dave.cx>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
@public
Test Plan: There are tests in `RCTUIManagerTests.m` that test the tag- and index-manipulation logic works. There are various scenarios including add-only, remove-only, and move. In addition, two scenario tests verify that the optimization works by checking the number of views and shadow views after various situations happen.
Summary:
Fix issue #1136
Closes https://github.com/facebook/react-native/pull/1721
Github Author: =?UTF-8?q?=E9=9A=90=E9=A3=8E?= <yinfeng.fcx@alibaba-inc.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Added remapping of style textAlign property to textAlignment (which is the name of the same property on text input components)
Closes https://github.com/facebook/react-native/pull/772
Github Author: Daryl Rowland <daryl@cloudyclear.com>
Test Plan: Not sure. I tried cleaned and rebuilt and my TextInput works, though! Do we need to set up any unit tests or examples for this?
Summary:
Added the ``scalesPageToFit`` prop to ``WebView``. This allows ``UIWebView`` to handle user zoom and scale.
Closes https://github.com/facebook/react-native/pull/1631
Github Author: alvaromb <amedina@apsl.net>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
In some case, it is very useful to have `velocity` and `targetContentOffset` parameters for `ScrollEndDrag` event. I just added them.
Closes https://github.com/facebook/react-native/pull/1500
Github Author: =?UTF-8?q?=E6=AD=A3=E9=9C=96?= <zhenglin.lzl@alibaba-inc.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
This fixes an issue with the containerBackgroundColor property of `<Text>` nodes, where containerBackgroundColor was being overridden by the backgroundColor. I also fixed up the example so that it demonstrates the feature more clearly.
Test Plan:
* Check UIExplorer text example
* Run Catalyst snapshot tests and check MAdMan, Groups
Summary:
As per discussion with @nicklockwood in #875, make `RCTScrollView` check its sticky headers for hitTests first.
Closes https://github.com/facebook/react-native/pull/1415
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan:
Have a sticky header in a ScrollView with a Touchable onPress action, scroll a bit after it docks and try tapping, should respond to tap.
Summary:
We need to unset `clipsToBounds` on both the wrapper and the inner custom
scroll view
@public
Test Plan:
`overflow: 'visible'` actually shows content outside the `ScrollView`
(e.g. for full-bleed horizontal scrollers/carousels). It doesn't pick up
touches though, which is a wider issue.
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:
Fixes#534:
```jsx
<SegmentedControlIOS
tintColor="#ff0000"
values={['One', 'Two', 'Three', 'Four']}
selectedtIndex={0}
momentary={false}
enabled={true}
onValueChange={ (value) => console.log(value) } />
```
This only supports string-based segments, not images. Also doesn't support full customization (no separator images etc); I figure this is a good MVP to lock-down a basic API
I also included a snapshot test case, but the images keep coming out funky. When I look at the sim, I see that the text labels show up for the selected segment, but the snapshot keeps coming out with no text on those segments. I tried forcing a delay, but same result. Is that explainable?
Obviously happy to change anything about the API, code-style nitpicks, etc
Closes https://github.com/facebook/react-native/pull/564
Github Author: Clay Allsopp <clay.allsopp@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@nicklockwood - Could I get a review of this?
Just took `RCTTextField` and ported it from `UITextField` to `UITextView` as you mentioned in another discussion, and removed any `UITextField` specific attributes.
- How do you think this should behave when there are subviews?
- Do you know how we can respond to the `UIControlEventEditingDidEndOnExit` event to respond to submit? Because `UITextView` isn't a `UIControl` we can't just use `addTarget` with `UIControlEventEditingDidEndOnExit`.
- Any other feedback?
Still going to look over the `UITextView` docs in more detail and make sure we expose all important options, and add it to the UIExplorer example, just putting this out here for feedback.
Closes https://github.com/facebook/react-native/pull/991
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
NavigatorIOS with custom nav bar custom colors, working example included in
UIExplorer.
Based on pull request #318 to complete pending work based on comments.
Closes https://github.com/facebook/react-native/pull/695
Github Author: Eduardo <edo.lomeli@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
There are still many other props that can be added to further customize the SliderIOS component, but I had a specific need for these two so I just went ahead and added them.
Closes https://github.com/facebook/react-native/pull/799
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
`value` is clamped between min/max and so order of prop application matters - `value` always ended up being set first in my tests, and consequently a value outside of the default range 0-1 would not work. So this applies the value when the min/max are set.
[Gist of broken example](https://gist.github.com/brentvatne/fc637b3e21d012966f3a)
^ the second slider here should have it's cursor in the middle
/cc @tadeuzagallo
Closes https://github.com/facebook/react-native/pull/835
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Enables overwriting of underlying colors for WebViews. Especially useful if you want to give your WebView a transparent background.
Closes https://github.com/facebook/react-native/pull/767
Github Author: Lochlan Wansbrough <lochie@live.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
- Returns matching subview hitTest or super hitTest if no match found. Should fix#99 .
Closes https://github.com/facebook/react-native/pull/501
Github Author: Boopathi Rajaa <me@boopathi.in>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
WebView component's automaticallyAdjustContentInsets prop should be type BOOL. Fixes#251.
Closes https://github.com/facebook/react-native/pull/314
Github Author: Jordanna Kwok <jordannakwok@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Allows setting of HTML directly on webview to support #506. This is a starting point, and feedback/improvement is requested.
1. if `startInLoadingState` is true, the HTML content will never show since the load event never fires
2. Neither html nor url are set as required props any more
Closes https://github.com/facebook/react-native/pull/542
Github Author: Colin Ramsay <colinramsay@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
This diff completes adding support for the following UITextField properties:
- returnKeyType: what the return key on the keyboard says
- enablesReturnKeyAutomatically: the return key is disabled iff there is no text entered. This too could be implemented in React but it feels better in UIKit right now because it is handled synchronously.
- secureTextEntry: obscure passwords
- keyboardType: added all the keyboard types, they are useful in different scenarios
There were varying degrees of support for these properties so it looks like this diff continues some unfinished work. I also updated the keyboardType enum to use native constants instead of strings like the other properties here.
Added examples to the UIExplorer.
Closes https://github.com/facebook/react-native/pull/265
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Alexsander Akers
Param Aggarwal
Hedger Wang
Owen Kelly
chaceliang
Stanislav Vishnevskiy
David Mohl
=?UTF-8?q?=E9=9A=90=E9=A3=8E?=
Daryl Rowland
Pieter De Baets
Nick Lockwood
alvaromb
=?UTF-8?q?=E6=AD=A3=E9=9C=96?=
Adam Krell
John Harper
Tadeu Zagallo
Brent Vatne
Stan Chollet
Georgiy Kassabli
Dave Sibiski
Spencer Ahrens
Jiajie Zhu
James Ide
Iragne
Clay Allsopp
Ben Alpert
Maksim Bunkow
Jakub Zika
Eduardo
Lochlan Wansbrough
Marek Cirkos
guru inamdar
Kureev Alexey
Ben Hiller
Christopher Chedeau
Boopathi Rajaa
Kevin Gozali
Jordanna Kwok
Colin Ramsay
