Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary: When embedding in a hybrid app, we sometimes present new modal views or windows that have a different frame from the original root view. This API allows us to get coordinates in the application's window frame, which should be valid in any fullscreen view.
Reviewed By: majak
Differential Revision: D2939827
fb-gh-sync-id: 06b93cc2cb3519a25819c6efa445c779314dd673
shipit-source-id: 06b93cc2cb3519a25819c6efa445c779314dd673
Summary:public
We now wrap the <RootComponent> in an <View> where we can control the accessibility at a high level. This was only used to turn it off for the faded out background view when we show a pop up.
We use setNativeProps instead of setState to avoid the render. We really just want to pass this value to the native Android View.
Reviewed By: davidaurelio
Differential Revision: D2928371
fb-gh-sync-id: 19c34471c33650acb526a2f5a02b6070e844e8d0
shipit-source-id: 19c34471c33650acb526a2f5a02b6070e844e8d0
Summary:
Original Android's refreshControl in ScrollView is tightly coupled with AndroidSwipeRefreshLayout. If someone use `ref=` for RefreshControl in ScrollView, it does nothing since RefreshControl in Android return null.
This change allows customized RefreshControl especially for `ref=` as well as making ScrollView's code clearer.
Closes https://github.com/facebook/react-native/pull/5623
Reviewed By: svcscm
Differential Revision: D2890072
Pulled By: nicklockwood
fb-gh-sync-id: a8fc7746bcc050a6e46fedf3583979f4cb9021b6
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
Summary:
A lot of people see this error and end up posting in our support group. The root cause is that their js and native versions are out of sync. Adding a helpful description here will unblock them on their own.
Closes https://github.com/facebook/react-native/pull/5605
Reviewed By: svcscm
Differential Revision: D2878376
Pulled By: martinbigio
fb-gh-sync-id: 10dedbdbb4bee3fce5119367223ebb42a3c1b6a4
Summary:
public
Map and Set are a standard JavaScript features, but are only supported in a subset of JSC versions that we target (e.g. iOS 7's JSC doesn't support Set).
The consequence of this is that failing to require('Set') before using it won't error during testing on a modern OS, but will fail on older OS versions. This diff makes the Map and Set polyfills available globally to all RN apps to avoid that problem.
Reviewed By: davidaurelio
Differential Revision: D2833997
fb-gh-sync-id: 713d8b69f6a1bce2472a1b2e6b84f69d75f30289
Summary:
When you did a typo in declaring a prop type (like using `boolean` insteal of `bool`) you'd got a bit misleading error message:
{F27113768}
The truth is that the prop type is defined, but not correctly. So I've changed the message in this case to be more accurate:
{F27113627}
public
Reviewed By: sahrens
Differential Revision: D2729340
fb-gh-sync-id: dd12c10a4f3a1c9825293f86481a082908127a76
Summary:
public
The +[RCTConvert UIImage:] function, while convenient, is inherently limited by being synchronous, which means that it cannot be used to load remote images, and may not be efficient for local images either. It's also unable to access the bridge, which means that it cannot take advantage of the modular image-loading pipeline.
This diff introduces a new RCTImageSource class which can be used to pass image source objects over the bridge and defer loading until later.
I've also added automatic application of the `resolveAssetSource()` function based on prop type, and fixed up the image logic in NavigatorIOS and TabBarIOS.
Reviewed By: javache
Differential Revision: D2631541
fb-gh-sync-id: 6604635e8bb5394425102487f1ee7cd729321877
Summary: public
RCTUIManager is a public module with several useful methods, however, unlike most such modules, it does not have a JS wrapper that would allow it to be required directly.
Besides making it more cumbersome to use, this also makes it impossible to modify the UIManager API, or smooth over differences between platforms in the JS layer without breaking all of the call sites.
This diff adds a simple JS wrapper file for the UIManager module to make it easier to work with.
Reviewed By: tadeuzagallo
Differential Revision: D2700348
fb-gh-sync-id: dd9030eface100b1baf756da11bae355dc0f266f
Summary: Adds a "Dismiss All" button to YellowBox for people who see litter on the ground and continue walking. (Just kidding).
public
Reviewed By: vjeux
Differential Revision: D2691764
fb-gh-sync-id: 9746b42bc1e5dc51f2320880f47f8cb17b952570
Summary: public
In a previous diff I've removed a need for using View attributes in requireNativeComponent. Thanks to that we can now use requireNativeComponent in View module. In a follow up diff I'll be getting rid of ReactNativeViewAttributes.
Reviewed By: sahrens
Differential Revision: D2676088
fb-gh-sync-id: d5d6e50f4629bd7982b90f3496e1fd22078e96a8
Summary: public
Make sure some modules that are only available in dev mode are only
included in dev bundles.
Depends on: D2663838
Reviewed By: davidaurelio
Differential Revision: D2663889
fb-gh-sync-id: 42be40b865ef305828b3519556125af090ec61f4
Summary: Partially fixes#3316 by addressing 16 linter warnings:
- Strings should be singlequote
- Missing semicolon
Travis build jobs 1.1 through 1.4 complete successfully. 1.5 fails through what appears to be an unrelated issue on master.
Closes https://github.com/facebook/react-native/pull/3332
Reviewed By: @svcscm
Differential Revision: D2531718
Pulled By: @javache
fb-gh-sync-id: ca22fbeac5fe3b4f725775a72f21b6dd7a75d94b
Summary: This is related to the discussion in #3155.
I've documented the methods in this mixin, and pointed to other appropriate documentation where necessary as well.
I didn't end up adding any examples. I wanted to add a `focus()`/`blur()` example to the UIExplorer app, but the app seems to be broken on master at the moment (`Requiring unknown module "event-target-shim"`) and I didn't bother trying to fix it. I think the last thing necessary for making the usage of these methods clear is an example of calling one or more of them on a `ref` or view captured in some other way. However, `setNativeProps` is well documented in the "Direct Manipulation" guide, which I link to from this page, so by extension it should be possible to figure out the functionality of the other methods.
cc @mkonicek @astreet
Closes https://github.com/facebook/react-native/pull/3238
Reviewed By: @svcscm
Differential Revision: D2517187
Pulled By: @mkonicek
fb-gh-sync-id: 4e68b2bc44ace83f06ae2e364ca0c23a7c461b20
Summary: These were accidentally supported because they were merged at a lower
level. That's an implementation detail. setNativeProps should still
normalize the API.
I fixed some callers.
Setting props the normal way used to ignore these. Unfortunately we can't
warn for those cases because lots of extra props are spread. (The classic
transferPropsTo issue.)
@public
Reviewed By: @vjeux
Differential Revision: D2514228
fb-gh-sync-id: 00ed6073827dc1924da20f3d80cbdf68d8a8a8fc
Summary: Decouple processStyle from the main reconciliation. It is now a process
extension to the style attribute `transform`. This effectively decouples a
large portion of special cases and helper dependencies from the reconciler.
The transform attribute becomes translated into the transformMatrix attribute on
the native side so this becomes a little weird in that I have to special case
it. I don't think it is worth while having a general solution for this so I
intend to rename the native attribute to `transform` and just have it accept the
resolved transform. Then I can remove the special cases.
The next step is generalizing the flattenStyle function and optimizing it.
@public
Reviewed By: @vjeux
Differential Revision: D2460465
fb-gh-sync-id: 243e7fd77d282b401bc2c028aec8d57f24522a8e
Summary: Move the ViewAttributes and StyleAttributes configuration into the
Components library since they're coupled and change with the
native component configuration.
This also decouples StyleAttributes from the reconciler by adding it
to the ReactViewAttributes.
To do that, I refactored the property diffing to allow for recursive
configurations. Now an attribute configuration can be a nested object,
a custom configuration (diff/process) or true.
The requireNativeComponent path incorrectly gets its attributes set up
on the root validAttributes instead of the nested style object.
So I also have to add the nested form. Effectively these currently allow
these attributes on props or nested.
@public
Reviewed By: @vjeux
Differential Revision: D2456842
fb-gh-sync-id: cd5405bd8316c2fcb016d06c61244ce7719c26c0
Summary: Concolidate the creation of the "update payload" into
ReactNativeAttributePayload which now has a create
and a diff version. The create version can be used by
both mountComponent and setNativeProps. This means that
diffRawProperties moves into ReactNativeAttributePayload.
Instead of storing previousFlattenedStyle as memoized
state in the component tree, I recalculate it every
time. This allows better use of the generational GC.
However, it is still probably a fairly expensive
technique so I will follow it up with a diff that
walks both nested array trees to do the diffing in a
follow up.
This is the first diff of several steps.
@public
Reviewed By: @vjeux
Differential Revision: D2440644
fb-gh-sync-id: 1d0da4f6e2bf716f33e119df947c044abb918471
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Summary:
Because we don't want to integrate Animated inside of the core of React, we can only pass Animated.Value to styles of <Animated.View>. TouchableOpacity unfortunately used cloneElement. This means that we should have asked every single call site to replace their children to Animated.View. This isn't great.
The other solution is to stop using cloneElement and instead wrap the children inside of an <Animated.View>. This has many advantages:
- We no longer use cloneElement so we're no longer messing up with elements that are not our own.
- Refs are now working correctly for children elements
- No longer need to enforce that there's only one child and that this child is a native element
The downside is that we're introducing a <View> into the hierarchy. Sadly with CSS there is no way to have a View that doesn't affect layout. What we need to do is to remove the inner <View> and transfer all the styles to the TouchableOpacity. It is annoying but fortunately a pretty mechanical process.
I think that having a wrapper is the best solution. I will investigate to see if we can make wrappers on TouchableHighliht and TouchableWithoutFeedback as well.
**Upgrade Path:**
If the child is a View, move the style of the View to TouchableOpacity and remove the View itself.
```
<TouchableOpacity onPress={...}>
<View style={...}>
...
</View>
</TouchableOpacity>
-->
<TouchableOpacity onPress={...} style={...}>
...
</TouchableOpacity>
```
If the child is an Image or Text, on all the examples at Facebook it worked without any change. But it is a great idea to double check them anyway.
Summary:
The `InspectorOverlay` component was getting unwieldy, so I broke it into three components:
- Inspector
- InspectorOverlay
- InspectorPanel
and added @flow types.
The inspector was also living under the `ReactIOS` directory, and I moved it
up into the `Libraries` directory, as the inspector will soon be usable [on
Android](https://phabricator.fb.com/D2138319).
All features of the inspector should remain functional, with the addition of
one feature:
- you can toggle "touch to inspect" by tapping the "Inspect" button at the
bottom of the inspection panel. When inspection is disabled, the panel remains, but you can interact with
the app normally without touches being intercepted
@public
Test Plan:
Open the inspector:
- touch to inspect things, verify that margin, padding, size and position are
reported correctly, and that the component hierarchy is navigable.
- tap the "Inspect" button, and verify that you can interact with the app
normally.
{F22548949}
[Video of toggling inspection](https://www.latest.facebook.com/pxlcld/mrs9)
Summary:
This allows you to select the displayed owner hierarchy, and see the styles,
props, and position.
@public
Test Plan:
Open the inspector, select something in the middle of the page. Click the
breadcrumb train in the inspector, and verify that:
- styles are reflected
- margin/padding/box is correct
- the highlight updates to show the selected item
See video as well.
[Video](https://www.latest.facebook.com/pxlcld/mqnl)
Screenshot
{F22518618}