-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: no_logic_in_state_constructor
#3059
Comments
I wonder if we can/should also lint that you don't otherwise initialize variables in class FooState extends State<Foo> {
// Should be initializing this in initState rather than here
final MySpecialControllerThatDoesNotNeedThis _controller = MySpecialControllerThatDoesNotNeedThis(bar: 3);
...
} |
That seems overly limiting. It's totally fine (and common) to initialize a |
Maybe if it's |
What does the word "logic" mean in this context? The proposed implementation flags constructors whose body is not empty, implying that no code should be executed when an instance is created, but that appears to conflict with the claim that it's acceptable to initialize a |
I don't think there are any actual conflicts, but I agree that we could be a little bit more specific with what we mean by "logic executed at instance creation". Maybe we should mention that initializations, such as creating instances of a BAD: class FooState extends State<Foo> with SingleTickerProviderStateMixin {
FooState() {
// It's best if you don't do anything here
_animationController = AnimationController(vsync: this);
_textEditingController = TextEditingController();
_myMethod();
}
late final AnimationController _animationController;
late final TextEditingController _textEditingController;
// ...
} Good: class FooState extends State<Foo> with SingleTickerProviderStateMixin {
// Declare members here
late final AnimationController _animationController;
late final TextEditingController _textEditingController;
@override
void initState() {
super.initState();
// Initialize members and execute all other code here
_animationController = AnimationController(vsync: this);
_textEditingController = TextEditingController();
_myMethod();
}
// ...
} Good: class FooState extends State<Foo> with SingleTickerProviderStateMixin {
// Declare and initialize members here
late final AnimationController _animationController = AnimationController(vsync: this);
final TextEditingController _textEditingController = TextEditingController();
@override
void initState() {
super.initState();
// Execute all other code here
_myMethod();
}
// ...
} Bottom line is that logic executed at creation of a |
Is the proposal here that a State constructor should not even have a body? Or is it a set of statements that should be banned, like assignments, method calls, ... |
Without additional information we're not able to resolve this issue, so it will be closed at this time. You're still free to add more info and respond to any questions above, though. We'll reopen the case if you do. Thanks for your contribution! |
no_logic_in_state_constructor
Description
The constructor of a
State
object should never contain any logic. That logic should always go intoState.initState
. When people put this kind of logic into their constructor, they often run into trouble.Kind
Guard against errors.
Good Examples
Bad Examples
Discussion
Add any other motivation or useful context here.
Discussion checklist
/cc @dnfield
The text was updated successfully, but these errors were encountered: