case study: add the widget tree to the leak and document the method contract. #4932
Conversation
polina-c
changed the title
polina-c
changed the title
| MyIncrementer(this.increment); | ||
|
|
||
| MyIncrementer(this.increment, this.screen); | ||
| final Scaffold? screen; |
There was a problem hiding this comment.
why do we need to store the widget in this class? It is bad practice to store widget objects, so I'm wondering if we should put this into a case study app. (unless of course, this is to demonstrate that it is bad practice to store Widget objects?)
There was a problem hiding this comment.
yes, it is bad practice and source of leak
There was a problem hiding this comment.
A slightly more natural looking thing you could do would be to store a BuildContext object. Our quick fix to turn a function into a widget often accidentally adds a BuildContext as a parameter to a widget.
There was a problem hiding this comment.
Thanks. I moved screen calculation out of closure to make it leaking and we do not need to store widget to produce leak any more.
I added context, but it does not contribute to the leak as it is always the same. What is leaking here is every time built screen.
Update: #4942
3 participants
The contract should be explained to make it clear what fixes will not break the functionality.