Summary:
NativeReadable{Map,Array} classes have convenient to{HashMap,ArrayList}
methods that make it easier to interoperate with existing Java code
from within a ReactNative application (e.g., Native Module) ...
Thanks for submitting a PR! Please read these instructions carefully:
- [x] 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.
NativeReadable{Map,Array} classes have convenient to{HashMap,ArrayList}
methods that make it easier to interoperate with existing Java code
from within a ReactNative application (e.g., Native Module)
These changes make these same methods available to any code using
the Readable{Map,Array} interfaces, instead of forcing consumers to
cast their generic instances into the NativeReadable* equivalents
Moving this methods up to the interfaces also makes it easier to
write unit tests for Native Modules - using the JavaOnly{Map,Array}
implementations of Readable{Map,Array} - while still relying on the
to{HashMap,ArrayList} methods
* Write a native module that receives a JSON object as `ReadableMap` and a JSON array `ReadableArray`.
* Print out the result of `toHashMap` and `toArrayList`.
* Make sure `NativeReadable{Map,Array}` works:
* Call the native module's method from JavaScript, passing an `Object` and an `Array`.
* Compare the printed values with the passed content.
* Make sure `JavaOnly{Map,Array}` works:
* Call the native module's method from the Java code and pass a `JavaOnlyMap` and a `JavaOnlyArray`.
* Compare the printed values with the passed content.
**Please advise if there is an automated test suite where I could add a case for this.**
Closes https://github.com/facebook/react-native/pull/14072
Differential Revision: D5123120
Pulled By: javache
fbshipit-source-id: 343f4396b99e03ecaf47993db6955d7932152f77
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
XCode [Thread Sanitizer](https://clang.llvm.org/docs/ThreadSanitizer.html) find race condition while read/write `_instance` variable in RCTModuleData class. A bridge can check `hasInstance` method while instance writes.
All tests passed on my device.
These changes remove data race, you can turn it in scheme configuration 
Closes https://github.com/facebook/react-native/pull/13757
Differential Revision: D4994041
Pulled By: javache
fbshipit-source-id: 631cd59bbcbde193937d8baf8358ff6868717a2e
Summary:
The lack of very clear docs on supported image formats is causing unnecessary issues (#13806).
This should mitigate and keep the issue list cleaner.
Its only a documentation change. No code changes made.
Closes https://github.com/facebook/react-native/pull/13807
Differential Revision: D5023002
Pulled By: javache
fbshipit-source-id: b1e3562ae7649cf71833b300e125966d6e832a69
Summary:
* Internally, we already set up babel before calling into metro-bundler.
* Externally, I moved the setup calls to outside the packager/ folder.
If somebody has a custom integration with RN, they would need to setup babel themselves up until we make the open source split. By the time this is released in open source, an npm version of metro-bundler will be available for use.
Next step: also do this for the worker and remove setupBabel from the metro repo.
Reviewed By: davidaurelio
Differential Revision: D5121429
fbshipit-source-id: e77c6ccc23bef1d13fd74c4727be2d7e09d2d0ca
Summary:
fix problem of function scrollToEnd: There are some strange thing happened when contentSize.height(width) is smaller than bounds.size.height(width). In fact, there is no need to scroll in this case.
Thanks for submitting a PR! Please read these instructions carefully:
- [x] 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/13180
Differential Revision: D4928778
Pulled By: javache
fbshipit-source-id: 8b74833593ee317df726a4035ec71bbc77d13afe
Summary:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting `intrinsinc content size` of the `<Image>` impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #0.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5100021
fbshipit-source-id: 640c0fb2d1066e166d974efba39b4cfaaee7dd45
Summary: Adds support for “RAM bundle groups” (common section for module groups) to the new Buck integration
Reviewed By: jeanlauliac
Differential Revision: D5112065
fbshipit-source-id: 038c06b8f4133c7fcd39aba8bb04a5ef42594f3e
Summary: This is a first step towards doing an experiment I was talking about, that is, using the local directory (the directory where the config file lives) instead of the tmp dir, that is fragile.
Reviewed By: davidaurelio
Differential Revision: D5112326
fbshipit-source-id: 819636209972115e41213867f3eb78fbdf6ed9df
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
Fanghao Chen
Hector Ramos
Daniel Cestari
makadaw
Francisco Sales
Christoph Pojer
Feng999
Valentin Shergin
Pieter De Baets
Seraj Ahmad
David Aurelio
Emil Sjolander
Jean Lauliac
Kathy Gray
James Isaac
James Pearce
Tim Yung
Ian Hill
Georgiy Kassabli
Swordsman-Inaction
Matt Mahoney
G. Kay Lee
Adam Ernst
Reem Helou
Neo
Kevin Gozali
Brian Kabiro
Jean Regisser
