Summary:
The relevant changes in the PR are to Libraries/StyleSheet/EdgeInsetsPropType.js; the rest are just removals of FlowIgnores.
The definition of the relevant types is [here](https://github.com/facebook/flow/blob/master/lib/react.js#L262-L271).
The long and short of it is that for whatever reason, Flow is unable to realize that `ReactPropsChainableTypeChecker` is a subtype of `ReactPropsCheckType` unless we assert it. Once we explicitly hint this to the typechecker, it realizes that `EdgeInsetsPropType` is indeed a valid React PropType, and stops complaining that it isn't.
Closes https://github.com/facebook/react-native/pull/16437
Differential Revision: D6109742
Pulled By: sahrens
fbshipit-source-id: e4e10720b68c912d0372d810409f389b65d7f4b1
Summary:
The title speaks for itself. Docs regarding secureTextEntry of TextInput were not descriptive enough. Owing to that, it took me more than an hour of debugging to find the issue of why the TextInput in my app was not hiding the input with secureTextEntry.
<!--
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!
-->
Closes https://github.com/facebook/react-native/pull/16272
Differential Revision: D6060614
Pulled By: ericnakagawa
fbshipit-source-id: 419ad6956e67b9adefae8d789b3fd76181c4194b
Summary:
References #7070
<!--
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!
-->
Docs are incomplete, start filling them out
N/A
Closes https://github.com/facebook/react-native/pull/16346
Differential Revision: D6057501
Pulled By: hramos
fbshipit-source-id: c30d3369fa1a73ef6a93c2ed8f8c53af5a1af7ee
Summary:
`visible-password` represents a very basic keyboard, typically only
letters and numbers. Backed by InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD,
it is useful for things like password and code entry fields. It can also be more
effective than autoCorrect={false} for disabling autocompletion on some keyboards
(like Gboard).
Note `secureTextEntry` also affects `TYPE_TEXT_VARIATION_*` flags internally, so there
may be some undefined behavior when combining `secureTextEntry` with
`keyboardType="visible-password"`
Also, while here, improve the documentation on TextInput to explicitly enumerate
which keyboardType applies to Android vs. iOS (since this is the first android-specific)
Reviewed By: shergin
Differential Revision: D6005353
fbshipit-source-id: 13af90c96353f714c0e106dd0fde90184a476533
Summary:
Currently, only `Text` supports the `allowFontScaling` prop. This commit adds support for it on `TextInput`.
As part of this change, the TextInput setters for font attributes (e.g. size, weight) had to be refactored. The problem with them is that they use RCTFont's helpers which create a new font based on an existing font. These helpers lose information. In particular, they lose the scaleMultiplier.
For example, suppose the font size is 12 and the device's font multiplier is set to 1.5. So we'd create a font with size 12 and scaleMultiplier 1.5 which is an effective size of 18 (which is the only thing stored in the font). Next, suppose the device's font multiplier changes to 1. So we'd use an RCTFont helper to create a new font based on the existing font but with a scaleMultiplier of 1. However, the font didn't store the font size (12) and scaleMultiplier (1.5) separately. It just knows the (effective) font size of 18. So RCTFont thinks the new font has a font size of 18 and a scaleMultiplier of 1 so its effective font size is 18. This is incorrect and it should have been 12.
To fix this, the font attributes are now all stored individually. Anytime one of them changes, updateFont is called which recreates the font from scratch. This happens to fix some bugs around fontStyle and fontWeight which were reported several times before: #13730, #12738, #2140, #8533.
Created a test app where I verified that `allowFontScaling` works properly for `TextInputs` for all values (`undefined`, `true`, `false`) for a variety of `TextInputs`:
- Singleline TextInput
- Singleline TextInput's placeholder
- Multiline TextInput
- Multiline TextInput's placeholder
- Multiline TextInput using children instead of `value`
Also, verified switching `fontSize`, `fontWeight`, `fontStyle` and `fontFamily` through a bunch of combinations works properly.
Lastly, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14030
Reviewed By: TheSavior
Differential Revision: D5899959
Pulled By: shergin
fbshipit-source-id: c8c8c4d4d670cd2a142286e79bfffef3b58cecd3
Summary:
Currently `TextInput.autoCapitalize` is defaulting to 'none' on Android. This PR sets the default to 'sentences', to match iOS and the PropTypes documentation.
Fixes#14846
Closes https://github.com/facebook/react-native/pull/14853
Differential Revision: D5918196
Pulled By: shergin
fbshipit-source-id: d0d00e75d44a410c6821b4ff8910099aae2b2c7c
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!
-->
I am a web developer, who recently started coding for mobile apps using react-native. I was trying to use the `inlineImageLeft` props of TextInput, but I found that it's docs weren't sufficient. So a PR for it.
No code change. Updated the docs under website folder. Screenshot for the change below.
Closes https://github.com/facebook/react-native/pull/15708
Differential Revision: D5738795
Pulled By: hramos
fbshipit-source-id: b8b6cbac5c50abd4d8a6ef8089dc9d92bc0b7f6f
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!
-->
(Write your motivation here.)
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
Closes https://github.com/facebook/react-native/pull/15515
Differential Revision: D5648285
Pulled By: hramos
fbshipit-source-id: fc1e50ffd18cc234771c5f40f92549e7e87cd28e
Summary:
This replaces all uses of `React.createClass` with `createReactClass` from the `create-react-class` package, attempting to match use of `var` and `const` according to local style.
Fixes#14620
Refs #14712
Closes https://github.com/facebook/react-native/pull/14729
Differential Revision: D5321810
Pulled By: hramos
fbshipit-source-id: ae7b40640b2773fd89c3fb727ec87f688bebf585
Summary:
In `TextInputState`'s `blurTextInput()` documentation, the parameter description`id of the text field to focus` should be `id of the text field to unfocus`, since this is `blurTextInput` and not `focusTextInput`.
N/A (just documentation fix).
Closes https://github.com/facebook/react-native/pull/14367
Differential Revision: D5200263
Pulled By: shergin
fbshipit-source-id: b3e9ab60e555ad9050474b59a728761180618190
Summary:
Because it introduces inconsistency in RN layout model, confuses people and hurts dev experience.
The original problem was introduced in D1611014 as an attempt to address the intrinsic size issue.
So, now <TextInput> has intrinsic size (D5069971) and we don't need this hack anymore.
GH issues:
https://github.com/facebook/react-native/issues/11892https://github.com/facebook/react-native/issues/9646
Reviewed By: javache
Differential Revision: D5072833
fbshipit-source-id: d9a60ab09b728e6de89bfa53eda07069377f1369
Summary:
cc hramos
Pretty sure I've hit all of the places where AppRegistry is called in CRNA-pastable examples. Let me know whether you think we need to approach the version lag differently, I figure a caveat is as natural a place to call it out as any.
If you end up finding anything else that needs tweaking before cherry picking, I'm happy to push that up here too.
Closes https://github.com/facebook/react-native/pull/13744
Differential Revision: D5071038
Pulled By: hramos
fbshipit-source-id: 4a4a6f2a73079aca627f17d75a4e4b395ecbd4a8
Summary:
Several things:
* The mess with insets was fixed. Previously we tried to compensate the insets difference with `UITextField` by adjusting `textContainerInset` property, moreover we delegated negative part of this compensation to the view inset. That was terrible because it breaks `contentSize` computation, complicates whole insets consept, complicates everything; it just was not right. Now we are fixing the top and left inset differences in different places. We disable left and right 5pt margin by setting `_textView.textContainer.lineFragmentPadding = 0` and we introduce top 5px inset as a DEFAULT value for top inset for common multiline <TextInput> (this value can be easilly overwritten in Javascript).
* Internal layout and contentSize computations were unified and simplified.
* Now we report `intrinsicContentSize` value to Yoga, one step before auto-expandable TextInput.
Depends on D4640207.
Reviewed By: mmmulani
Differential Revision: D4645921
fbshipit-source-id: da5988ebac50be967caecd71e780c014f6eb257a
Summary:
Because `TextInput` only render the `defaultValue` of `string`, when using other types of values, it will render empty('') without any Warnings.
Closes https://github.com/facebook/react-native/pull/11478
Differential Revision: D4340132
Pulled By: lacker
fbshipit-source-id: aedb96d49277836000c0adc53007c97db6363253
Summary:
This PR will:
- add missing documentation for `caretHidden` prop to the docs
- add `caretHidden` prop implementation for Android
I noticed this by accident when looking at `RCTTextFieldManager.m` and there is `RCT_EXPORT_VIEW_PROPERTY(caretHidden, BOOL)` which hides caret on iOS. Then I realised that the docs were missing for this prop and implementation on Android side :)
Render `TextInput` with prop `caretHidden`. After this caret is not visible anymore.
`<TextInput style={styles.input} caretHidden />`
If you omit the prop then caret is visible again
`<TextInput style={styles.input} />`
Closes https://github.com/facebook/react-native/pull/11863
Differential Revision: D4448402
fbshipit-source-id: 456e1df3e2cbb8af32540d2c7a8f4e7da219f5c3
Summary:
This matches the behavior on iOS, there was no way before to change the cursor color per input, it was only possible to change it globally via the theme. Ideally cursor color and selection color would be 2 different props but I think this is better than what we have (and matches iOS).
Sadly there is no api to change it pragmatically (only possible via xml) so this uses reflection and can easily break so it is wrapped in a try catch to avoid crashes. I think it is better to just silently fail in this case. Definetly not super happy about the solution but I think it's worth adding since it is possible to do it natively using xml so it would suck not to be able to do it in RN.
**Test plan**
Tested that the cursor has the same color as before the change when not setting the prop and that it gets the selectionColor color when set.
Closes https://github.com/facebook/react-native/pull/12280
Differential Revision: D4571858
Pulled By: astreet
fbshipit-source-id: 7dca2db33a0a4eecb6115b45155549b1265ffbed
Summary:
Corresponding iOS PR: https://github.com/facebook/react-native/pull/11002
This adds an onScroll event to TextInput which is useful when a multiline TextInput has so much content that it is scrollable.
**Test plan (required)**
Verified the event works properly in a test app. Also, my team uses this event in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11001
Differential Revision: D4220941
Pulled By: mkonicek
fbshipit-source-id: 7e420579946f2ae840c9e1fcdc8afab68007da17
Summary:
To update the documentation. Works on iOS, so I assume this is the same on Android.
Closes https://github.com/facebook/react-native/pull/11575
Differential Revision: D4494464
Pulled By: mkonicek
fbshipit-source-id: c7480d39ed0849401efaa080948c14fa0cb7a08d
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
I had tried fixing a broken link in a previous commit (#11453). My commit was merged, but it did not resolve the underlying problem. I have looked into how links should be formed for the docs and have fixed the original problem as well as updated all other links to be consistent.
Previous link formats:
- /docs/sample.html <-- broken link
- sample.html <-- broken link
- https://facebook.github.io/react-native/docs/sample.html <-- works
- /react-native/docs/sample.html <-- works
- docs/sample.html <-- works (permalink format)
This PR updates all links to the permalink format.
**Test plan (required)**
I ran the website locally and manually tested half of the links in each category. They all worked.
```
$ cd website
$ npm install && npm start
```
Closes https://github.com/facebook/react-native/pull/12064
Differential Revision: D4489153
Pulled By: mkonicek
fbshipit-source-id: bf0231d941ba147317595c3b3466dc579a887169
Summary:
Bandaid for #7070. Until this is fixed, the docs should at least be honest the state they're in, so people don't have to go search and wonder.
Closes https://github.com/facebook/react-native/pull/11626
Differential Revision: D4366925
Pulled By: mkonicek
fbshipit-source-id: 082a8a9916ad0f8fbb2955cffbf61142fa2a98a1
Summary:
Android has a text API called breakStrategy for controlling how paragraphs are broken up into lines. For example, some modes support automatically hyphenating words so a word can be split across lines while others do not.
One source of complexity is that Android provides different defaults for `breakStrategy` for `TextView` vs `EditText`. `TextView`'s default is `BREAK_STRATEGY_HIGH_QUALITY` while `EditText`'s default is `BREAK_STRATEGY_SIMPLE`.
In addition to exposing `textBreakStrategy`, this change also fixes a couple of rendering glitches with `Text` and `TextInput`. `TextView` and `EditText` have different default values for `breakStrategy` and `hyphenationFrequency` than `StaticLayout`. Consequently, we were using different parameters for measuring and rendering. Whenever measuring and rendering parameters are inconsistent, it can result in visual glitches such as the text taking up too much space or being clipped.
This change fixes these inconsistencies by setting `breakStrategy` and `hyphenat
Closes https://github.com/facebook/react-native/pull/11007
Differential Revision: D4227495
Pulled By: lacker
fbshipit-source-id: c2d96bd0ddc7bd315fda016fb4f1b5108a2e35cf
Summary:
This exposes iOS's spellCheckingType functionality to JavaScript. The native functionality is a three state enum. It gets exposed to JavaScript as a boolean. The initial value and JS null map to the third state.
An alternative design for this API would have been to expose a three state enum to JavaScript:
- "on" which maps to UITextSpellCheckingTypeYes
- "off" which maps to UITextSpellCheckingTypeNo
- "auto" (default) which maps to UITextSpellCheckingTypeDefault
For consistency, I decided to use the same API design as spellCheck. We don't have many options for fixing spellCheck in #11055 without introducing a breaking change.
**Test plan (required)**
Verified that switching `spellCheck` between `true`, `false`, and `null` all work correctly in single line and multiline `TextInputs`.
Closes https://github.com/facebook/react-native/pull/11056
Differential Revision: D4232802
Pulled By: javache
fbshipit-source-id: 79e03307fa6a30a169f7e2fd0ec5ac826663e7c1
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
Corresponding Android PR: https://github.com/facebook/react-native/pull/11001
This adds an onScroll event to TextInput which is useful when a multiline TextInput has so much content that it is scrollable.
**Test plan (required)**
Verified the event works properly in a test app. Also, my team uses this event in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11002
Differential Revision: D4203565
Pulled By: ericvicenti
fbshipit-source-id: 7cb5e10325c3b03c6b395cce0f1bacb0528db40a
Summary:
To my mind this feature should be documented as here lots of issues can happen potentially.
Closes https://github.com/facebook/react-native/pull/10706
Differential Revision: D4119506
fbshipit-source-id: 54f9738ea2308144a05678fd1897f529f260966c
Summary:
Android PR for TextInput selection, based on the iOS implementation in #8958.
** Test plan **
Tested using the text selection example in UIExplorer.
Closes https://github.com/facebook/react-native/pull/8962
Differential Revision: D3819285
Pulled By: andreicoman11
fbshipit-source-id: 9a2408af2a8b694258c88ab5c46322830c71452a
Summary:
One of the potential fixes that grabbou suggested was to make _getText return an empty string in the worst case of null value and null defaultValue.
Closes https://github.com/facebook/react-native/pull/9553
Differential Revision: D3800913
fbshipit-source-id: 30d9c0a7384d39477a71947714eec3340ba5380f
Summary:
This adds support for a controlled `selection` prop on `TextInput` on iOS (Android PR coming soon). This is based on the work by ehd in #2668 which hasn't been updated for a while, kept the original commit and worked on fixing what was missing based on the feedback in the original PR.
What I changed is:
- Make the prop properly controlled by JS
- Add a RCTTextSelection class to map the JS object into and the corresponding RCTConvert category
- Make sure the selection change event is properly triggered when the input is focused
- Cleanup setSelection
- Changed TextInput to use function refs to appease the linter
** Test plan **
Tested using the TextInput selection example in UIExplorer on iOS.
Also tested that it doesn't break Android.
Closes https://github.com/facebook/react-native/pull/8958
Differential Revision: D3771229
Pulled By: javache
fbshipit-source-id: b8ede46b97fb3faf3061bb2dac102160c4b20ce7
Summary:
Currently, text inputs do not scroll when inside other components like scroll
views. This fixes it by blocking any parent native component from taking the
responder when the text input is focused and is being scrolled. This fixes the
previous implementation, where the scroll view was not able to scroll on top of
other text inputs, even though they were not focused.
This makes the component similar to it's ios counterpart.
Reviewed By: foghina
Differential Revision: D3735237
fbshipit-source-id: 724f94a6e7332d03261a80f63ffa60d0e5846932
Summary:
Currently, text inputs do not scroll when inside other components like scroll
views. This fixes it by blocking any parent native component from taking the
responder when the text input is focused and is being scrolled. This fixes the
previous implementation, where the scroll view was not able to scroll on top of
other text inputs, even though they were not focused.
This makes the component similar to it's ios counterpart.
Reviewed By: foghina
Differential Revision: D3735237
fbshipit-source-id: 0e56b2bbd3f5636540b4c3cc7cc13aa0f4d2737e
Avik Chaudhuri
ashoat
Eduard Rastoropov
Marcin Dobosz
Peter Ruibal
Gustavo Gard
Adam Comella
James Isaac
Marshall Roch
Syed Haani Hasan
Caleb Meredith
Tomas Reimers
Andrew Y. Chen
Summer Kitahara
Seth Fitzsimmons
Justin Stanley
Valentin Shergin
Adam Perry
Brian Vaughn
Bin Yue
Jeff Morrison
Henrik Raitasola
Janic Duplessis
Naman Goel
Michal Srb
Paul Mestemaker
Alex Kotliarskyi
David Aurelio
aybb
Tim Yung
m3vaz
Andrei Coman
