Repository navigation
Conversation
There was a problem hiding this comment.
Code Review
This pull request effectively unifies text direction handling in InputDecorator, TextField, and TextFormField by introducing a new textDirection property on InputDecoration. This change correctly deprecates the old hintTextDirection property, promoting consistency for labelText and hintText directionality. The implementation is solid, well-supported by new tests, and includes a data-driven fix for migration. My review includes one suggestion to improve code clarity and performance.
872502b to
720fd08
Compare
720fd08 to
20ac14b
Compare
Renzo-Olivares
left a comment
There was a problem hiding this comment.
Hi @Mairramer, thank you for the contribution! I definitely agree we should try to make textDirection consistent across text field's components like input decorator. I left a small comment but the change and approach looks good to me overall.
f135465 to
c4a6c1c
Compare
| strutStyle: widget.strutStyle, | ||
| textAlign: widget.textAlign, | ||
| textDirection: widget.textDirection, | ||
| textDirection: widget.decoration?.textDirection ?? widget.textDirection, |
There was a problem hiding this comment.
This feels like it might be a breaking change if someone had has TextField.textDirection and TextField.hintTextDirection as different and then they migrate away from hintTextDirection. Previously the text field and input decorator could have a different text direction but after this change they cannot. I don't think this is a blocker since I think unifying the handling here is the right decision but definitely something to keep an eye out for.
Renzo-Olivares
left a comment
There was a problem hiding this comment.
LGTM, thank you for the contribution @Mairramer!
c4a6c1c to
5d50f75
Compare
|
There are some valid google testing failures I need to investigate further. |
|
@mdebbar Do you have any thoughts on whether a user might want to define different text directions for labels within the same component, i.e. InputDecorator in this case. |
|
@mdebbar pointed out that in cases like phone numbers which should always follow LTR, it may be expected for the I think we should probably keep the existing We should keep the If we did want to continue this unification, the migration for existing users setting their TextField.textDirection explicitly but expecting their input decoration to use a different text direction would be for them to explicitly set their InputDecoration.textDirection. If we did not want to continue with the unification but still enable users to change the text direction of their label or entire input decoration, then a Generally it does make sense to me that setting I'm leaning towards not breaking existing users since their apps rely on this existing behavior. The addition of One open question is If we introduce Other note: In the original issue, a workaround the user could have used is wrap their subtree with a |
Renzo-Olivares
left a comment
There was a problem hiding this comment.
Mostly LGTM just had a small comment regarding the test. Thank you for the changes @Mairramer!
| decoration: InputDecoration( | ||
| hintText: hintText, | ||
| labelText: labelText, | ||
| labelTextDirection: TextDirection.rtl, |
There was a problem hiding this comment.
I think this test should either explicitly wrap with a Directionality widget set to ltr or leave a comment regarding it being the default. Then labelTextDirection and hintTextDirection should both be set to rtl to make it clear between the default ltr direction set by Directionality and the explicit rtl direction set by the InputDecoration.
loic-sharma
left a comment
There was a problem hiding this comment.
Thanks for the excellent contribution!
|
Thanks for your contribution! This PR has reached completion, although we will not land this PR for now due to the material/cupertino code freeze (#184093). As soon as the decoupling is complete, we will post a way to migrate this PR to the new packages. |
|
In the meantime, I'll convert this PR to a draft and apply a label so that we can quickly find it when the freeze is lifted. |
mdebbar
left a comment
There was a problem hiding this comment.
FYI: this PR looks good to me. Thanks for the contribution!
|
I've marked this PR as not ready to port to flutter/packages yet. |
|
This pull request contains changes to Material or Cupertino, which are currently frozen in this repository. Changes should be made in Please refer to #188444 for instructions. |
|
Ported to flutter/packages#12607. |
This PR introduces `labelTextDirection` property to InputDecoration. Closes flutter/flutter#41324 Port of flutter/flutter#182477 ## Pre-Review Checklist **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. [^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
This PR introduces
labelTextDirectionproperty to InputDecoration.Fixes #41324
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.