Refactoring - Move Widget/Class to New File

[skybur]

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.

[DanTup]

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]

Wow that issue is almost 2 years old 😅

[DanTup]

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]

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]

12+ now :) Refactoring is all we need to be code boy scouts. Any news on this feature @DanTup ?

[DanTup]

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]

Now there are 66, will there be any updates now?

[DanTup]

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]

https://dart-review.googlesource.com/c/sdk/+/212562
It looks like this feature will finally be supported in SDK.

[tieorange]

Any updates?
It would be useful during refactor of legacy code for us

[shtse8]

It's painful without this feature.
Spent lots of time to create new file, copy and paste code, update import on each files....

[patniemeyer]

It is the # 1 repetitive manual thing that I have to do when developing in Flutter... Flutter does a great job at helping you refactor code into reusable widgets, but then completely bails on what should be the easy part - helping you organize the widgets in a sensible way in your project. For three years now I've been tempted to write a plugin to do this myself but I keep talking myself out of it, thinking: "surely this will be in the next update..."

[DanTup]

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]

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]

@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]

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]

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).

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]

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:

• file headers may be inserted after the moved class
• moved classes may be inserted above import statements
• moving sealed classes does not automatically move their direct subclasses
• moving sealed classes/subclasses that are spread across part files is allowed and results in invalid code (for now, moving sealed types with direct subclasses in other parts 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:

	"dart.experimentalNewRefactors": true, // current flag
	"dart.experimentalRefactors": true, // future flag

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]

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!