Repository navigation
Create a ValueListenableBuilder - #19729
Conversation
9da5fbd to
0d9fb7d
Compare
There was a problem hiding this comment.
I test that the listeners are indeed removed when I remove the builder from the tree
There was a problem hiding this comment.
i would just subclass ChangeNotifier in your test. But this is fine too I guess.
|
How does this differ from an AnimationBuilder? |
|
It gives you the value of the listenable so the builder function can build from it without the owner of this widget needing to capture the source of the data again to re-plumb it into the build function which seems like a leak of abstraction. The AnimatedWidget API seems to be made to be suitable for subclassing (where the subclass owns the listenable anyway) rather than use by composition (like the FutureBuilder, StreamBuilder API). |
|
I meant AnimationBuilder, not AnimatedWidget. As far as I can tell this is identical except for passing the value through, but it's not clear how useful that is. You always have the ValueListenable when building this widget, obviously, so using it in the closure passed to |
|
I guess I was referring to the AnimatedBuilder too (just that the meat of it is inside AnimatedWidget). Half of it is the discoverability. We can't do much about it now but 'Animated'Builder would definitely throw people off. The other half is still to avoid the leak of abstraction. The owner of the ValueListenableBuilder should be just compose things (the listenable and the handler) without wanting to know how to open either of them. Imagine an owner that has its own problem domain and then also knows how to retrieve a listenable via some injection mechanism and is given a function instance. It should be able to just pass the function to the ValueListenableBuilder it creates without first unpacking the ValueListenable itself and then re-invoke the function in a specific way. |
ebdfe80 to
0773c74
Compare
2824f6e to
26a5ef3
Compare
There was a problem hiding this comment.
this adds a listener, and thus leaks listeners.
To avoid this kind of accidental leak, I recommend always being symmetric when adding and removing listeners.
So you would explicitly add one in initState, remove one in dispose, and add/remove them in didUpdateWidget.
There was a problem hiding this comment.
don't forget to add a test for this too :-)
|
|
26a5ef3 to
2c8cc04
Compare
This reverts commit ea355c6.
3 participants
No description provided.