Summary:
This diff unifies `selection` prop between single line and multi line text inputs.
Besides that, this diff improves the selection event handling, makes it more robust and predictable.
(See inline comments.)
Reviewed By: mmmulani
Differential Revision: D5317652
fbshipit-source-id: db5b0d2c0b80268e479ba866980e14b444079386
Summary: The implementation of `clearTextOnFocus` was unified and moved to baseclass.
Reviewed By: javache
Differential Revision: D5299489
fbshipit-source-id: ff166f9bb0673ff8766f20b677f56810f64d7b2d
Summary: The implementation of `clearsOnBeginEditing` was unified and moved to superclass.
Reviewed By: javache
Differential Revision: D5299396
fbshipit-source-id: 98c5494a782cbe4df5b2d6021828eb7b2012f6dc
Summary:
Now the business logic of `blurOnSubmit` is pretty simple and lives inside `RCTTextInput`,
whereas UIKit hacks/workarounds lives inside `RCTBackedTextInputDelegateAdapter`.
Reviewed By: javache
Differential Revision: D5299397
fbshipit-source-id: 6a9d4194324ff9446c74fdb32ad5357e849e471d
Summary: This method was identical between two subclasses, so it was moved to baseclass.
Reviewed By: javache
Differential Revision: D5297401
fbshipit-source-id: 8f56bef33f9ab0184f69da76177b5e8da10d7514
Summary:
Nothing behavioral changed in this diff; just moving code around.
`RCTBackedTextInputDelegate` is the new protocol which supposed to be common determinator among of UITextFieldDelegate and UITextViewDelegate
(and bunch of events and notifications around UITextInput and UITextView).
We need this reach two goals in the future:
* Incapsulate UIKit imperfections related hack in dedicated protocol adapter. So, doing this we can fix more UIKit related bugs without touching real RN text handling logic. (Yes, we still have a bunch of bugs, which we cannot fix because it is undoable with the current architecture. This diff does NOT fix anything though.)
* We can unify logic in RCTTextField and RCTTextView (even more!), moving it to a superclass. If we do so, we can fix another bunch of bugs related to RN imperfections. And have singleline/multiline inputs implementations even more consistent.
Reviewed By: mmmulani
Differential Revision: D5296041
fbshipit-source-id: 318fd850e946a3c34933002a6bde34a0a45a6293
Summary:
Nothing really changed except that there is no code duplication in this part anymore.
More unification is coming!
Reviewed By: mmmulani
Differential Revision: D5144435
fbshipit-source-id: 390f795be3228907b254f8656783232013c36abe
Summary: Some basic same to both classes functionality was moved to base class, and it is just a beginning.
Reviewed By: mmmulani
Differential Revision: D5144429
fbshipit-source-id: 56c6400d46f4cf3c0058fe936cba524dd5d490df
Summary: RCTBackedTextInputViewProtocol is supposed to unify interface of backed text inputs which will make them accessible from managers and wrapper views.
Reviewed By: mmmulani
Differential Revision: D5144428
fbshipit-source-id: 473e7364d4af2edcd87c5555200e1325c38a8214
Summary: Now padding, border and intinsic sizes are computed same way as for singlelined text input.
Reviewed By: mmmulani
Differential Revision: D5075880
fbshipit-source-id: 1bc2fd479c13a003c717b1fc3d9c69f4639d4444
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:
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:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
There's an inconsistency in autoCorrect's default state:
- If you don't specify a value for autoCorrect, it defaults to on.
- If you specify true/false for autoCorrect and later specify null, autoCorrect turns off. It should have reverted to its initial state of on.
The reason for this discrepancy is that autoCorrect is exposed to JS as a boolean but it is actually an enum with three states in native:
- UITextAutocorrectionTypeDefault (the default value)
- UITextAutocorrectionTypeYes
- UITextAutocorrectionTypeNo
This is fixed by explicitly mapping JS null to UITextAutocorrectionTypeDefault.
**Test plan (required)**
Verified that switching `autoCorrect` between `true`, `false`, and `null` all work correctly in single line and multiline `TextInputs`.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11055
Differential Revision: D4226419
Pulled By: javache
fbshipit-source-id: e3e5769a3aa537f00fb56ca4ae622ff4213481c5
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:
This adds proper support for tracking a TextInput content size as discussed in #6552 by adding a new callback that is called every time the content size changes including when first rendering the view.
Some points that are up for discussion are what do we want to do with the onChange callback as I don't see any use left for it now that we can track text change in onChangeText and size changes in onContentSizeChange. Also a bit off topic but should we consider renaming onChangeText to onTextChange to keep the naming more consistent (see [this naming justification](https://twitter.com/notbrent/status/709445076850597888)).
This is split in 2 commits for easier review, one for iOS and one for android.
The iOS implementation simply checks if the content size has changed everytime we update it and fire the callback, the only small issue was that the content size had several different values on initial render so I added a check to not fire events before the layoutSubviews where at this point the value is g
Closes https://github.com/facebook/react-native/pull/8457
Differential Revision: D3528202
Pulled By: dmmiller
fbshipit-source-id: fefe83f10cc5bfde1f5937c48c88b10408e58d9d
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
public
Setting `blurOnSubmit=true` on a multiline `<TextInput>` now causes it to behave like a single-line input with respect to the return key:
With the default value of `false`, pressing return will enter a newline character into the field. If you set the value to `true`, pressing return will now blur the field and trigger the onSubmitEditing event. The newline character will *not* be added to the text.
(See associated github task for dicussion: https://github.com/facebook/react-native/pull/2149)
Reviewed By: javache
Differential Revision: D2710448
fb-gh-sync-id: c9706ae11f8b399932d3400ceb4c7558e455570d
Summary: public
This diff fixes the jumpy scrolling for multiline `<TextInput>` when using nested `<Text>` components to implement rich text highlighting.
The fix is to disable scrolling on the underlying UITextView, and nest it inside another UIScrollView that we control.
Reviewed By: ericvicenti, tadeuzagallo
Differential Revision: D2674670
fb-gh-sync-id: bacee3ae485523cc26ca8102b714e081df230629
Summary: public
Open-sourced the onSelectionChange event for RCTTextView, and also added onSelectionChange support for RCTTextField.
Reviewed By: javache
Differential Revision: D2647541
fb-gh-sync-id: ab0ab37f5f087e708a199461ffc33231a47d2133
Summary:
This introduces event counts to make sure JS doesn't set out of date values on
native text inputs, which can cause dropped characters and can mess with
autocomplete, and obviates the need for the input buffering which added lag and
complexity to the component. Made sure to test simulated super-slow JS text
event processing to make sure characters aren't dropped, as well as typing
obviously correctable words and making sure autocomplete works as expected.
TextInput is now a controlled input by default without causing any issues for
most cases, so I removed the `controlled` prop.
Fixes selection state jumping by restoring it after setting new text values, so
highlighting the middle of some text in the new ReWrite example and hitting
space will replace that selection with an underscore and keep the cursor at a
sensible position as expected, instead of jumping to the end.
Ads `maxLength` prop to support the most commonly needed syncronous behavior:
preventing the user from typing too many characters. It can also be used to
prevent users from continuing to type after entering special characters by
changing it to the current length after a regex match. Made sure to verify it
works well with pasted input (including in the middle of existing text),
truncating it and collapsing the selection the same way it does on the web.
Fixes bug in TextEventsExample where it wouldn't show the submit and end events,
even though there were firing correctly.
Summary:
Some of the RCTTextView properties weren't set up correctly which would cause bugs when you'd set a property and then unset it, trying to revert to the default. This requires reading the default value from the dummy view instance, but some of these properties didn't have getters which was causing issues.
Fixes#1174
Closes https://github.com/facebook/react-native/pull/1175
Github Author: James Ide <ide@jameside.com>
Test Plan: Create a `<TextInput multiline={true}>` component. Give it a style with `color: 'blue'`, and then on the next render pass remove the style. No more red box.
Summary:
@nicklockwood - Could I get a review of this?
Just took `RCTTextField` and ported it from `UITextField` to `UITextView` as you mentioned in another discussion, and removed any `UITextField` specific attributes.
- How do you think this should behave when there are subviews?
- Do you know how we can respond to the `UIControlEventEditingDidEndOnExit` event to respond to submit? Because `UITextView` isn't a `UIControl` we can't just use `addTarget` with `UIControlEventEditingDidEndOnExit`.
- Any other feedback?
Still going to look over the `UITextView` docs in more detail and make sure we expose all important options, and add it to the UIExplorer example, just putting this out here for feedback.
Closes https://github.com/facebook/react-native/pull/991
Github Author: Brent Vatne <brent.vatne@madriska.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Valentin Shergin
Marc Horowitz
Adam Comella
Pieter De Baets
Janic Duplessis
Nick Lockwood
Spencer Ahrens
James Ide
Brent Vatne
