Summary:
public
https://github.com/facebook/react-native/pull/4935 changed the window dimensions for android by replacing them with the actual screen dimensions. This changes the window dimensions back to their original values and adds `Dimensions.get('screen')` for the actual screen dimensions of the device.
Reviewed By: astreet
Differential Revision: D2921584
fb-gh-sync-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
shipit-source-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: javache
fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on https://github.com/facebook/fbjs/pull/95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.
This PR does several things:
1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2803288
Pulled By: davidaurelio
fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary:
In the native code, you must use RCTLinkingManager instead of LinkingManager and you have to import it as well.
Closes https://github.com/facebook/react-native/pull/5830
Reviewed By: svcscm
Differential Revision: D2921718
Pulled By: androidtrunkagent
fb-gh-sync-id: a95ec358c69e8830b7f0fb2ec60baefc06139758
shipit-source-id: a95ec358c69e8830b7f0fb2ec60baefc06139758
Summary:
public
I was looking into the missing panels at the bottom of the <ListView> - Grid Layout example, and found that it was caused by several problems, some in the example and some in ListView itself.
The first problem seemed to be a bug in the `_getDistanceFromEnd()` method, which calculates whether the ListView needs to load more content based on the distance of the visible content from the bottom of the scrollview. This was previously using the function
Math.max(scrollProperties.contentLength, scrollProperties.visibleLength) - scrollProperties.visibleLength - scrollProperties.offset
to calculate the amount the user could scroll before they run out of content. This sort-of works in most cases because `scrollProperties.contentLength` is usually longer than `scrollProperties.visibleLength`, so this would generally evaluate to
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
which meant that it would be positive as long as there was content still to be displayed offscreen, and negative when you reached the end of the content. This logic breaks down if `contentLength` is less than `visibleLength`, however. For example, if you have 300pts of content loaded, and your scrollView is 500pts tall, and your scroll position is zero, this evaluates to
Math.max(300, 500) - 500 - 0 = 0
In other words, the algorithm is saying that you have zero pts of scroll content remaining before you need to reload. But actually, the bottom 200pts of the screen are empty, so you're really 200pts in debt, and need to load extra rows to fill that space. The correct algorithm is simply to get rid of the `Math.max` and just use
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
I originally thought that this was the cause of the gap, but it isn't, because ListView has `DEFAULT_SCROLL_RENDER_AHEAD = 1000`, which means that it tries to load at least 1000pts more content than is currently visible, to avoid gaps. This masked the bug, so in practice it wasn't causing an issue.
The next problem I found was that there is an implict assumption in ListView that the first page of content you load is sufficient to cover the screen, or rather, that the first _ second page is sufficient. The constants `DEFAULT_INITIAL_ROWS = 10` and `DEFAULT_PAGE_SIZE = 1`, mean that when the ListView first loads, the following happens:
1. It loads 10 rows of content.
2. It checks if `_getDistanceFromEnd() < DEFAULT_SCROLL_RENDER_AHEAD` (1000).
3. If it is, it loads another `DEFAULT_PAGE_SIZE` rows of content, then stops.
In the case of the ListView Grid Layout example, this meant that it first loaded 10 cells, then loaded another 1, for a total of 11. The problem was that going from 10 to 11 cells isn't sufficient to fill the visible scroll area, and it doesn't change the `contentSize` (since the cells wrap onto the same line), and since ListView doesn't try to load any more until the `contentSize` or `scrollOffset ` changes, it stops loading new rows at that point.
I tried fixing this by calling `_renderMoreRowsIfNeeded()` after `_pageInNewRows()` so that it will continue to fetch new rows until the `_getDistanceFromEnd()` is less than the threshold, rather than stopping after the first page and waiting until the `contentSize` or `scrollOffset` change, but although this solves the problem for the Grid Layout example, it leads to over-fetching in the more common case of a standard row-based ListView.
In the end, I just increased the `pageSize` to 3 for the Grid Layout example, which makes more sense anyway since loading a page that is not a multiple of the number of cells per row confuses the `_renderMoreRowsIfNeeded` algorithm, and leads to gaps at the bottom of the view.
This solved the problem, however there was still a "pop-in" effect, where the additional rows were paged in after the ListView appeared. This was simply a misconfiguration in the example itself: The default of 10 rows was insufficient to fill the screen, so I changed the `initialListSize` prop to `20`.
Reviewed By: javache
Differential Revision: D2911690
fb-gh-sync-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
shipit-source-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
Summary:
Adds APIs to get all the enumerable property names of an object and to get an object as a map of property names to JSON values.
public
Reviewed By: lexs
Differential Revision: D2916238
fb-gh-sync-id: 0d9ee1eb4886d58fba8241537f6a0dad6024bd0e
shipit-source-id: 0d9ee1eb4886d58fba8241537f6a0dad6024bd0e
Summary:
public
In 9baff8f437 (diff-8d9841e5b53fd6c9cf3a7f431827e319R331), I incorrectly assumed that iOS was wrapping promises in an extra Array. What was really happening is that all the callers were doing this. I removed the wrapping in the callers and the special case handling MessageQueue.
Now one can pass whatever object one wants to resolve and it will show properly in the resolve call on the js side. This fixes issue https://github.com/facebook/react-native/issues/5851
Reviewed By: nicklockwood
Differential Revision: D2921565
fb-gh-sync-id: 9f81e2a87f6a48e9197413b843e452db345a7ff9
shipit-source-id: 9f81e2a87f6a48e9197413b843e452db345a7ff9
Summary:
[This commit](e730a9fdd0) (_Load assets from same folder as JSbundle (Android)_) causes React Native to look for assets inside the same folder the JSBundle was loaded from and generates asset URIs containing the absolute path to the asset (e.g. _/sdcard/bundle/drawable-xxhdpi/ic_back.png_).
While this is fine for a normal `ImageView`, `ToolbarAndroid`/`ReactToolbar` currently crashes if the icons are located on the file system. This happens because when setting an icon on `ReactToolbar`, Fresco is only used if the icon URI contains `http:// `or `https://`. For all other cases (like in this case where it starts with `file://`), the view tries to load the Drawable from the Android App Resources by it's name (which in this case is an absolute file-URI) and therefore causes it to crash (`getDrawableResourceByName` returns 0 if the Drawable was not found, then `getResources().getDrawable(DrawableRes int id)` throws an Exception if th
Closes https://github.com/facebook/react-native/pull/5753
Reviewed By: svcscm
Differential Revision: D2921418
Pulled By: foghina
fb-gh-sync-id: 7a3f81b530a8c1530e98e7b592ee7e44c8f19df1
shipit-source-id: 7a3f81b530a8c1530e98e7b592ee7e44c8f19df1
Summary:
public
Remove the unused feature for async dependencies / bundle layouts. We can bring it back later, if needed.
Reviewed By: cpojer
Differential Revision: D2916543
fb-gh-sync-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
shipit-source-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
Summary:
This PR moves `react` from dependencies to peerDependencies.
In general, this would have only been important for those people using packages that depend on `react` and were using npm@2...npm@3 would automatically de-dupe.
However, when #5812 gets merged, dependencies will be scoped to react-native (on both npm@2 & npm@3), thus breaking projects that are using a package like `react-redux` for example, which depends on `react`. There would be two copies of React installed, and due to the use of haste modules in `react`, this would break the packager and cause naming collisions.
This PR does three things -
1. Moves the dependency from dependencies to peerDependencies
2. Updates the local-cli to run `npm install react --save` when a new project is initialized.
3. Updates `react-native upgrade` to warn if `react` is not listed in the package.json's dependencies.
**Note: This will require a shrinkwrap update.**
Closes https://github.com/facebook/react-native/pull/5813
Reviewed By: svcscm
Differential Revision: D2918380
Pulled By: androidtrunkagent
fb-gh-sync-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
shipit-source-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
Reviewed By: mkonicek
Differential Revision:D2917191
Ninja: Only related to open source React Native, does not affect any fb apps
fb-gh-sync-id: c4fc80ebdd520942e75161a4a30ea4d18030bec4
shipit-source-id: c4fc80ebdd520942e75161a4a30ea4d18030bec4
Summary:
Output the Android artifacts in the new location so we can simply
do `./gradlew :ReactAndroid:installArchives` and `npm publish`.
**Test Plan**
Same as test plan of 702f999b05 without having to manually move the artifacts.
public
Reviewed By: bestander
Differential Revision: D2916664
fb-gh-sync-id: 27dcc711b3055a5a6c554ed1e69cf4a64add849c
shipit-source-id: 27dcc711b3055a5a6c554ed1e69cf4a64add849c
Summary:
As a part of this change I'm also renaming SimpleArray to JavaOnlyArray and SimpleMap to JavaOnlyMap. The main reason for the change is to support use-cases such as driving animations form the native code. In the case of native "animated" I'd like to be able to use the same interface as JS is using for updating the View properties. As view setters can take ReadableMap and ReadableArray as an argument in some cases it is necessary to create and pass those types to the setter. Using WritableNativeArray and WritableNativeMap for this purpose seems to me like a misuse and IMO will be less performant (vs java-only map/array) as those implementations of ReadableMap and ReadableArray proxies all their methods through JNI.
I'm also adding some additional class-level comments for the moved classes to avoid confusion and hopefuly prevent people from using those classess accidentally while writing native modules or methods that calls to JS.
Closes https://github.com/facebook/react-native/pull/5816
Reviewed By: svcscm
Differential Revision: D2911339
Pulled By: foghina
fb-gh-sync-id: 5b9a98d64f48d8bba34c15e3eecba2151da3577a
shipit-source-id: 5b9a98d64f48d8bba34c15e3eecba2151da3577a
Adam Miskiewicz
Satyajit Sahoo
David Aurelio
Thomas Parslow
Sreejumon
Pieter De Baets
Kevin Johnson
Olivier Notteghem
Hedger Wang
Felix Oghina
Martin Konicek
Konstantin Raev
Andrei Coman
Martin Konicek
Nick Lockwood
James Ide
Dave Miller
wusuopu
Michael Anderson
Andy Street
Andreas Stütz
Christopher Dro
Henry Kirkness
Sam
Chris Hopman
Corentin Smith
sunnylqm
Krzysztof Magiera