Summary:
Changelog:
[Internal] - Add default value for accessibilityState "checked" and handle unhandled states.
It is also work for the case that accessibilityRole = "switch" and accessibilityState is set.
Reviewed By: sammy-SC
Differential Revision: D22914427
fbshipit-source-id: 4767a21f3bd109019b57bc09918758a38fbdea93
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
Changelog:
[Internal] - Add an condition to exclude accessibilityRole that not currently used
Since I've added all the possible values in accessibilityRole enum, it is necessary to gate what needs to be an accessibilityElement. SO I add a condition to exclude accessibilityRole that not currently used.
Reviewed By: shergin
Differential Revision: D22559136
fbshipit-source-id: 910d59132984872b5a9816b8e390117b7b1e2e71
Summary:
Changelog:
[Internal] - Reword the guide words to make it more generic.
Considering the case that some languages are RTL so swiping right cannot guarantee to move to the link. iOS can handle the order of the words and accessibilityElements according to the language. But the accessibilityHint we hardcoded would be an issue. So we decided to reword it to be more generic.
Reviewed By: PeteTheHeat
Differential Revision: D22422498
fbshipit-source-id: 175711317961663d0b0b47e04d2ab600f63446fe
Summary:
Changelog:
[Internal] - Add a `accessibilityHint` to the first accessibilityElement so that it will tell user double tap to expand or truncate the text after reading the whole text. Also add the `accessibilityRole` in `FBTextWithEntities` when shouldTruncated is true, which allow us to specially distinguish the shouldTruncated text.
Reviewed By: sammy-SC
Differential Revision: D22339875
fbshipit-source-id: ce22fe9d86eeba5a2750022acd2cdd2c06a1dc79
Summary:
This refined algorithm now takes a zoom/scale into account and deals with `contentInset` properly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22382482
fbshipit-source-id: 7e9d34d3bababf68e624c045c308957e7e5c9d84
Summary:
Changelog: [Internal]
When JS Inspector is activated, ScrollView is unmounted and then mounted again with same state.
ScrollView's content offset was being set to 0 inside `[RCTScrollViewComponentView prepareForRecycle]` during unmount but when it is mounted again, we ignored value inside state.
Reviewed By: shergin
Differential Revision: D22333125
fbshipit-source-id: f232dc95b695605f4819f29d8e0bf14b2f3e9150
Summary:
Changelog:
[iOS][Added] - This is the first step to build RCTParagraphComponentAccessibilityProvider. The main idea of RCTParagraphComponentAccessibilityProvider is to provide an array of accessible elements for the AttributedString in PCTParagraphComponentView.
Reviewed By: sammy-SC
Differential Revision: D22214855
fbshipit-source-id: 69d47555e86452620f89a4b2e21ed6065c8e669c
Summary:
This is the first implementation stage of on-demand child views mounting for <ScrollView> feature.
It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area.
Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling.
This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304012
fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary:
The method does not do anything besides calling a super method. Even if this method does nothing special, overriding it can have negative performance implications.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22309895
fbshipit-source-id: bd8237d15df20017629223f278b1b6ac628b0cc7
Summary:
Changelog: [Internal]
Introducing InputAccessoryView.
There is one big difference between Fabric's implementation and Paper's implementation.
Fabric searches for text input from InputAccessoryView, unlike Paper where it is the other way around.
Reviewed By: shergin
Differential Revision: D22160445
fbshipit-source-id: 55313fe50afeced7aead5b57137d711dd1cfd3ae
Summary:
Changelog: [Internal]
The methods were out of order, this diff reorders them.
Reviewed By: shergin
Differential Revision: D22233255
fbshipit-source-id: ea66bc701c4d021ec5721e191bc0d3413b3d36ae
Summary:
Changelog: [Internal]
Add support for dynamic font size.
New class `ThreadStorage` is introduced, which is used to pass LayoutContext to `YogaLayoutableShadowNode::yogaNodeMeasureCallbackConnector`.
## Shortcoming
This implementation doesn't cause re-render, if user changes font size and comes to the app without restarting it, it will show old font size. I believe this is fine for now as most people set their font size before they use the app and keep the same setting for a long time.
Reviewed By: shergin
Differential Revision: D22043728
fbshipit-source-id: 7453d165c280a2f4bcb73f4ee6daf9e64b637ded
Summary:
Changelog: [Internal]
Paper views are not designed to be recycled, that's why a new view is created each time legacy interop layer is used.
However paper view was not deallocated immediately after it was used, it was still being strongly referenced by `self.contentView`.
This doesn't cause an immediate issue because eventually when legacy interop layer does get reused, it will create a new paper view and replace the old one inside `self.contentView`, triggering deallocation of the old one. But we were retaining the paper view beyond what was necessary.
Reviewed By: mdvacca
Differential Revision: D22066022
fbshipit-source-id: 17c3b81468f50ebcc05f1a7cdf4d4b9b00965fc3
Summary:
Changelog: [Internal]
There is no need for custom dealloc, let's get rid of it.
We also prefer east const over west const.
Reviewed By: shergin
Differential Revision: D21997545
fbshipit-source-id: aa017f99aa26421fc59b353d0012687cb38fac08
Summary:
Changelog: [Internal]
Here is what I believe happens.
We have an instance of `RCTSliderComponentView` which has green thumb tint color.
It gets reused, in prepareForRecycle we call `setThumbTintImage:nil` on its UISlider which internally sets an ivar to `nil`.
Next time `RCTSliderComponentView` gets used without explicit thumb tint color, we assign nil to UISlider's thumb tint color.
Internally this nil gets compared to nil that it saved during `prepareForRecycle` and concludes that the value is already sets and exists early.
Since we don't have access to `UISlider` I can't prove this but here is a short video where I showcase this behavior
{F239923204}
The code in video is here P133083862.
Reviewed By: shergin
Differential Revision: D21997324
fbshipit-source-id: 28a11ed817cc863a313217c475042918ee726011
Summary:
Changelog: [internal]
We were not reseting value of slider when recycling, this would result in wrong value being displayed once slider gets reused.
Reviewed By: shergin
Differential Revision: D21996786
fbshipit-source-id: 3beac4936d0719c4ac5ac0499209300a912f6986
Summary:
Changelog: [Internal]
# Problem
We were recording mount child component calls with its arguments and the replaying them inside `finalizeUpdates`.
However we store the events in NSDictionary where `key` was index at which the child should be added.
Then in `finalizeUpdates` we iterated over this NSDictionary and added those views into our paper view.
`NSDictionary` is unordered, it isn't guaranteed what was first inserted into it, will be first iterated over.
# Solution
Use `NSMutableArray` instead which guarantees order.
Reviewed By: shergin
Differential Revision: D21685993
fbshipit-source-id: 3b933f05125130eef175d7a8a56f29012ee76bb3
Summary:
Changelog: [Internal]
If you look at implementation of hit testing in `RCTViewComponentView`
```
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
if (UIEdgeInsetsEqualToEdgeInsets(self.hitTestEdgeInsets, UIEdgeInsetsZero)) {
return [super pointInside:point withEvent:event];
}
CGRect hitFrame = UIEdgeInsetsInsetRect(self.bounds, self.hitTestEdgeInsets);
return CGRectContainsPoint(hitFrame, point);
}
```
you will notice that we use `UIEdgeInsetsInsetRect` to calculate hitFrame. The input for this function is bounds and `hitTestEdgeInsets`. `hitTestEdgeInsets` is our hitSlop.
Look at documentation of `UIEdgeInsetsInsetRect`, it says "Adjusts a rectangle by the given edge insets.".
So if you give it a positive edge insets, it will make the rect smaller.
That's why we need to reverse values of hitSlop to negative before assigning it to `hitTestEdgeInsets`.
Paper does the same thing here https://github.com/facebook/react-native/blob/d0871d0a9a373e1d3ac35da46c85c0d0e793116d/React/Views/RCTViewManager.m#L304-L305
Reviewed By: mdvacca
Differential Revision: D21661894
fbshipit-source-id: c3dd6c55b68e4fdef8589ca8f0484e2837b4136c
Summary:
Changelog: [Internal]
# Problem
We call `_state->updateState` anytime safe area insets changes.
Once that is called, `_state` still holds old value, so when we check whether there is big enough of a difference, we are actually checking it against old value of state until `updateState` is called from MountingManager.
This causes `_state->updateState` to be called dozens of times (I measured 47, with this diff it fell to 22) when displaying a safe area view inside Modal.
# Solution
Create new ivar `_lastPaddingStateWasUpdatedWith` where we store last padding that was sent through `_state->updateState` and compare new inset with this value instead of last value stored in state.
Reviewed By: shergin
Differential Revision: D21596367
fbshipit-source-id: b9249b8ef444ea532ec8b86a15a32c733eb6f987
Summary:
Changelog: [Internal]
Using `empty()` vs `size() == 0` or `size() > 0`.
It is a more semantic way to check whether container is empty or not.
Reviewed By: JoshuaGross
Differential Revision: D21573183
fbshipit-source-id: b83283f687432a037941852114717a0f014e28db
Summary:
Changelog: [Internal]
ScrollView didn't support centerContent prop. The implementation is copied over from Paper.
I added an example of this prop in RNTester.
Reviewed By: JoshuaGross
Differential Revision: D21548270
fbshipit-source-id: 28f6c8d769c5a6bc1d111b33970a06b95c259132
Summary:
Changelog: [internal]
As part of recycle, we should delete state. This is a common pattern used in other components as well.
Reviewed By: shergin
Differential Revision: D21348782
fbshipit-source-id: a5dee2f4ccee9b19498db31dab1983d8879dca71
Summary:
In D20836890 we no longer set `_contentView.frame` inside `layoutSubviews`.
This doesn't work well with component views that set their `contentView` after `updateLayoutMetrics` is called. For Example legacy interop which sets its contentView in the `finalizeUpdates` method. Other component views that set their contentView during initialisation are fine.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21302108
fbshipit-source-id: 5adcf489e4e650ac04b84c836a8f8d6f55a77267
Summary:
Changelog: [Internal]
When there is a change coming from javascript, avoid triggering `onChange ` and `onSelectionChange` events since JavaScript already has these changes. This is only necessary for multiline text.
For changes coming through view commands, do not increment `_mostRecentEventCount`.
Reviewed By: shergin
Differential Revision: D21255228
fbshipit-source-id: e972dab0eb3dd21f611ee5c71d755bab593ae9cc
Summary:
Changelog: [Internal]
In `onKeyPress` event, we were not returning `key` property. This diff adds `key` property to `onKeyPress` event and removes other, redundant properties from `onKeyPress` event.
The implementation has been translated from Paper.
Reviewed By: shergin
Differential Revision: D21250411
fbshipit-source-id: f1e31381667acb9dec02d0b33883df8f8f5b2a4b
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885163
fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af
Summary:
Changelog: [Internal]
We don't use view command `setMostRecentEventCount`, let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D21016600
fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b
Summary:
Changelog: [Internal]
Calling `_backedTextInputView.attributedText = attributedString` causes cursor to be moved to the end of text input.
This applies to both, `UITextField` and `UITextView`.
This is not desired as when JS sets a new text, we don't want the cursor to be moved to the end of text input.
JS has the option to use view commands if it wishes to move cursor somewhere.
Reviewed By: JoshuaGross
Differential Revision: D20836201
fbshipit-source-id: 9234e54cfbc5fc206f723626988e505275788aae
Summary:
Changelog: [Internal]
UIKit uses either `UITextField` or `UITextView` as its UIKit element for `<TextInput>`. `UITextField` is for single line entry, `UITextView` is for multiline entry.
There is a problem with order of events when user types a character.
In `UITextField` (single line text entry), typing a character first triggers `onChange` event and then `onSelectionChange`. JavaScript depends on this order of events because it uses `mostRecentEventCount` from this even to communicate to native that it is in sync with changes in native.
In `UITextView` (multi line text entry), typing a character first triggers `onSelectionChange` and then `onChange`. As JS depends on the correct order of events, this can cause issues. An example would be a TextInput which changes contents based as a result of `onSelectionChange`. Those changes would be ignored as native will throw them away because JavaScript doesn't have the newest version.
Reviewed By: JoshuaGross
Differential Revision: D20836195
fbshipit-source-id: fbae3b6c0d388fc059ca2541ae980073b8e5f6c7
Summary:
Changelog: [Internal]
Setting `_borderLayer.frame` inside `-[RCTViewComponentView layoutSubviews]` causes unwanted animation because it is not wrapped in `CATransaction`.
Moving it to `-[RCTViewComponentView updateLayoutMetrics]` which is called inside `CATransaction`.
Reviewed By: shergin
Differential Revision: D20836890
fbshipit-source-id: 2048a25fd2edb8109f6275c1186c0adae4b9f504