Summary:
An earlier diff removed the "Sending Events to JavaScript" section of
the Native Modules (Android) docs.
Previous diff:
30bf039d90 (diff-bdf570846f463516068b23131b72eaaf)
Adding that section back in.
Confirm section renders correctly via markdown.
Closes https://github.com/facebook/react-native/pull/14143
Differential Revision: D5116899
Pulled By: hramos
fbshipit-source-id: c4a0f2a7fa8c5b1a0386c3a4e83d3ec2cd5c247e
Summary: in order to prepare open sourcing React Native Packager, we have to move scripts specific to React Native to a directory that will continue to exist.
Reviewed By: javache
Differential Revision: D5112193
fbshipit-source-id: eac77d0d981aecef7ee52365a6856340420a5638
Summary:
Working on refactoring error handling in `_loadAsDir` I figured out it was oftentimes problematic to pass on the candidates out of the functions as an array, as in practice there's always a single "candidates" object passed out. Also, using an array prevented nice Flow typing and forced additional invariants to be added. So I replaced that by a return value that explicitely can be either a module, or resolution candidates. That way the semantic is more clear: we don't get any candidates if we did resolve properly, and at the same time we enforce returning candidates if we could not resolve any module.
At first I wanted to just have type `{module: TModule} | {candidate: TCandidate}`, but Flow would hit edge cases, so instead I added a field `type` that make it explicit what is the result of the resolution, and allows Flow to refine the type fully after we test that field. This allows us to remove the extraneous invariants. Also, a nice thing is that at a few places, even if the type of the candididate is different, Flow allows us to return the "resolved" object just as it is, that prevents using more memory and causing more garbage collection than necessary.
Since we're creating more objects with that solution, this will be slightly less performant than returning `Module` objects directly, but I don't think it is worth micro optimizing this at that point. If really we see this to be causing trouble later, I'd try to find solutions such as reusing a pool of objects. Ex. we could pass the result `Resolution` object as argument instead of returning a fresh one, but that would make the code less legible, more complex.
Reviewed By: davidaurelio
Differential Revision: D5111501
fbshipit-source-id: f41cdab00640124081cfdf07668169bb2d5c00be
Summary: We can switch that case easily since it was already discarding the error if any would happen.
Reviewed By: davidaurelio
Differential Revision: D5103851
fbshipit-source-id: a0991f626e94a45efbf666561041af258fdbef0a
Summary:
Add the ability for UIManager to check if a node is an ancestor of anther one on Android like #7876 did on iOS
Closes https://github.com/facebook/react-native/pull/13129
Differential Revision: D4938319
Pulled By: hramos
fbshipit-source-id: abe20779be2142a1ea9ac46f52d8cd8609236419
Summary:
Restored the version lag caveat in the Getting Started, and updated the Upgrading guide to account for CRNA.
Additionally, updated the release versions page to account for the new release cycle (e.g. release candidates are encouraged).
Closes https://github.com/facebook/react-native/pull/14112
Differential Revision: D5112224
Pulled By: hramos
fbshipit-source-id: d544c5178484c27f1ed6dee3479bcd94e5e81982
Summary:
Make all properties of `ModuleTraansportLike` covariant to enforce read-only behavior at all sites using it.
The type only exists for compatibility reasons between old and new output functionality, and covariant properties give us stronger guarantees.
Reviewed By: jeanlauliac
Differential Revision: D5111667
fbshipit-source-id: 674658b07eb3a229cbc4344cb636e4a9ea4126d1
Summary:
Simplifies the `File` type by making `map` a non-optional, but nullable property.
Also adds helper functions for empty/virtual modules
Reviewed By: jeanlauliac
Differential Revision: D5111580
fbshipit-source-id: 9cab6634a9bdb0522dc36aec2abccaef9cf35339
Summary: Adds functionality to assemble an indexed source map to the new Buck integration. This implementation supports startup section optimisations. Hooking it up, and grouping optimisations will be in follow-ups.
Reviewed By: jeanlauliac
Differential Revision: D5106985
fbshipit-source-id: cc4c6ac8cfe4e718fc8bb2a8a93cb88914c92e0b
Summary: Because we don't want to test for `empty-module.ios.js`, etc. We know the module is supposed to be here. This simpler version makes it easier for me to switch the rest of the `loadAsFile` callsites to the "candidates" system to the "candidates" system.
Reviewed By: davidaurelio
Differential Revision: D5103816
fbshipit-source-id: 7e7d9be27573a1f33d562aeb850759e073fbc72f
Summary: For the Buck integration (work-in-progress), we want to add the ability to do some custom preprocessing similar to the packager server. The signature is different so I prefer to have a separate function for that. Also we don't need the transform options right now, I suggest we don't add them for now and add them later if necessary.
Reviewed By: davidaurelio
Differential Revision: D5094632
fbshipit-source-id: 1775ddef90b331deabc5be3e57a67436bce06c82
Summary:
Not sure if that is how it's supposed to read but tried to correct it
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/14085
Differential Revision: D5103609
Pulled By: javache
fbshipit-source-id: 483661b149761cf6d27fb43990272312d781cc6f
Summary:
Close#13500
I've been bothered by this issue for quite a long time, finally get some time to look into it.
I find the root cause is that after a prop of the native driven node is assigned with a plain value, if you set it to be a `Animated.Value` again , it will take no effect any more, so I just keep it be a `Animated.Value` all the time.
`value --> Animated.Value (✅) --> value (✅) --> Animated.Value (❌)`
ping janicduplessis
Closes https://github.com/facebook/react-native/pull/13885
Differential Revision: D5077094
Pulled By: javache
fbshipit-source-id: 3fb5d8196d94101200394b2bb2b95c776fb1d2f3
Summary:
1, Change bottom to be based� on height of parent.
2, Respect margin value when layout with right/bottom.
Closes https://github.com/facebook/yoga/pull/552
Differential Revision: D5102090
Pulled By: emilsjolander
fbshipit-source-id: dca291413ffc2027d7628f4c8b8eeeb0b4823bc2
Summary:
There are two ways to get started with React Native: using CRNA, or by building native code. The latter requires a set of dependencies that also need to be installed even by people who use CRNA if they have ejected.
There needs to be a clear demarcation between the two approaches as well as clear instructions as to which steps are of interest to CRNA using parties or people adding RN to an existing app.
Separating the two approaches entirely by using tabs can achieve this purpose.
Built and tested the website on Chrome on macOS. Have not yet tested other browsers or OS configurations.
This is a work in progress. Feedback is appreciated. I am not yet happy with the different sets of tabs/buttons, for example.
Closes https://github.com/facebook/react-native/pull/14005
Differential Revision: D5096426
Pulled By: hramos
fbshipit-source-id: cdbf19b148ec87f2f2dfdced345084d0bbff4c26
Summary:
'source' is not available in all shells on Linux (e.g. dash) and will silently fail launchPackager.command when called from runAndroid.js.
react-native run-android will thus silently fail to start the developement server ('JS server').
What existing problem does the pull request solve?
When running "react-native run-android" on the below reasonably vanilla Ubuntu system, the development server / packager script fails to start. It fails because sh defaults to dash (not bash) which doesn't know the command 'source'. dot (.) does the same as source, but works in all shells.
$ uname -a
Linux dallas 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ which sh
/bin/sh
$ readlink -f /bin/sh
/bin/dash
react-native-cli: 2.0.1
react-native: 0.44.0
$ ps aux | grep packager
(nothing)
ps aux | grep packager
sh /home/xxx/code/react-native/AwesomeProject/node_modules/react-native/packager/launchPackager.command
node /home/xxx/code/react-native/AwesomeProject/node_modules/react-native/packager/../local-cli/cli.js start
Closes https://github.com/facebook/react-native/pull/14040
Differential Revision: D5096298
Pulled By: hramos
fbshipit-source-id: 88466e802c9bc4358840391edb37e153f0a6b1f7
Summary: Changes the `sourceMappingURL` comment from multi line to single line.
Reviewed By: johnislarry
Differential Revision: D5094791
fbshipit-source-id: f8fa2efd7f173290cac985564c06b4a118a80aae
Summary: separates modules of the dependency graph from the generated require calls to kick of the app. This is required to make RAM bundle generation work properly'
Reviewed By: jeanlauliac
Differential Revision: D5094635
fbshipit-source-id: fca69a3e2d9b030cdc4d4405c2b5e795b0d55f87
Summary:
There was an issue that sometimes sticky headers would stop moving when re-rendering because we did not reattach events properly. This makes sure that we always detach and reatach on rerender in case the scroll view ref changes.
**Test plan**
Tested that this fixes issues with sticky headers we discovered when updating Expo to RN 0.44.
Closes https://github.com/facebook/react-native/pull/14012
Differential Revision: D5094418
Pulled By: javache
fbshipit-source-id: a56050ae786712e8a3de2a6e3b4e8749a2fde86e
James Pearce
Tim Yung
Ian Hill
Christoph Pojer
David Aurelio
Hector Ramos
Jean Lauliac
Georgiy Kassabli
Swordsman-Inaction
Matt Mahoney
G. Kay Lee
Adam Ernst
Reem Helou
Neo
Kevin Gozali
Brian Kabiro
Jean Regisser
Aaron Chiu
yihuang
Pieter De Baets
Sebastian Bargmann
Valentin Shergin
Emil Sjolander
Janic Duplessis
