Repository navigation
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
There was a problem hiding this comment.
Code Review
This pull request introduces a new errorPadding property to InputDecoration and its related theme classes. This allows for specifying custom padding for the error text in text fields. The property has been plumbed through InputDecoration, InputDecorationTheme, and InputDecorationThemeData.
My review has identified a critical issue where the new errorPadding property is incorrectly wired to use the contentPadding value. I've also pointed out a couple of places where documentation for the new public properties is missing, which is a violation of the repository's style guide.
|
|
||
| final _Decorator decorator = _Decorator( | ||
| decoration: _Decoration( | ||
| errorPadding: decorationContentPadding, |
There was a problem hiding this comment.
The errorPadding is being incorrectly initialized with decorationContentPadding, which is derived from decoration.contentPadding. This is likely a copy-paste error. Since the errorPadding feature is not fully implemented yet (as per the TODOs), it would be safer to initialize this to null for now. When the feature is implemented, this should be changed to resolve decoration.errorPadding.
errorPadding: null,| // TODO(abikko): add documentation after implementing error padding in text field | ||
| final EdgeInsetsGeometry? errorPadding; |
There was a problem hiding this comment.
This public property should have a documentation comment explaining its purpose.1
/// Overrides the default value for [InputDecoration.errorPadding].
// TODO(abikko): add documentation after implementing error padding in text field
final EdgeInsetsGeometry? errorPadding;Style Guide References
Footnotes
-
All public members should have documentation. ↩
|
@tirth-patel-nc Hi! Who will review this PR? |
justinmc
left a comment
There was a problem hiding this comment.
Thanks for jumping on fixing this. I agree with the need for an errorPadding property like this, but I think the implementation should be in _layout (see my comment below).
There was a problem hiding this comment.
It's probably not strictly necessary to include an example for a straightforward change like this. However, if you want to include it as a dartpad example in the errorPadding docs to show people how to solve the problem from the issue, that's probably worth it.
If you do keep this example, you'll have to add a test for it too.
There was a problem hiding this comment.
I think that in new release, I have to clearly explain how that ErrorPadding works! :)
There was a problem hiding this comment.
Thanks for review, I appreciate that!
Tomorrow I will try to implement your suggestions, and write some tests and documentation
| final Color fillColor; | ||
| final Color hoverColor; | ||
| final bool isHovering; | ||
| final EdgeInsetsGeometry? contentPadding; |
There was a problem hiding this comment.
I am assuming that we will use it _EditableText RenderBox, for calculating the padding in _Decorator
| static BoxParentData _boxParentData(RenderBox box) => box.parentData! as BoxParentData; | ||
|
|
||
| EdgeInsetsDirectional get contentPadding => decoration.contentPadding; | ||
| EdgeInsetsDirectional get contentPadding => decoration.errorPadding ?? decoration.contentPadding; |
There was a problem hiding this comment.
Won't this also affect the position of the content?
There was a problem hiding this comment.
There is a problem that _EditableText is "surrounded" by size of _Decorator which extends RenderBox
And we have to use errorPadding(assuming that contentPadding will be more than ErrorPadding)
| /// and `EdgeInsets.fromLTRB(12, 24, 12, 16)` when [isDense] is false. | ||
| final EdgeInsetsGeometry? contentPadding; | ||
|
|
||
| ///TODO(abikko): add documentation after implementing error padding in text field |
There was a problem hiding this comment.
Don't forget this. This is where I'd add your example.
| child: Padding( | ||
| padding: contentPadding, |
There was a problem hiding this comment.
I think you probably want to implement the padding in the layout method of InputDecorator, not here.
There was a problem hiding this comment.
Yes, today I was thinking about moving from here to implementing it to layout for RenderBox InputDecorator
thanks!
There was a problem hiding this comment.
@abikko Do you still intend to come back to this PR and move this to the _layout method instead of a Padding widget?
TextField
|
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
I'm a bit concerned about the scope of this change Exposing This same layout coupling has effect on "helper", "helperText" in Formfield's decoration I've not really had time to look into the implementation details myself, but from a API design pov, this feels like a styling level fix for what is really a structual concern I feel if there is a need for padding control for errors, i want to believe it's very likely needed consistently across other supporting widgets exposed by Maybe elevating the padding control to FormField itself might be better in this case, or just exposing a unifield field like |
justinmc
left a comment
There was a problem hiding this comment.
@danielkiing3 Thanks for chiming in here. When you say FormField I guess you mean TextFormField? I think you're right that any API we add here should probably affect both error and helper (which are positioned in the same place today).
| child: Padding( | ||
| padding: contentPadding, |
There was a problem hiding this comment.
@abikko Do you still intend to come back to this PR and move this to the _layout method instead of a Padding widget?
|
@abikko Thanks for your contribution! Since I haven't seen a reply, I'm going to reluctantly close this pull request for now, but if you get time to address the comments, we'd be more than happy to take a look at a new patch. If you do send a new patch, it would be very useful to reference this one in the description in order to help reviewers see the previous context. |
This PR closes: #175834
Added errorPadding property,
Currently it's not ready yet.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
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.