You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The State class doesn't store any state in member variables and it also doesn't use any of the properties provided by Sate (e.g. mounted). This could easily be refactored to be a more concise StatelessWidget:
I wonder if it would be possible to have a lint for this?
Of course, from a functional perspective using a StatefulWidget here is totally fine, the additional performance overhead of a StatefulWidget over a StatelessWidget is probably neglectable. However, using a StatelessWidget where appropriate leads to more compact, concise, and readable code and is more idiomatic, IMO.
The text was updated successfully, but these errors were encountered:
I wonder if it would be possible to have a lint for this?
Yes, the lint appears to be well defined, so it should be possible to implement it. I'm not sure how often code like this is written, so it's hard to gauge how much value such a lint would bring to users, but it seems doable.
I'm not sure how often code like this is written @bwilkerson I agree with about the complexity, but if we make the following simple checks than I think we are good to go.
Check if widget hasn't a setState
Check if the widget hasn't a life cycle methods
Check if the widget hasn't any non final field (optional)
a14n
linked a pull request
Sep 23, 2022
that will
close
this issue
Occasionally, I see Flutter code where people use StatefulWidgets even though a StatelessWidget would have been sufficient. Example:
The
State
class doesn't store any state in member variables and it also doesn't use any of the properties provided bySate
(e.g.mounted
). This could easily be refactored to be a more conciseStatelessWidget
:I wonder if it would be possible to have a lint for this?
Of course, from a functional perspective using a StatefulWidget here is totally fine, the additional performance overhead of a StatefulWidget over a StatelessWidget is probably neglectable. However, using a StatelessWidget where appropriate leads to more compact, concise, and readable code and is more idiomatic, IMO.
The text was updated successfully, but these errors were encountered: