Summary: ListView is deprecated and SwipeableListView uses ListView. Thus, it is deprecated as well.
Reviewed By: RSNara
Differential Revision: D10437408
fbshipit-source-id: a08391d5b099e74b6ec179cd940ac404b2e702f4
Summary: This adds a callback for <Text> to get metrics about the rendered text. It's divided by line but that could be changed to "fragments" (which makes more sense for multi-lingual). Right now by line is convenient as you frequently want to know where the first and last line end (though we could make this work with fragments I suppose).
Reviewed By: shergin
Differential Revision: D9440914
fbshipit-source-id: bb011bb7a52438380d3f604ffe7019b98c18d978
Summary:
1. The user inserts a character ('0') at index 0. Because the range matches 0, 0, predictedText is set to that character that was inserted.
2. In textInputDidChange, it discovers a mismatch between the rendered text ('1234') and predicted text ('0')
3. This triggers textInputShouldChangeTextInRange to be called again with the 'new' text that it thinks was just added ('1234')
4. It goes to insert this text, but runs into the maxLength limit, so it gets truncated and then inserted.
(I'm not totally sure why only happens if maxLength is set - I need to look into that.)
One fix for this is to just get rid of the range check, but that'll regress #18374. I decided to just check and see if the rendered text is empty instead of checking the range where text could be inserted, since that seems like it should properly handle both cases.
Reviewed By: shergin
Differential Revision: D10392176
fbshipit-source-id: 84fb3b6cac9b0aa25b3c1a127d43f9cdc5a1c6a8
Summary:
Related to https://github.com/facebook/react-native/pull/21488
Disclaimer: I made this PR.
I think there's some requestAnimationFrame events that are not cleared on unmount because of bad use of `splice` method.
- All flow tests succeed.
- RNTester: iOS (this change should only affect iOS because calculateChildFrames is iOS only)
Show perf monitor, show ListView* screen, start scrolling. UI frame Rate is used at the beginning. When scrolling there is no drop in FPS rate.
- TODO: I'll write a load test for ListView
[GENERAL] [ENHANCEMENT] [ListView.js] - rm TimerMixin
Pull Request resolved: https://github.com/facebook/react-native/pull/21802
Differential Revision: D10391812
Pulled By: RSNara
fbshipit-source-id: 49f0b0a4641ec29bcb4cc04bd3bafb42b3842b69
Summary:
Related to #21485
- Remove TimerMixin from ListView
- All flow tests succeed.
- RNTester: <ListView> iOS (this change should only affect iOS because calculateChildFrames is iOS only)
Show perf monitor, show ListView* screen, start scrolling. UI frame Rate is used at the beginning. When scrolling there is no drop in FPS rate.
TODO: I think a load test would be more relevant:
- Update props multiple times and scroll
[GENERAL] [ENHANCEMENT] [ListView.js] - rm TimerMixin
Pull Request resolved: https://github.com/facebook/react-native/pull/21488
Differential Revision: D10219088
Pulled By: RSNara
fbshipit-source-id: 946e4fc1319324c5bf4947a2060b18bebb6fc493
Summary: Currently the pull to refresh icon on browse feed is super cut off on Android. Expose the progressViewOffset prop from FBPullToRefresh to support offsetting the PTR component to make the component more visible.
Reviewed By: yungsters
Differential Revision: D10274679
fbshipit-source-id: 1735c4d2d98523ccc3d1ec3733465028ae33df7b
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.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
_Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!_
Pull Request resolved: https://github.com/facebook/react-native/pull/21396
Differential Revision: D10119630
Pulled By: RSNara
fbshipit-source-id: d0fe193eee976b9b18a2eb467b5f3af48bd7d2de
Summary:
This test is disabled internally and flaky in open source causing CI to fail. Skipping it for now.
Related to: https://github.com/facebook/react-native/issues/21517
Reviewed By: RSNara
Differential Revision: D10223498
fbshipit-source-id: 37a3798c0abb7de829bc5b59e02f23d8943da882
Summary: Fixes the runtime value of `ReactNativeStyleAttributes` to correctly map to `true` instead of strings (as returned by `keyMirror`).
Reviewed By: TheSavior
Differential Revision: D10057235
fbshipit-source-id: dc855cff3a114761098ed5176b2e6e25412481dc
Summary: The legacy implementation doesn't provide additional functionality and has a negative impact on performance and user experience. The legacyImplementation prop is deprecated and will be removed in a future release.
Reviewed By: yungsters
Differential Revision: D10212762
fbshipit-source-id: 9b3416434ba392827b538c984c7ab4bcbe156e60
Summary: This component has long been deprecated in the docs. Adding a warning to the code.
Reviewed By: sahrens
Differential Revision: D10261155
fbshipit-source-id: 462ce30a97f35e52477cfc135fb50c976b56e9cb
Summary: Upgrades all dependents of `fbjs` to the latest version.
Reviewed By: mjesun
Differential Revision: D10100661
fbshipit-source-id: 2e2af616cb2b5eab560872b6c6c60ed264e986b2
Summary:
This fixes#19193
Characters of different languages may have different height and different baseline, even with a same font and same font-size. When they mixed together, iOS will adjust their baselines automatically, to display a suitable view of text.
The problem is the behavior of dealing with the text-style property 'lineHeight'.
It once to be a right way at version 0.52.3, to setting a base-line-offset attribute for the whole range of the string. However, in current version, it enumerated the string, and set a different base-line-offset for different font-height characters.
And this behavior broke the baseline adjustment made by the iOS. It just make every character's baseline aligned to a same line. But it is not supposed to displaying characters of different languages like that. Chinese characters' baseline is the bottom of each, however, it is not for English characters.
So maybe it is the better way to give a same value of base-line-offset attribute for the whole string. And this PR just did that: found the biggest value of font-height in the text, and calculate the offset with that biggest value, then set to the whole string. This will keep the origin baseline adjustment for different languages' chars made by iOS.
Since I always got an error when running the snapshot test locally, I can't even pass the them with the unmodified code in master branch.
The error is "Nesting of \<View\> within \<Text\> is not currently supported."
After I comment all of the check of that error from the source code, I got a different snapshot from the reference ones. It seems that all components which will cause that error are not rendered in the reference images.
Since this PR changed the behavior of 'lineHeight' property, it's better to add a new snapshot case for the situation of different-language-characters' mixture. So maybe somebody could help me with that or maybe it should be a issue?
[IOS] [BUGFIX] [Text] - fix the baseline issue when displaying a mixture of different-language characters
Pull Request resolved: https://github.com/facebook/react-native/pull/19653
Differential Revision: D10140131
Pulled By: shergin
fbshipit-source-id: 646a9c4046d497b78a980d82a015168cf940646b
Summary:
@public
We're seeing a crasher where `self` on line 54 isn't an `RCTNetInfo`. The timing looks related to D9798488, so my theory is that this class is being deallocated before it resolves, and thus causes a crash.
Reviewed By: PeteTheHeat
Differential Revision: D10127341
fbshipit-source-id: 94eaba7def6b118092adcf6b4cce841ccc7d0b59
Summary:
`new Date().getTime()` is equal to `Date.now()`.
`Date.now()` avoids an allocation, which can save some GC time.
This micro-optimization isn't worth it in most places, but since MessageQueue is one of the hottest pieces of JS in RN, it's worth it.
Reviewed By: javache
Differential Revision: D9972334
fbshipit-source-id: 05d78fd65304f0f27115d76b8b52db11a52c86a0
Summary:
Fixes#18223
This is a fairly simple solution to what seems to be a recurring issue where certain requests that result in an empty body where JSON is expected throw an error rather than being handled gracefully. Client side error handling is not being hit as this is being thrown at a lower level.
Make a http request that results in an empty blob: ""
[INTERNAL] [BUGFIX] [XMLHttpRequest.js] - Line 262
Pull Request resolved: https://github.com/facebook/react-native/pull/19567
Differential Revision: D8314416
Pulled By: hramos
fbshipit-source-id: a17c49f3620f0abbb936f3a1c2b01aa1b64820fd
Summary:
Fixes#20797
As mentioned in #20797 when running `react-native run-ios Xcode 9.2 will complain about the nullability of pointers in `RCTLinkingManager.h`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20798
Differential Revision: D9988581
Pulled By: hramos
fbshipit-source-id: e3ce7736da97d314a421c2c1ab71577864081642
Summary: This diff adds a new property in ReactWebView to be able to configure allowFileAccess
Reviewed By: achen1
Differential Revision: D9789466
fbshipit-source-id: 39d042ac6ef69e44f006a4c4b0c2dd900f84dbc9
Summary: Apparently different apps have different implementations of view managers that support different props. This is a problem that we will need to address. Unfortunately, this means we can't have a static config defined in JS. We will need to find another approach to this problem.
Reviewed By: sahrens
Differential Revision: D9500178
fbshipit-source-id: b591559164fcf29f5fd43e13a0f2da15011491c6
Summary: As we move these configs to JS from native, until we have codegen that ensures everything stays up to date, this adds a dev mode check to ensure they are consistent.
Reviewed By: yungsters
Differential Revision: D9475011
fbshipit-source-id: 9d6f7b6c649229cae569d840eda3d5f7b7aa7cb2
Summary: Moving this config to native for android so we skip the native lookup for the config.
Reviewed By: yungsters
Differential Revision: D9415726
fbshipit-source-id: 84cac3f0dfa4f6ea8800de77676f1e2896ee463d
Summary:
Fixing error
node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedNodesManager.h:12:9: 'RCTAnimation/RCTValueAnimatedNode.h' file not found
I'm integrating react native into an existing app through cocoa pods and similar to other PRs
PR https://github.com/facebook/react-native/pull/16192
PR https://github.com/facebook/react-native/pull/16271
PR https://github.com/facebook/react-native/pull/17764
When integrating with cocoa pods
```
pod 'React', :path => './node_modules/react-native', :subspecs => [
'Core',
'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
'RCTText',
'RCTNetwork',
'RCTWebSocket', # needed for debugging
'RCTImage',
'RCTWebSocket',
'BatchedBridge',
'RCTLinkingIOS',
'RCTActionSheet',
'RCTAnimation'
]
```
With `RCTAnimation` being the important part for this PR.
Also note without this PR and the other PR's above if anyone is trying to integrate react native into an existing app i.e. through cocoa pods they won't be able too. I think the latest working version is
My app wouldn't build without changing this line
PR https://github.com/facebook/react-native/pull/16192
PR https://github.com/facebook/react-native/pull/16271
PR https://github.com/facebook/react-native/pull/17764
[IOS] [BREAKING] [PODS] - Fixed RCTAnimation import for integrating with cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/18050
Differential Revision: D9235162
Pulled By: hramos
fbshipit-source-id: 426daccf8d8952658e262d5a0e4623c72c38542c
Summary: This caught a few flow types that weren't defined for attributes that Android exposes. Ensuring that these stay in sync will be necessary for codegen in the future.
Reviewed By: sahrens
Differential Revision: D9444165
fbshipit-source-id: 8ee00af7b732c35d7f6befcdf79f77b73eac6a1b
Summary: Moving this config to native for android so we skip the native lookup for the config.
Reviewed By: yungsters
Differential Revision: D9415726
fbshipit-source-id: 84cac3f0dfa4f6ea8800de77676f1e2896ee463d
Summary:
As we add js view configs to our view managers, we want this type to be a little bit more strict.
This will be especially useful as we start removing certain keys (like NativeProps) which aren't actually necessary, this will make sure we remove them everywhere.
Reviewed By: yungsters
Differential Revision: D9416905
fbshipit-source-id: 6b12e38b9d56969a81ec5d4f2920298e4919f7be
Eli WhiteandLorenzo Sciandra
Mehdi MulaniandLorenzo Sciandra
Emily JanzerandLorenzo Sciandra
Thomas BARRASandLorenzo Sciandra
Andy HuangandLorenzo Sciandra
Andrey LunyovandLorenzo Sciandra
Radovan ŠmitalaandLorenzo Sciandra
Hyunjong LeeandLorenzo Sciandra
Tim YungandLorenzo Sciandra
Mike Grabowski
Radek CzemerysandMike Grabowski
BingBingandMike Grabowski
Hector Ramos
Riley DulinandMike Grabowski
anthonyandMike Grabowski
Warren KnoxandLorenzo Sciandra
David VaccaandLorenzo Sciandra
Karan ThakkarandLorenzo Sciandra
Chun ChenandLorenzo Sciandra
lukedurrantandHector Ramos
magicienandHector Ramos
