-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Closed as not planned
Closed as not planned
Copy link
Labels
r: invalidIssue is closed as not validIssue is closed as not valid
Description
Use case
Many widgets have a single child and enhance that child in some way. Extensions on Widget that define methods which wrap the receiver in another widget enable a style of Flutter code that requires much less nesting and is more readable to some.
Take this example of a widget tree written in the traditional Flutter style:
Center(
child: Padding(
padding: EdgeInsets.all(8),
child: Text('Hello World'),
),
);With the help of an extension on Widget, it can be rewritten like so:
Text('Hello World')
.padding(EdgeInsets.all(8))
.center();extension WidgetExtensions on Widget {
Widget center() => Center(child: this);
Widget padding(EdgeInsetsGeometry padding) =>
Padding(padding: padding, child: this);
}There are some downsides for this style (that I'm aware of):
- The factory methods in extensions cannot return
constwidgets, even if the receiver isconst.
I don't think this is a big problem, since more often than not the receiver cannot beconstin the first place.
It might be possible to introduce simplifiedconstextension methods in Dart, that only allow calling aconstconstructor. - Code in the described style does not mirror the element tree in the same way the more traditional style does.
- Recorded widget instance creation locations point to the bodies of extension methods, which is not useful to developers.
This issue is about the last point.
Proposal
I would like to have the ability to mark an extension method as a widget factory. Debug tools would use the call site of such methods when they need the location of a widget instance in the source code.
Metadata
Metadata
Assignees
Labels
r: invalidIssue is closed as not validIssue is closed as not valid