Repository navigation
packages/flutter/lib/src/widgets/async.dart video promotes bad use of FutureBuilder #112676
Description
The "Widget Of The Week" video for FutureBuilder (https://youtu.be/ek8ZPdWj4Qo) suggests a usage of FutureBuilder where the future will be created by a function call. This is in direct contradiction of the first two paragraphs of the documentation, as well as common sense. The future cannot be built as the future: parameter to FutureBuilder, because it would be re-built every time build(...) of the enclosing widget is run.
As a result, I think there's a massive misinformation meme running around now. I have a short video on why this is broken, and how to fix it, and it's now getting 10-20 references per day counting both Stack Overflow and the Flutter Discord (https://youtu.be/sqE-J8YJnpg).
My recommendation: immediately pull the video from the docs. Ideally, replace it with a proper video that shows the future coming from a variable. But saying nothing is better than saying the wrong thing, and the first two paragraphs of the documentation explain it properly anyway.
Activity
jonahwilliams commentedon Sep 30, 2022
Yeah that video is pretty wrong, we should do better by either showing a Future that is cached in a StatefulWidget, or (even better) one that is cached in some sort of service layer.
RandalSchwartz commentedon Sep 30, 2022
@slightfoot and I have been discussing adding a 'create:' to both FutureBuilder and StreamBuilder which would take a callback function to create the Future or Stream, which would get called only if no value is provided, and held in the builder. This would solve 95% of the cases we've seen done wrong, and it would be backwards compatible.
jonahwilliams commentedon Sep 30, 2022
In order to cache the future/stream in the State object? That would still have issues if there is any stateloss, but that is still probably better than the situation we're in today. Happy to review a PR
HansMuller commentedon Sep 30, 2022
CC @craiglabenz
craiglabenz commentedon Sep 30, 2022
Thanks for raising this, @RandalSchwartz. But for your attention to detail, we may not have ever really noticed this; and because of your attention to detail, a refreshed episode for
FutureBuilderis coming very soon.satvikpendem commentedon Oct 5, 2022
I'd also add in the new video to show what could happen were it the case that the future or stream is referenced directly in the build method, like @RandalSchwartz's video shows with incrementing the counter and the future or stream running again. The video would then show the correct solution and show that the future or stream does not run again when placed in a variable.
RandalSchwartz commentedon Oct 5, 2022
I would disagree. The "Flutter of the week" series works well because it merely alerts you to the presence and relative scope of a particular widget, and does not purport to be a "how to use" tutorial except in passing. The subtleties to explain the relationship of build with FutureBuilder and StreamBuilder cannot be adequately represented in this context.
I'd be happy with the video just not showing a bad practice. :)
RandalSchwartz commentedon Oct 29, 2022
So, the problem hasn't gone away. I'm still seeing people copying bad behavior daily. @slightfoot and I have chatted a bit about adding a "create:" callback to FutureBuilder/StreamBuilder, but we've both had busy schedules.
MelbourneDeveloper commentedon Nov 4, 2022
I'm a bit confused here.
FutureBuilderis aStatefulWidget. That means that all things being equal, it will hold onto the state across rebuilds.@RandalSchwartz is this the code you are referring to?
At least from what I can tell here, this
FutureBuilderwill get the result of the HTTP call and then hold onto that state across rebuilds. Is there something I'm missing here?3 remaining items
MelbourneDeveloper commentedon Nov 5, 2022
Yes very good point
RandalSchwartz commentedon Nov 17, 2022
I like the new video! https://youtu.be/zEdw_1B7JHY
I presume it will be incorporated in docstring for FutureBuilder, which will satisfy the initial concern for my initiating this issue. We still should discuss adding a create callback for FutureBuilder and StreamBuilder to avoid the need for visible state variables to hold the future or stream. Should that be from another ticket?
Hixie commentedon Mar 16, 2023
The API docs now refer to the new video, and I'll remove the link to the old one.
For API changes, please consider making a new issue, yes. Thanks!
MelbourneDeveloper commentedon Mar 16, 2023
@Hixie @RandalSchwartz
Perhaps you may be interested in this PR/Issue. This issue partially inspired this new widget. Comments and reactions welcome.
#121962
#121963
github-actions commentedon Apr 6, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.