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}
Summary:
- make overlay transparent to avoid obscuring the app
- show style in the inspector pane
- show margin+padding values, also width/height and abs position
@public
Test Plan:
Open the inspector somewhere, start selecting things. You should see correct
padding, margin, and dimentions values; in addition to all style properties
enumerated.
Summary:
This shows margin and padding visually when inspecting an element.
@public
Test Plan:
Go to the "UIExplorer", to the <View> page. Open the inspector, and start
selecting things. Padding and margin should be indicated. (Padding in dark
blue and margin in orange).
Summary:
Previously, if you were already inspecting an element, touching again would
select a completely different element because the touch position was
calculated relative to the current overlay.
This fixes it.
@public
Test Plan:
Open the inspector, click around, verify that every click selects the thing
you clicked on.
Summary:
This adds new development feature to React Native that provides information
about selected element (see the demo in Test Plan).
This is how it works:
App's root component is rendered to a container that also has a hidden layer called
`<InspectorOverlay/>`. When activated, it shows full screen view and captures all
touches. On every touch we ask UIManager to find a view for given {x,y} coordinates.
Then, we use React's internals to find corresponding React component. `setRootInstance`
is used to remember the top level component to start search from, lmk if you have a
better idea how to do this. Given a component, we can climb up its owners tree
to provice more context on how/where the component is used.
In future we could use the `hierarchy` array to inspect and print their props/state.
Known bugs and limitations:
* InspectorOverlay sometimes receives touches with incorrect coordinates (wtf)
* Not integrated with React Chrome Devtools (maybe in followup diffs)
* Doesn't work with popovers (maybe put the element inspector into an `<Overlay/>`?)
@public
Test Plan:
https://www.facebook.com/pxlcld/mn5k
Works nicely with scrollviews
Summary:
Closes https://github.com/facebook/react-native/pull/1260
Github Author: Luke <kejinlu@gmail.com>
Test Plan: Created `class Foo extends React.Component` and made sure error messages were good.
Summary:
`mountSafeCallback` simply wraps a callback in an `isMounted()` check to prevent crashes when old callbacks are called on unmounted components.
@public
Test Plan:
Added logging and made sure callbacks were getting called through
`mountSafeCallback` and that things worked (e.g. photo viewer rotation etc).
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:
Requiring ExceptionsManager in renderApplication (added in D2023119) led to a transitive require of ExecutionEnvironment, which has to run after InitializeJavaScriptAppEngine.
InitializeJavaScriptAppEngine is the right place for this sort of logic because we control the order that things are loaded, so move the console.error hook initialization there.
@public
Test Plan: Loaded shell app in simulator with Chrome debugging with no errors.
Martin Kralik
Nick Lockwood
Gabe Levi
Tim Yung
David Aurelio
Krzysztof Magiera
Tadeu Zagallo
Pawel Sienkowski
Bill Glover
Kyle Corbitt
Sebastian Markbage
Felix Oghina
Alexsander Akers
Martin Konicek
Eric Vicenti
Spencer Ahrens
Jared Forsyth
Christopher Chedeau
Pieter De Baets
Philipp von Weitershausen
Alex Kotliarskyi
Luke
Ben Alpert