How it works: Highlight some widgets in a large widget build tree you'd like to start breaking down. Currently, you can easily extract these as a method in the current class using the "extract method" action. However, I often find myself creating a StatelessWidget out of this selection instead of a method and have to do that part manually. It would be very handy if you could "extract widget".
This would allow you to create a Stateless Widget, with a constructor and fields that match the necessary params. For example, if you extracted a piece of Code, and it required a Todo with the variable name todo, the StatelessWidget would extract a final Todo todo field and a Constructor to match. The build method would return the contents of your highlighted selection.
After creating the class, it would replace your current highlighted selection with the new MyTodoWidget(todo);
Essentially, this would just be a slightly different extraction than a method.
/cc @scheglov @bwilkerson
That sounds perfectly reasonable, but I'll note that it would require work in both the analysis server and in each client. Refactorings are a little harder to add because they allow for / require user interaction, and that requires building a UI in the client. That doesn't make this impossible, but does make it a bigger task than just adding a quick fix or quick assist.
It's never as simple as it appears, is it? :)
Totally understand if this is high effort / low reward, just an idea as it's a natural refactoring I'd noticed myself doing a number of times.
Thanks for the response!
I agree, this would be a good feature. And we actually had a lot of experience with editing UIs in the past. We even had the "Extract Composite" refactoring in one of the previous versions of our visual UI builder :-)
Yes, this is pretty much the "Extract Method" factoring with wrapping the extract code into a class with moving variables into constructor arguments instead of method arguments.
StatelessWidget seems simple enough. Would StatefulWidget any use? I also don't know whether passing in (potentially mutable) widgets, like mentioned Todo, is considered a good pattern in Flutter.
Ideally it should be a Flutter specific refactoring, and special integration with IDE(s). In the interim it could be implemented as a Quick Assist, which will generate a unique class name and initiate linked rename, or just leave it as is and allow you to use Rename refactoring as the next step.
I'd love a "extract this function/method into a new widget". Originally requested here: https://github.com/flutter/flutter/issues/11919
The feature is implemented.
You can extract either a widget instance creation or a method that return a widget.
It coverts any read local variables and fields into extract widget fields and constructor parameters.
import 'package:flutter/material.dart';
class MyWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return new Row(
children: <Widget>[
new Column(
children: <Widget>[
new Text('AAA'),
new Text('BBB'),
],
),
new Text('CCC'),
new Text('DDD'),
],
);
}
}

import 'package:flutter/material.dart';
class MyWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return new Row(
children: <Widget>[
new NewWidget(),
new Text('CCC'),
new Text('DDD'),
],
);
}
}
class NewWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return new Column(
children: <Widget>[
new Text('AAA'),
new Text('BBB'),
],
);
}
}
Yesssssss. Thanks so much!!! :shipit: 馃樃
The 'extract widget' functionality is part of the 'Refactor' menu. It would be great if it is a part of the 'Context options'.
@jwren
Most helpful comment
The feature is implemented.
You can extract either a widget instance creation or a method that return a widget.
It coverts any read local variables and fields into extract widget fields and constructor parameters.