Summary:
For backwards-compatibility with Paper, we're implementing a feature in Fabric that will allow TextInputs to use the default padding from the theme in Android.
Note that this uses some pretty ugly hacks that probably shouldn't be used inside of components at all: looking directly at rawProps, overriding props/Yoga styles in the component descriptor, etc. I would (personally) really like to kill this feature entirely unless and until we can find a more elegant solution.
Changelog: [Internal]
TextInputs are still not pixel-perfect with Paper, but they're much closer, and the underline visual glitchiness is no longer an issue.
Reviewed By: mdvacca
Differential Revision: D20109605
fbshipit-source-id: 543282843e0a9f03a504d72d7a014431099bd64c
Summary:
Before this change, C++ couldn't propagate changes that updated TextInputs that were completely empty. In C++ the AttributedString cannot contain Fragments with empty text, so a completely empty TextInput would have no Fragments; this breaks the C++ state value updating infra since it relies on copying over existing fragments.
Instead, now we propagate default TextAttributes and ShadowView through State, so that State updates can use them to construct new Fragments.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18835048
fbshipit-source-id: 58ac94c5454c8610c6287b096b62199045e5879b
Summary:
Support for modifying AndroidTextInputs with multiple Fragments was added on the Java side in a previous diff.
This diff adds support on the C++ side for the following scenario:
A <TextInput> is initially given contents via children <Text> notes, which represents multiple Fragments (that could have different TextAttributes like color, font size, backgroundcolor, etc). The Android EditText view must get this initial data, and then all updates after that on the Android side must flow to C++ so that the C++ ShadowNode can perform layout and measurement with up-to-date data.
At the same time, the <TextInput> node could be updated from the JS side. All else equal, this would cause the native Android EditText to be replaced with the old, original contents of the <TextInput> that may not have been updated at all from the JS side.
To mitigate this, we keep track of two AttributedStrings with Fragments on the C++ side: the AttributedString representing the values coming from <TextInput> children, from JS (`treeAttributedString`); and the AttributedString representing the current value the user is interacting with (`attributedString`). If the children from JS don't change, we don't update Android/Java with that AttributedString. If the children from JS do change, we overwrite any user input with the tree from JS.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18785976
fbshipit-source-id: a1f3a935e02379cabca8ab62a39cb3c0cf3fbca5
Summary:
This is necessary for allowing TextInput updates from Java.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739831
fbshipit-source-id: 0ba2d7eac96cac7471c5e46cc1e03a4d065229f5
Summary:
iOS and other platforms have direct access to C++ StateT structs, whereas Java only has access to a Java map equivalent - state updates from Java can't update complex types, or must incur significant cost to reconstruct large objects from their folly::dynamic representation (not to mention the complexity of implementing the Java-to-C++ struct converters). Thus it's hard for Java to update StateT's with complex types on the C++ side.
This diff makes a minor change to Android's updateState which uses both the folly::dynamic data from Java as well as the previous State, so each StateT can have fields that are read-only from the Java perspective.
Motivation: For AndroidTextInput we need to set params from Java, without being able to send all of the State params from Java.
In this diff, we introduce a new State constructor that takes the previous State value and a folly::dynamic. It is up to each State implementation how the additional parameter will be used.
We migrate every existing component except for AndroidTextInput in this diff.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18672365
fbshipit-source-id: 4469e0a3c7658c204089c6fed39394979883f124
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
generatedunixname89002005287564
Joshua Gross