Option to "Convert to Stateless Widget"

[ghost]

@ThinkDigitalSoftware commented on Aug 5, 2019, 5:14 PM UTC:

Can we have the option to convert to a stateless widget if all variables if any are immutable?

This issue was moved by helin24 from flutter/flutter-intellij#3734.

[ghost]

@stevemessick commented on Aug 6, 2019, 2:49 PM UTC:

@scheglov Does this seem like a reasonable request? I'd be concerned that our list of actions might get too large if we do everything.

[ghost]

@ThinkDigitalSoftware commented on Aug 6, 2019, 6:04 PM UTC:

I figured it would be natural to add the companion. Also, it wouldn't be present at the same time as the convert to stateful, so the list length would stay the same

…

On Tue, Aug 6, 2019, 7:49 AM stevemessick ***@***.***> wrote: @scheglov <[https://github.com/scheglov](https://github.com/scheglov)> Does this seem like a reasonable request? I'd be concerned that our list of actions might get too large if we do everything. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <[#3734](https://github.com/flutter/flutter-intellij/issues/3734)?email_source=notifications&email_token=AFPYO7OK2PAP2YBPDGU6AMTQDGFQLA5CNFSM4IJNHC6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VMRAQ#issuecomment-518703234>, or mute the thread <[https://github.com/notifications/unsubscribe-auth/AFPYO7I2LKBUKAWLVXFS4BTQDGFQLANCNFSM4IJNHC6A](https://github.com/notifications/unsubscribe-auth/AFPYO7I2LKBUKAWLVXFS4BTQDGFQLANCNFSM4IJNHC6A)> .

[ghost]

@scheglov commented on Aug 6, 2019, 6:05 PM UTC:

@ThinkDigitalSoftware could you please provide a couple of example when it should happen, and when not?

[ghost]

@ThinkDigitalSoftware commented on Aug 6, 2019, 6:14 PM UTC:

Sure. In this case, it should show up, since this is an easy conversion with no possible side effects. I.E. move the build function and delete the createState.

class SampleWidget extends StatefulWidget {
  @override
  _SampleWidgetState createState() => _SampleWidgetState();
}

class _SampleWidgetState extends State<SampleWidget> {
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

In this case, all variables are immutable. No setState calls.

class SampleWidget extends StatefulWidget {
  @override
  _SampleWidgetState createState() => _SampleWidgetState();
}

class _SampleWidgetState extends State<SampleWidget> {
  final variableA = 7;
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

no variables are reassigned here, no setState calls. variable can be made immutable and moved over.

class SampleWidget2 extends StatefulWidget {
  @override
  _SampleWidget2State createState() => _SampleWidget2State();
}

class _SampleWidget2State extends State<SampleWidget2> {
  String aString = "Hello, world";
  @override
  Widget build(BuildContext context) {
    return Container();
  }
}

The cases where it shouldn't show up are all the cases not shown here. If a widget has state that's internally managed, it's not available for that refactor. If setState is used...

My use case is that I switched to managing the state of my widget to outside of the widget. I moved out all the mutable variables and then had to cut, paste and delete (and change Stateful to Stateless) to get it done.

[ghost]

@jacob314 commented on Apr 21, 2020, 3:26 PM UTC:

I've found myself wanting this refactor a few times. Often you have a stateful widget and then you perform some refactors so it can be stateless but it takes a lot of manual boilerplate renames to make it a stateless widget (e.g. remove widget. in lots of places so it would be very handy to have this lint and quickfix.

[asashour]

Should this be a lint and moved to linter project? or should it be an assist or refactoring in sdk project?

[bwilkerson]

It would be an assist, similar to FlutterConvertToStatefulWidget.

[jacob314]

We should also add a lint as a lint + quickfix makes it 10X more discoverable than just an assist.
The lint would warn any time you have a stateful widget with only (non-late) final fields in the state.

[asashour]

sdk/250087, which currently proposes:

Widget can not be Stateless if there is any of:

• a call to one of State methods (outside a default override of calling the super method)
• a static method or field in State subclass