Repository navigation
Refactoring - Move Widget/Class to New File #1831
Description
I don't know if this is VSCode feature request or specifically for dart/flutter, but is it possible to move a widget class (or any other class) to a new file? If I remember correctly Visual Studio have this refactoring option.
Say I have this my_widget.dart file.
class MyWidget extends StatelessWidget {
const MyWidget({Key key}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container(
child: child,
);
}
}
class MyOtherWidget extends StatelessWidget {
const MyOtherWidget({Key key}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container(
child: child,
);
}
}
I want to move MyOtherWidget to my_other_widget.dart (automatically created) and automatically import that file if my_widget.dart contains MyOtherWidget references. Sorry if this is a duplicate.
Thank you.
Activity
DanTup commentedon Jul 8, 2019
This requires support in the SDK's analysis server before it can be supported here. There's an open issue for it you can 👍 and subscribe to at dart-lang/sdk#30310.
If it's added to the server, then it could be exposed here in VS Code.
skybur commentedon Jul 8, 2019
Wow that issue is almost 2 years old 😅
DanTup commentedon Jul 8, 2019
Yeah, it only has 3 👍's including yours. I don't think it's in huge demand (probably mostly because people tend to put many classes per file).
Jonas-Sander commentedon Oct 23, 2019
Well 11👍 now ;)
I really wish to have way more refactorings for dart and this is one that I would honestly use very often.
rasmuschristensen commentedon Mar 15, 2020
12+ now :) Refactoring is all we need to be code boy scouts. Any news on this feature @DanTup ?
DanTup commentedon Mar 17, 2020
This would first need to be implemented in the analyzer in the SDK (dart-lang/sdk#30310). Once implemented there, it would be available to both VS Code and IntelliJ/Android Studio extensions to expose in the UI.
vishnuagbly commentedon Jul 29, 2020
Now there are 66, will there be any updates now?
DanTup commentedon Jul 30, 2020
As mentioned above, this can't be implemented here until it's available in the server. There was a response posted on the SDK issue last month:
dart-lang/sdk#30310 (comment)
Jannchie commentedon Oct 2, 2021
https://dart-review.googlesource.com/c/sdk/+/212562
It looks like this feature will finally be supported in SDK.
9 remaining items
DanTup commentedon Jan 3, 2023
Sorry for the lack of updates/progress here. Work has started on a new refactoring mechanism that will make it easier to build new refactors like this. Previously refactors needed work in both the analysis server and the IDE plugins for each refactor, which also made it difficult to ever change the refactors. The new system aims to remove the need for the IDE plugins to handle each refactor specifically, with everything driven by the Dart analysis server.
The "Move to file" refactor is the first refactor being built to test out this mechanism, but it's not complete yet. I don't know when it'll be ready for use, but the desire for this feature is known and it's definitely not being ignored :-)
adam-ah commentedon Feb 20, 2023
We can soon celebrate the 4th anniversary of this report, and a whopping 6th of the original (dart-lang/sdk#30310) - anyone wants to guess how many hundreds of engineering man-years were wasted globally in past 6 years, copy-pasting code?
Worst case scenario a regex based hack could have temporarily solved this until the golden-plated solution arrives.
DanTup commentedon Feb 20, 2023
@adam-ah this feature has been implemented - but not yet enabled/shipped - as noted in the issue you linked to. I appreciate it's taken a while to get to, but this isn't because it's being ignored or because it's not a good idea. There are a lot of feature requests and users don't all have the same priorities so no matter what order they're worked on, some people are going to feel theirs are not being progressed.
There are explanations above and in the SDK issue about why it's taken a while to get to this (if you're interested). You're welcome to share your opinions in this tracker, but please be respectful of the developers that are working hard to deliver features, even if they're not the features that are most important to you.
adam-ah commentedon Feb 20, 2023
Thank you, and I agree, @DanTup, we all need to be respectful when responding to feature requests and bugs. Even when responding with
"Yeah, it only has 3 👍's including yours. I don't think it's in huge demand",
especially given the situation we are in today: hundreds of upvotes, and 6 years of wait. Unfortunately, GitHub is not great at sorting issues based on upvotes (unlike UserVoice).
Sometimes it is good to reflect on the project's priorities and goals - whether all the features shipped since reporting this one were really more impactful. This is something I cannot comment on.
Regardless, the community is very much appreciative of all the exceptional work being put into these projects, and I am sure this feature will be very welcome once it is released...
DanTup commentedon Feb 21, 2023
It's clear I underestimated the demand for this issue, but at the time I only had the 👍 's to go on. I don't think that's disrespectful. As I noted above, work has been done in this refactor because since then it became clear that there was demand for it. In December 2020 I filed microsoft/language-server-protocol#1164 to try and get a standard LSP way to prompt the user for input specifically for this. We had to make a decision of building something ourselves (which required some custom framework in the VS Code extension and would be VS Code specific) versus waiting for something standard in LSP. Ultimately we gave up waiting and built something custom, but there are many reasons that contributed to this taking longer than you (and we) would have have liked. The period between the issue having a large number of 👍 's and us trying to start the ball rolling is far shorter than the entire period you're quoting.
Again, I'm sorry it's taken so long. The feature is largely implemented now, you'll be able to use it in a future release. If you're trying out the Dart 3 alpha, instructions to try this out with an experimental flag are at dart-lang/sdk#30310 (comment). Thanks for your patience.
DanTup commentedon Mar 28, 2023
Repeating what I posted in the SDK issue here for anyone subscribed here but not there.
--
FYI, I'm making some slight changes to the opt-in flag for experimental refactors. The existing flag (
"dart.experimentalNewRefactors") was for entirely enabling the new refactoring system. This was fine for initial development but doesn't allow us to have both experimental + stable refactors using this system in future.In an upcoming release, that flag will be replaced by
"dart.experimentalRefactors"(the word "New" has been removed) and it will now control only specific refactors that are marked as experimental.For the time being, the "Move to File" refactor will continue to be considered experimental. You're welcome to try it out and provide feedback to help find any remaining issues, but be aware that in the current stable and current Dart 3 pre-release SDKs it's incomplete and has several known issues, such as:
partfiles is allowed and results in invalid code (for now, moving sealed types with direct subclasses in otherparts will not be supported)If you find any issues not listed above, please file new issues (and feel free to cc me). If you want to update your settings in advance so the experimental refactor doesn't disappear when you get an SDK with this change, you can include both flags in your VS Code settings:
Though be aware that these flags may also cause other incomplete refactors to show up in future, so you may wish to disable them once this refactor is no longer considered experimental.
DanTup commentedon Jul 27, 2023
Closing this as complete - the current Beta SDKs no longer require the experimental flag for this refactor to show up. Unless major issues are found, this should mean the same is true for the next major Dart/Flutter SDK releases.
If you find any issues when using this refactor (on the current beta or future releases), please file new issues here or in the https://github.com/dart-lang/sdk repo. Thanks!