We don't strictly need this since all the other subspecs that use this set up the header search path for ReactCommon anyway but do it just for correctness.
Summary:
Resolves#16663.
Walked through the reproduction steps in #16663, but with successful build.
We can also now see the files are included in the `Pods` project:
<img width="236" alt="screen shot 2017-11-03 at 7 43 21 pm" src="https://user-images.githubusercontent.com/33126/32390596-4a06c05c-c0cf-11e7-8616-3ae547f8cca2.png">
(I noticed a subspec called `_ignore_me_subspec_for_linting_` so do we have tests for the podspec?)
[IOS] [BUGFIX] [React.podspec] - Resolves build error about missing symbols for PrivateDatabase.{cpp,h}
Closes https://github.com/facebook/react-native/pull/16664
Differential Revision: D6238178
Pulled By: hramos
fbshipit-source-id: b57007ab8c7c8bd0faf1f2f11269a7a2c28183e5
Summary:
The core React Native codebase already has full support for CocoaPods. However, `react-native link` doesn’t play nicely with CocoaPods, so installing third-party libs from the RN ecosystem is really hard.
This change will allow to link projects that contains its own `.podspec` file to CocoaPods-based projects. In case `link` detect `Podfile` in `iOS` directory, it will look for related `.podspec` file in linked project directory, and add it to `Podfile`. If `Podfile` and `.podspec` files are not present, it will fall back to previous implementation.
**Test Plan**
1. Build a React Native project where the iOS part uses CocoaPods to manage its dependencies. The most common scenario here is to have React Native be a Pod dependency, among others.
2. Install a RN-related library, that contains `.podspec` file, with `react-native link` (as an example it could be: [react-native-maps](https://github.com/airbnb/react-native-maps)
3. Building the resulting iOS workspace should succeed (and there should be new entry in `Podfile`)
Closes https://github.com/facebook/react-native/pull/15460
Differential Revision: D6078649
Pulled By: hramos
fbshipit-source-id: 9651085875892fd66299563ca0e42fb2bcc00825
Summary:
- The version check that ensures the JS and native versions match is now in its own module for two reasons: it is easier to test and it allows react-native-windows to override just this module to implement its own version check (ex: more advanced checks for RNW-specific code).
- Added unit tests for the version checking to specify its behavior more clearly, including parity between dev and prod to avoid prod-only behavior and mitigate SEVs.
- Prefixed the Obj-C `#define` with `RCT_` to conform with other RN globals.
Closes https://github.com/facebook/react-native/pull/16403
Differential Revision: D6068491
Pulled By: hramos
fbshipit-source-id: 2b255b93982fb9d1b655fc62cb17b126bd5a939a
Fix eslint
Fix flow
Revert "Improve Flow Types"
This reverts commit bee33a4400.
[0.50.0-rc.1] Bump version numbers
Fix Analyze step
Remove mockFs dependency and unblock tests
Revert "[0.50.0-rc.1] Bump version numbers"
This reverts commit 5d0bc1d29bfdce40bbcc403190b06324557e5a58.
Revert "Migrate to Circle 2.0"
This reverts commit 8fa9984b11.
Remove old circle
Comment out danger for now
Summary:
Now RCTTextInput relies on ivar to detect should it reconstruct inputAccessoryView or not.
Previously we checked `inputAccessoryView` directly which breaks some 3rd party libs.
See https://github.com/facebook/react-native/issues/16071 for more details.
cc douglasjunior
Reviewed By: javache
Differential Revision: D5994798
fbshipit-source-id: c086efdd24f5528393a4c734ff7c984e0ed740d1
Summary:
Queues Problem Intro:
UIManager queue is special queue because it has special relationship with
the Main queue.
This particular relationship comes from two key factors:
1. UIManager initiates execution of many blocks on the Main queue;
2. In some cases, we want to initiate (and wait for) some UIManager's work *synchronously* from
the Main queue.
So, how can we meet these criteria?
"Pseudo UIManager queue" comes to rescue!
"Pseudo UIManager queue" means safe execution of typical UIManager's work
on the Main queue while the UIManager queue is explicitly blocked for preventing
simultaneous/concurrent memory access.
So, how can we technically do this?
1. `RCTAssertUIManagerQueue` is okay with execution on both actual UIManager and
Pseudo UIManager queues.
2. Both `RCTExecuteOnUIManagerQueue` and `RCTUnsafeExecuteOnUIManagerQueueSync`
execute given block *synchronously* if they were called on actual UIManager
or Pseudo UIManager queues.
3. `RCTExecuteOnMainQueue` executes given block *synchronously* if we already on
the Main queue.
4. `RCTUnsafeExecuteOnUIManagerQueueSync` is smart enough to do the trick:
It detects calling on the Main queue and in this case, instead of doing
trivial *synchronous* dispatch, it does:
- Block the Main queue;
- Dispatch the special block on UIManager queue to block the queue and
concurrent memory access;
- Execute the given block on the Main queue;
- Unblock the UIManager queue.
Imagine the analogy: We have two queues: the Main one and UIManager one.
And these queues are two lanes of railway go in parallel. Then,
at some point, we merge UIManager lane with the Main lane, and all cars use
the unified the Main lane.
And then we split lanes again.
This solution assumes that the code running on UIManager queue will never
*explicitly* block the Main queue via calling `RCTUnsafeExecuteOnMainQueueSync`.
Otherwise, it can cause a deadlock.
Reviewed By: mmmulani
Differential Revision: D5935464
fbshipit-source-id: 6a60ff236280d825b4e2b101f06222266097b97f
Summary:
`CheckBox` component was introduced in v0.49.0 and not implemented on iOS.
Users who are trying to use `CheckBox` on iOS will get a warning that
> Native component for "AndroidCheckBox" does not exist
We should declare in the document that this component is Android only and use `UnimplementedView` for iOS.
- Use `react-native init` new project
- Apply pull request changes
- Add `<Checkbox />` after welcome text in `App.js`
- Run the app in iOS simulator
Closes https://github.com/facebook/react-native/pull/16211
Differential Revision: D6005393
Pulled By: hramos
fbshipit-source-id: 1c9b68b5e1c933496c4d7c2f487f0500264b603a
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Tests were failing due to not updated snapshot about TouchableHighlight.
Run `npm test`.
Closes https://github.com/facebook/react-native/pull/16185
Differential Revision: D6005399
Pulled By: hramos
fbshipit-source-id: eda5009b68ca121250817de448424105aec6f685
Summary:
I don't think a test plan is required here! 😛
Closes https://github.com/facebook/react-native/pull/16243
Differential Revision: D6005196
Pulled By: hramos
fbshipit-source-id: 3b46346e57e0d9971078c4807a4fa0045a8366b1
Summary:
This is pretty normal and harmless case, we should not crash here.
I plan to refactor similar places in this file soon.
Reviewed By: AaaChiuuu
Differential Revision: D5983443
fbshipit-source-id: 922fea8ed12ebef45d249f16739aa81fe3254f19
Summary: Remove RCTWebSocketObserver as it's not used anywhere in the project.
Reviewed By: shergin
Differential Revision: D5960354
fbshipit-source-id: a5b9d128f7cf9384a9fa9ed20e869801023e1d57
Summary: As RCTNativeModule can be destructed at any time, it's unsafe to capture "this" in a callback.
Reviewed By: javache
Differential Revision: D5963728
fbshipit-source-id: c80a01c851d97813e4fead2b31c442eaeb8ae204
Summary:
YellowBox currently assumes the first arg is a printf like format string, this adds support for any arguments so it works more like console in the browser. This also adds `stringifySafe` to format arguments when using printf style.
The main annoyance that this fixes is when trying to log a single object it will currently print [object Object] instead of the fully stringified version.
**Test plan**
Tested a bunch of different log combinations.
```js
console.warn({test: 'a'}); // {"test":"a"} (was [object Object] before this patch)
console.warn('test %s %s', 1, {}); // test 1 {}
console.warn('test %s', 1, {}); // test 1 {}
console.warn({}, {}, {}, {}); // {} {} {} {}
```
Closes https://github.com/facebook/react-native/pull/16132
Differential Revision: D5973125
Pulled By: yungsters
fbshipit-source-id: fc17105a79473a11c9b1c4728d435fc54fb094bb
Summary:
Motivation:
(SUDDENLY) There is a thing on Android called SpanWather, and their purpose is to notify "the watcher" about span-related changes in SpannableString. The idea is: some special kind of span can have some logic to prevent or tweak interleaving with some another kind of spans. To do so, it has to implement SpanWather interface.
So, EditText uses this to control internal spannable object (!) and SUDDENLY (＃＞＜) calls internal "layout" method as a reaction to adding new spans. So, when we are cloning SpannableString, we are (re)applying same span objects to a new spannable instance, and it causes notifying other spans in the string, and they notify EditText, and the EditText does relayout and... BOOM!
So, the solution is, easy, we should use SpannableStringBuilder instead of SpannableString because it does not notify SpanWather during cloning.
See:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/text/SpannableStringBuilder.java#101
(the first argument is `false`).
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/text/SpannableStringBuilder.java#678
Compare with:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/text/SpannableStringInternal.java#43
Why? I believe because SpannableStringBuilder objects are "unfinished" by design, and documentation said: "it is the caller's responsibility to restore invariants [among spans]". As we do an exact clone of the string, that's perfectly okay to assume that all invariants were already satisfied for original string.
Reviewed By: achen1
Differential Revision: D5970940
fbshipit-source-id: 590ca0e3aede4470b809c7db527c5d55ddf5edb4
