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:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
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: When pasting text longer than maxlenght, the textDidChange: call we did would end calling back into textView:shouldChange: because we saw an unexpected multi-character change. Since this is an expected mutation, update predictedText appropriately.
Reviewed By: majak
Differential Revision: D3561524
fbshipit-source-id: 07bb78d830ccfa3aed6ee274dc30adeadce9e1f8
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:
Submitting PR for adding textAlignment to the placeholder of textView so that it matches the alignment of the actual value text
Closes https://github.com/facebook/react-native/pull/7429
Differential Revision: D3422007
fbshipit-source-id: e255c2d86dbaa0e197328a56ec81cbab2735c53d
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
RCTShadowText currently explicitly defaults to black text color:
https://github.com/facebook/react-native/blob/d46ac11/Libraries/Text/RCTShadowText.m#L204
However, the UITextView used by RCTTextInput doesn't explicitly default to black text color.
This causes issues when RCTTextInput is in rich text editing mode (i.e. when the <TextInput> element uses child <Text> nodes to provide extra styling info) and the client doesn't provide us with any explicit color info. In this case, the following series of badness occurs:
1. -[UITextView attributedText] will return an attributed string without the NSColor property set.
2. -[RCTShadowText attributedString] will return an attributed string with NSColor equal to blackColor.
3. The `[_textView.attributedText isEqualToAttributedString:_pendingAttributedText]` check in -performPendingTextUpdate will fail and causes -[UITextView setText:] to be called.
4. -setText: clears the marked text range in the text view, which breaks multi-character autocomplete (e.g. QWERTY input methods for CJK languages).
The easiest fix for now is to just make sure RCTUITextView and RCTShadowText default to the same text color.
Reviewed By: nicklockwood
Differential Revision: D3368726
fbshipit-source-id: a92cb188c60bac80d963af6b1f2a09f27ae084f5
Summary:
The TextInput when configured with `multiline=true` has a minor issue due to which if the initial text doesn't fit in one line, the input won't span multiple lines. The root cause of the problem is that the `onChange` event is not fired for the initial render. This issue has been reported on open-source: 481f560f64
This is an attempt to fix this problem by moving the logic to fire the event to the method that updates the content size. This way we can guarantee that anytime the content size changes we'll trigger the JS event.
The downside of this approach is that it's possible that multiple events get fired for a single character change. As per the comment that was removed, this was already happening when adding a character that when rendered, would increase the content size. By moving the code to the new place, this can happen more often (twice per character tapped). Let me know if you think this is an issue.
I don't know this code much, so please be careful reviewing. I'm happy to add more test cases I may have missed to the test plan :).
Reviewed By: nicklockwood
Differential Revision: D3348218
fbshipit-source-id: 6b457624c9126e771c326eac61cd1cdd6496671d
Summary:
The TextInput when configured with `multiline=true` has a minor issue due to which if the initial text doesn't fit in one line, the input won't span multiple lines. The root cause of the problem is that the `onChange` event is not fired for the initial render. This issue has been reported on open-source: 481f560f64
This is an attempt to fix this problem by moving the logic to fire the event to the method that updates the content size. This way we can guarantee that anytime the content size changes we'll trigger the JS event.
The downside of this approach is that it's possible that multiple events get fired for a single character change. As per the comment that was removed, this was already happening when adding a character that when rendered, would increase the content size. By moving the code to the new place, this can happen more often (twice per character tapped). Let me know if you think this is an issue.
I don't know this code much, so please be careful reviewing. I'm happy to add more test cases I may have missed to the test plan :).
Reviewed By: nicklockwood
Differential Revision: D3348218
fbshipit-source-id: d3da3c0da1a0da9b9960625441191497e91d322e
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:This fixes autocomplete for CJK text input by making sure that the `<Text>` nodes that JS controls to produce attributed text matches the text view's attributed text as much as possible. This is done by giving the disconnected `<Text>` child the same style as the `<TextInput>` parent.
This works because `-[RKTextView performPendingTextUpdate]` avoids setting the attributedText property on textView if the JS attributedText and textView attributedText are equal. This is important because setting attributedText on a text view clears the autocomplete state (markedText property) on a text view, breaking autocomplete for multistage input styles like CJK with a phonetic keyboard.
Reviewed By: nicklockwood
Differential Revision: D3207513
fb-gh-sync-id: 02e582ea5f15191974f15a65ebc1820401715f8d
fbshipit-source-id: 02e582ea5f15191974f15a65ebc1820401715f8d
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:
public
This diff adds support for auto-resizing multiline text fields. This has been a long-requested feature, with several native solutions having been proposed (see https://github.com/facebook/react-native/pull/1229 and D2846915).
Rather than making this a feature of the native component, this diff simply exposes some extra information in the `onChange` event that makes it easy to implement this in pure JS code. I think this is preferable, since it's simpler, works cross-platform, and avoids any controversy about what the API should look like, or how the props should be named. It also makes it easier to implement custom min/max-height logic.
Reviewed By: sahrens
Differential Revision: D2849889
fb-gh-sync-id: d9ddf4ba4037d388dac0558aa467d958300aa691
Summary:
This is useful for applying input masks in the onChange handler that you then need to propagate down to the native component. In our case, we add commas as the user enters a price. Without this change, the cursor will end up in the wrong place when the text is transformed in our onChange handler.
Closes https://github.com/facebook/react-native/pull/4716
Reviewed By: svcscm
Differential Revision: D2766236
Pulled By: nicklockwood
fb-gh-sync-id: c4057d77d62507ec9e09eb0242888bf2858d822f
Summary:
public
The scrolling fix I added to RCTTextView doesn't work on iOS 8 because the underlying UITextField doesn't resize correctly, which breaks text input functionality. This diff fixes it.
Reviewed By: tadeuzagallo
Differential Revision: D2712618
fb-gh-sync-id: 1d0282df3a16f1cb6ddf9d005d640738bb1b5659
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
Fixed some Xcode warnings, and added some missing UIResponder methods to make the behavior of RCTTextView more self-consistent.
Reviewed By: javache
Differential Revision: D2712250
fb-gh-sync-id: d30038500194d7a5262d9e77d516c65d836a4420
Summary: public
onFocus and onBlur were not firing for multiline TextInputs.
Reviewed By: tadeuzagallo
Differential Revision: D2699846
fb-gh-sync-id: 7e64309bc631a42a99f989f615fef927dc50217c
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: public
It is now possible to display and edit rich text inside a multiline `<textInput>` by nesting a `<Text>` node inside it.
Note that this doesn't yet provide everything needed to build a full rich text editor (as there is no facility to capture or control the selected text range, or insert/remove text) but it does make it possible to apply token-based styling to text as the user types.
See the 'Attributed text' example in the UIExplorer > TextInput demo for details.
Reviewed By: javache
Differential Revision: D2622493
fb-gh-sync-id: b6bc9a46005322c806934541966460edccb59e70
Summary:
Now that UITextViews have a delegate, they consume the "tap to scroll to top" gesture. This diff restores the original behavior of letting the top-level scroll view (if any) scroll to top instead.
I tried exposing scrollsToTop as a prop and was semi-successful in that I could turn scroll-to-top on and off for the top-level scroll view scroll, but the text view itself would never scroll to top. So instead of exposing it as a prop, this diff sets scrollsToTop always to NO, which is how TextInput behaved previously.
Closes https://github.com/facebook/react-native/pull/2333
Github Author: James Ide <ide@jameside.com>
Summary:
With a multiline TextInput, the text is initially rendered correctly but once you try to edit it, the cursor slides off the top of the view and out of its bounds. Also if the TextInput is scrollable, you can scroll the text out of the bounds of the view, which looks buggy unless you clip the overflow. This occurs because the top content inset is applied to the RCTTextView instead of the UITextView's text container.
This diff fixes both bugs by applying the vertical insets to the UITextView's textContainerInset instead of the RCTTextView's frame (which is a wrapper around a real UITextView).
The left inset is still applied to the frame because there is a bug with the text rendering when the left textContainerInset is negative: the initial text doesn't show up until you focus the text view. The bug doesn't occur when setting the right textContainerInset, so I apply this workaround to only the left inset.
Closes https://github.com/facebook/react-native/pull/2297
Github Author: James Ide <ide@jameside.com>
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
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:
Get the system font instead of Helvetica programmatically and add a virtual fontName called "System" that defaults to whatever the current system font is.
#1611
Closes https://github.com/facebook/react-native/pull/1635
Github Author: LYK <dalinaum@gmail.com>
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
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
Adam Comella
Pieter De Baets
Douglas Lowder
Janic Duplessis
Dave
Nick Lockwood
Ben Nham
Nathan Azaria
Martín Bigio
Nick
Ben
Andrew Crowell
Dave Sibiski
Kushal Dave
James Ide
Spencer Ahrens
LYK
Brent Vatne
