Summary:
public
To make sourcemaps work on Hot Loading work, we'll need to be able to serve them for each module that is dynamically replaced. To do so we introduced a new parameter to the bundler, namely `entryModuleOnly` to decide whether or not to process the full dependency tree or just the module associated to the entry file. Also we need to add `//sourceMappingURL` to the HMR updates so that in case of an error the runtime retrieves the sourcemaps for the file on which an error occurred from the server.
Finally, we need to refactor a bit how we load the HMR updates into JSC. Unfortunately, if the code is eval'ed when an error is thrown, the line and column number are missing. This is a bug/missing feature in JSC. To walkaround the issue we need to eval the code on native. This adds a bit of complexity to HMR as for both platforms we'll have to have a thin module to inject code but I don't see any other alternative. when debugging this is not needed as Chrome supports sourceMappingURLs on eval'ed code
Reviewed By: javache
Differential Revision: D2841788
fb-gh-sync-id: ad9370d26894527a151cea722463e694c670227e
Summary:
After the release of 0.14, static images should be placed in the source code tree and then required as explained in the [Images guide] (https://facebook.github.io/react-native/docs/images.html). This pull request updates the image documentation and examples to the new asset system. UIExplorer tested on iOS and Android.
Closes https://github.com/facebook/react-native/pull/4987
Reviewed By: svcscm
Differential Revision: D2796276
Pulled By: bestander
fb-gh-sync-id: 732ffa2f136391bb8a3e40a54b5b1ff5022c97f2
Summary:
public
This diff improves the implementation of 3D touch by adding a `forceTouchAvailable` constant to View that can be used to check if the feature is supported.
I've also added an example of how you can use the `force` property of the touch event to measure touch pressure in React Native.
Reviewed By: vjeux
Differential Revision: D2864926
fb-gh-sync-id: 754c54989212ce4e4863716ceaba59673f0bb29d
Summary:
This adds the first of the three 3dTouch API types, that found on the touch event.
It adds the `force` prop to touch events when running on iOS 9 devices:
Closes https://github.com/facebook/react-native/pull/3055
Reviewed By: svcscm
Differential Revision: D2860540
Pulled By: nicklockwood
fb-gh-sync-id: 95a3eb433837c844f755b3ed4a3dfcb28452c284
Summary:
A promise based API for handling Link for Android and iOS. Refer #4971
The iOS part doesn't handle errors. Will need someone with iOS knowledge to do that.
cc skevy ide brentvatne mkonicek vjeux nicklockwood
Closes https://github.com/facebook/react-native/pull/5336
Reviewed By: svcscm
Differential Revision: D2866664
Pulled By: androidtrunkagent
fb-gh-sync-id: 67e68a827e6b85886bfa84e79b897f079e78b1b5
Summary:
I *think* this is causing a crash for me in a release build (curiously, not a debug build):
```
ReferenceError: Can't find variable: self
```
I saw this in 0.18.1, which I assume was renamed to v0.19.0-rc.
Closes https://github.com/facebook/react-native/pull/5562
Reviewed By: svcscm
Differential Revision: D2866491
Pulled By: androidtrunkagent
fb-gh-sync-id: 196f718bf807c5eef676f66f1e15d7bde9475d5b
Summary:
public
NSJSONSerialization throws an exception when it encounters bad JSON data, including NaN values, which may not be a programming error.
This diff adds code to catch those exceptions and convert to an error. Also, if no error handling is in place, RCTJSONStringify will now display a redbox, and attempt to recover by sanitizing the JSON data and retrying.
Reviewed By: javache
Differential Revision: D2854778
fb-gh-sync-id: 18e6990af0d91083496d6a0b75c31a94ed9454a5
Summary:
public
When using dev menu - elements inspector, a yellow box appears
with React warning regarding missing key prop in elements array.
This commit fixes this issue.
Reviewed By: martinbigio
Differential Revision: D2835332
fb-gh-sync-id: 3fcb37dfb6bdcff3788963b36416b7da190b9a84
Summary:
We no longer need to manually build JS bundle, everything should be integrated into Xcode.
Closes https://github.com/facebook/react-native/pull/5521
Reviewed By: svcscm
Differential Revision: D2860511
Pulled By: martinbigio
fb-gh-sync-id: fdde6b39aabccd5a39c140d431acbbbe5af71ec4
Summary:
Catalyst is the old project name. Rename a few files.
public
Reviewed By: bestander
Differential Revision: D2859553
fb-gh-sync-id: 65a87cc7bcc22f20326971becec02aa1c573e5b9
Summary:
public
This diff adds support for auto-resizing multiline text fields. This has been a long-requested feature, with several native solutions having been proposed (see https://github.com/facebook/react-native/pull/1229 and D2846915).
Rather than making this a feature of the native component, this diff simply exposes some extra information in the `onChange` event that makes it easy to implement this in pure JS code. I think this is preferable, since it's simpler, works cross-platform, and avoids any controversy about what the API should look like, or how the props should be named. It also makes it easier to implement custom min/max-height logic.
Reviewed By: sahrens
Differential Revision: D2849889
fb-gh-sync-id: d9ddf4ba4037d388dac0558aa467d958300aa691
Summary:
This reverts commit 888749220d.
The original commit didn't handle cases like .(ios|android|native).js, and vjeux is in favor of standardizing on .js instead of custom extensions like .jsx or .es6 everywhere.
> Unfortunately this pull request doesn't implement with .ios.jsx. But, when/if it does, it raises more questions like what happens if you have both ios.js and ios.jsx?
>
> Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. We now live in a world where we have many transforms for es6, flow, jsx... Why would we add .jsx but not .flow or .es6. Supporting more extensions is only going to fragment tools even more.
https://github.com/facebook/react-native/pull/5233#discussion_r49682279
Closes https://github.com/facebook/react-native/pull/5296
Reviewed By: svcscm
Differential Revision: D2830784
Pulled By: bestander
fb-gh-sync-id: 9a7a4745803acbcbc5dba176b971c629c904bacd
Summary:
maybe it is a bug when migrating from es5 to es6
Closes https://github.com/facebook/react-native/pull/5526
Reviewed By: svcscm
Differential Revision: D2860047
Pulled By: androidtrunkagent
fb-gh-sync-id: d8be261eea08ec659999fe8c714f33aca6fe3a60
Summary:
In Android, Fresco's default rounding corners support mode is BITMAP_ONLY which doesn't work in all cases (such as animated GIF's, some scale types, etc.).
Specifying the new "overlayColor" property on an Image will cause Fresco to switch to the other rounding corners mode, OVERLAY_COLOR, and will draw rounded corners by overlaying the solid color specified.
Fresco's behaviour is explained here: http://frescolib.org/docs/rounded-corners-and-circles.html
Closes https://github.com/facebook/react-native/pull/5366
Reviewed By: svcscm
Differential Revision: D2854696
Pulled By: mkonicek
fb-gh-sync-id: 251701ee8a64acbfc22694e9d4661c40eef75725
Summary:
I am using ReactNative in a hybrid App.
We have a setup like so:
Native Navigation Controller
Native Tab Controller
Native View Controller wrapping React
React Navigation Controller
React View Controller 1
React View Controller 2
Native View Controller 2.
When I pop Native View Controller 2 off the Navigation stack, I get a seg fault on this line:
NSUInteger indexOfFrom = [_currentViews indexOfObject:fromController.navItem];
I believe what's happening:
Your code is listening to Nav Controller transitions, assuming that they are all from React Native Nav Controllers.
You are catching this one instead, which is actually a Native Nav Controller transition.
You start trying to access the pushed/popped view controllers as if they were react native view controllers.
In this case, the view controllers are not react native -> no navItem field -> seg fault.
Solution: if we are catching this transition but it isn't from our react native nav controller, just
Closes https://github.com/facebook/react-native/pull/5495
Reviewed By: svcscm
Differential Revision: D2857473
Pulled By: nicklockwood
fb-gh-sync-id: cc7f0a16e2e0cea56ca9e49bcb87db4ebd3a0905
Summary:
public
This is needed to bring numerical module IDs back.
The numerical ID of the main module will always be `0` and is therefore of no use when used as conditional. We have to pass on the name, which will be preserved, when requesting transform options.
Reviewed By: martinbigio
Differential Revision: D2855106
fb-gh-sync-id: f9bc40e753b1b283ce0b00068e3c9964a541ad9b
Summary:
public
The reverted change doesn’t play nice with inline requires, let’s revert it for now.
I will bring it back after fixing it or adapting inline requires
Reviewed By: martinbigio
Differential Revision: D2854771
fb-gh-sync-id: 32fdbf8ad51240a9075b26502decb6328eed4b29
Summary:
I talked about this a bunch before. node-haste2 will resolve this issue. Right now node-haste1 looks into eevery single node_module recursively even though we only need to look into a finite-set of them. Some node_modules are huge so it takes a long time. haste2 doesn't eagerly look into node_modules so it doesn't have this issue. This diff blacklists the modules from node-haste but since we use the `resolve` npm module as a fallback we'll still be able to require them.
public
Reviewed By: kassens
Differential Revision: D2852384
fb-gh-sync-id: 113f1bd9c66fcd712c2549a7110a3e752b0e4a69
Martín Bigio
Andreas Drivenes
Pieter De Baets
Konstantin Raev
Jean Regisser
Nick Lockwood
Matt Apperson
Chirag
tuyou
SangYeob Bono Yu
Satyajit Sahoo
Jed Lau
Christoph Pojer
Martin Konicek
Alex Kotliarskyi
Hedger Wang
Alex Kotliarskyi
Andy Street
Yamill Vallecillo
Yamill Vallecillo
Dan Caspi
Mark Vayngrib
Christopher Chedeau
asmockler
James Ide
张亦驰
Noam Bartov
Arjun Komath
Christopher Dro
DougBanksPersonal
sunnylqm
Elliot Hesp
Dale Jefferson
David Aurelio
