-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[iOS][TextInput]Add numberOfLines and maxNumberOfLines props to TextInput on iOS #38021
[iOS][TextInput]Add numberOfLines and maxNumberOfLines props to TextInput on iOS #38021
Conversation
Co-authored-by: Janic Duplessis <janicduplessis@gmail.com>
…acebook#37609) Summary: Pull Request resolved: facebook#37609 changelog: [internal] Moving LayoutMetrics and LayoutPrimitives from core to graphics module. This is to enable different implementation for different platforms. Reviewed By: rubennorte Differential Revision: D45904748 fbshipit-source-id: a4e666d7c7390e87abdb09235f96655b63f451f9
…o graphics folder Differential Revision: D45904748 Original commit changeset: a4e666d7c739 Original Phabricator Diff: D45904748 fbshipit-source-id: c2da28836cb51966854c81d4e380a2abeb742cda
Summary: Chronos Job Instance ID: 1125907889493757 Sandcastle Job Instance ID: 36028797978627335 allow-large-files ignore-conflict-markers opt-out-review Differential Revision: D46270525 fbshipit-source-id: 26beec108aa03c970338fdc4561af24798813acf
Summary: Pull Request resolved: facebook#37572 Currently, RNTester was using a completely custom AppDelegate and not leveraging the RCTAppDelegate we use in the OSS. This resulted in a misalignment between the two setups and duplicated work to test stuff internally furst and then in the OSS, with some more time needed to understand why one setup was working and the other wasn't. With this change, we are aligning the two, bringing RNTester closer to the OSS setup. There are still small differences, but we can iterate over those. ## Changelog: [iOS][Changed] - Make RNTester use RCTAppDelegate Reviewed By: cortinico Differential Revision: D46182888 fbshipit-source-id: 7c55b06de1a317b1f2d4ad0d18a390dc4d3356a4
Summary: Pull Request resolved: facebook#37596 This commit is a backport of this [commit](facebook@32327cc) so that we build the right version of hermes in CI. This also bumps the hermes keys to make sure that we are building it properly from now on. ## Changelog: [Internal] - Fix Hermes versioning and bump hermes workspace keys Reviewed By: cortinico Differential Revision: D46225179 fbshipit-source-id: f00c9d20d37f3bd5689e0742063f98e3bfe373c2
Summary: Pull Request resolved: facebook#37614 changelog: [internal] We do not control what `vImageBoxConvolve_ARGB8888` returns, it may return 0. If it does return 0, we will allocate memory chunk of size 0. Yes, malloc will let you do that. Well, it depends on the implementation, but according to the spec it is legal. The only requirement is to by able to call free on that without crash. If `vImageBoxConvolve_ARGB8888` does return 0 and we allocate memory of size 0. Call to `vImageBoxConvolve_ARGB8888` with tempBuffer of size 0 will lead to a crash. [The documentation](https://developer.apple.com/documentation/accelerate/1515945-vimageboxconvolve_argb8888#discussion) for `vImageBoxConvolve_ARGB8888` and tempBuffer states: > To determine the minimum size for the temporary buffer, the first time you call this function pass the kvImageGetTempBufferSize flag. Pass the same values for all other parameters that you intend to use in for the second call. The function returns the required minimum size, which **should be a positive value**. (A negative returned value indicates an error.) The kvImageGetTempBufferSize flag prevents the function from performing any processing other than to determine the minimum buffer size. I think the keyword word there is "should be a positive value". 0 is not a positive value. Reviewed By: javache, yungsters Differential Revision: D46263204 fbshipit-source-id: baa8fac5b3be6fb5bed02800cd725cc4cf43485a
…targets (facebook#37581) Summary: In Xcode projects with multiple targets, and in particular when targets are for different platforms (e.g. iOS and macOS), Cocoapods may add a suffix to a Pod name like `React-Core`. When this happens, the code in `new_architecture.rb` (which was looking for a pod with exact name `React-Core`) would not add the preprocessor definitions for Fabric as expected. This change fixes this issue. Fixes facebook#37102 . ## Changelog: [iOS] [Fixed] - Fix Fabric issue with React-Core pod when Xcode project has multiple targets Pull Request resolved: facebook#37581 Test Plan: Tested that this change fixes this issue which occurs 100% of the time in React Native TV projects. Reviewed By: dmytrorykun Differential Revision: D46264704 Pulled By: cipolleschi fbshipit-source-id: 8dfc8e342b5a110ef1f028636e01e5c5f2b6e2f0
Summary: This (`greet.yml`) action requires some _changes_ to "repo" settings which are _out of maintainers' controls_. So, instead of wasting compute; let's just delete this action :( 🤗🌏 ## Changelog: [GENERAL] [REMOVED] - [Actions] Remove `greet.yml` action Pull Request resolved: facebook#37587 Test Plan: - Not needed. Reviewed By: cortinico Differential Revision: D46275607 Pulled By: cipolleschi fbshipit-source-id: 80880568cbae1158006445e078e638e4e375cb73
Summary: Pull Request resolved: facebook#37616 Add tests in CircleCI to avoid that changes in Hermes can break the Xcode integration. ## Changelog: [Internal] - Add CI tests to avoid to break the Hermes-Xcode integration Reviewed By: cortinico Differential Revision: D46265656 fbshipit-source-id: 176f1a33fe6944a68fb14b62e5c626fe30d296cc
Summary: Pull Request resolved: facebook#37410 Incremental adoption of new bridgeless API's, where they are semantically equivalent to the old one. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D45736529 fbshipit-source-id: e41f6840e7c329f6051530e53773fae760584842
Base commit: f9a63ec |
@sammy-SC @NickGerleman I just fixed CI Tests. Sorry for not noticing it earlier. |
@NickGerleman @sammy-SC I know you have plenty of work and this pr may seems to be a bit complex at first but would really appreciate if you could take a look :) |
@sammy-SC I just merged recent changes on Main so there is no merge conflicts. I also added descriptions the pr so that you don't need to read original pr. Please, let me know what you thing/how I can help. :) |
I'm sorry, but what is the final goal here? By reading the comments it seems like that you'd like to add the Maximum Number of Rows so that you can add some padding at the beginning for layout purposes. If that's the case, I don't think that this is the right solution for your problem. We shouldn't introduce additional props and logic in the the semantic of a component (handling text) to get a final result on a different layer (layouting) |
@cipolleschi It's a pr that adds numberOfLines prop on iOS. Android and web already have that prop :) |
Additionally, I'm adding a prop that let people set maximum height expressed in lines |
The problem is here. That's why I was asking what's the problem you are trying to solve. If we know that, we can guide you to the right solution. |
The goal is to add numberOfLines support to TextInput component on iOS. On Android and Web we can set exact height in lines using exactly this prop. On iOS it's not possible. On Android the native "TextArea" like component (EditText) exposes setLines method that sets height of the component in lines. However, I wasn't able to find anything similar on iOS. What is a common method for both platforms is setting maximum height in lines. On iOS we can set .maximumNumberOfLines property on TextContainer and similarly on Android we can call setMaxLines() method to limit number of lines. So Adding maximumNumberOfLines is not a problem. I realised that when we add enough number of newLines in order to implement numberOfLines prop using maximumNumberOfLines functionality and did exactly that. Probably it's possible to get a font size and based on that set exact height but I didn't want to miss any edge cases and adding few newlines doesn't seem to be an overhead at all. |
@cipolleschi Those lines are only added on layout stage and are not visible on the screen. |
https://reactnative.dev/docs/textinput#numberoflines-android That's the prop that I implemented on iOS in this pr |
I understand, but why do you need the same behavior? The two platforms behaves differently natively and that's the strength of React Native. On top of that, the I think that this change arrives because of some product need, where there is a text field that needs a certain height to accomodate some user input, right? Why can't the product change the layout code (with flexlayout) so that it occupies a portion of the screen that it's roughly the amount of space you need? |
|
#35703 <- here is there previous pr that I just split as @NickGerleman asked me to do it. |
Can you explain how the pr can break internal tests? It only has impact on dimensions returned by yoga and then on frame size on UIViews. |
Because we have screenshot tests: we have a reference file that states the expected result. We run the test and we generate a screenshot of the state of the app after the change. We compare the expected result with the actual result and if they differ, it is a failure. Imagine that we have a JS file used both by iOS and Android, which sets the We are not the only company having screenshot tests and this change will also mess up with the design of apps which were designed considering a single line for iOS. |
I just created a RFC discussion on this here. Could everyone who's involved in this change give it a look? :) @Noitidart i think you were interested in this feature too |
Yes absolutely still interested will take a look thank you. |
This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This PR was closed because it has been stalled for 7 days with no activity. |
This pull-request adds
rows
,numberOfLines
props to TextInput component on iOS so that it we can use it on all platforms. Additionally, the addsmaxNumberOfLines
prop that lets people express maximumHeight in lines (which is useful due to multithreaded react native architecture that can cause some delays caused by scheduling)The main idea in this pr is to make use of
maximumNumberOfLines
property onNSTextContainer
. As we don't have any native support for setting exact height expressed in lines I came up with the idea that we can add some lines of text at the layout stage what will let us implementnumberOfLines
usingmaximumNumberOfLines
. The lines are not added in component that are actually displaying text so that it's not visible on the screen but is using on layout layer soShadowNodes
andTextLayoutManagers
. Later similar idea was implemented on Android here( #35703) but I split the implementation to simplify the review.So you can review this pr without a need to get familiar with original pr.
Summary:
Changelog:
[iOS] [Added] - Added support for numberOfLines/rows to TextInput on iOS platform (Fabric and Paper)
[iOS] [Added] - Added MaxNumberOfLines prop to the same component that sets upper bound instead of exact value
Test Plan:
I added few Texts to RN tester