Repository navigation
[proposal] Force user to at least use one or both from initalData or Future in FutureBuilder #83081
Description
Use case
While learning flutter FutureBuilder , I was just creating a small POC for my understanding i.e fetching data from Rest Api (randomuser.me). In FutureBuilder default constructor we have three things from which initalData and future is optional.
const FutureBuilder({
Key? key,
this.future,
this.initialData,
required this.builder,
}) : assert(builder != null),
super(key: key);While making POC I forgot to supply both(future and initialData) but everything seems working fine. Untill I found it's not fetching data from web Api. I had spend around 15 minutes checking why my code is not fetching data from REST Api. Then I saw future is missing.
Flutter kept executing builder without even woorying about future which seems to bad UX for me as a developer. We should atleast warn or force developers to provide a future or initialData.
Eg.
FutureBuilder<String>(
builder:(ctx,snapshot)=>CircularProgressIndicator(),
);Everthing will work fine on above code, but will not work as expected since we haven't supplied necessary arguments.
Proposal
I think we should add one more validation(assert) in FutureBuilder<String>(). Which will force developers to supply atleast one or both from future and initialData.
Below is what I think can be done to improve UX of developing apps in flutter.
const FutureBuilder({
Key? key,
this.future,
this.initialData,
required this.builder,
}) : assert(builder != null),
assert(!(future == null && initialData == null),'Future and initialData cannot be null at same time'),
super(key: key);I have already started working on these. Just want to know if these can be accepted or we should move in any other direction.
These is my First Proposal or Feature Request. Pardon me for any mistakes.
Activity
agwanyaseen commentedon May 25, 2021
what's next on these?
kenthinson commentedon Jun 29, 2021
I would caution that this might break a lot of apps. In my app I start without the Future defined (null), then at runtime depending on the users choice it is created.
I would need to provide dummy data in initalData
or use gate logic to not display the FutureBuilder until after the choice is made.
If I'm using logic to block display of the FutureBuilder then I would need to wrap the FutureBuilder in an additional Builder.
Not the end of the world, but still less convenient.
Being able to put all related build logic into one build function is convenient.
First we gate:
if(hasData)
return data display
if(hasError)
return error message
if(connectionState == waiting)
return loading spinner
etc.
return Default Layout with user choices.
caseycrogers commentedon Apr 20, 2023
Carrying over from my duplicate issue:
imo the important part is that the developer be required to specify a
future. They can still manually set it to null, they just can't omit it:While there are perfectly good reasons to pass a nullable future (see @kenthinson's earlier comment) I can't think of a coherent case where a developer would intentionally omit the
futureargument. And if there is a coherent case, they can simply writefuture: null.Same applies for
StreamBuilder.stream. Both should be changed at once to keep the two APIs consistent with eachother.domesticmouse commentedon Apr 21, 2023
I'd vote that this is worth promoting higher than P5 as it makes learning flutter with futures less error prone.
I'm assuming this is a breaking API change and should be initially built out as a lint with a fix before introducing a breaking API change?
[-][proposal] Force user to atleast use one or both from initalData or Future in FutureBuilder[/-][+][proposal] Force user to at least use one or both from initalData or Future in FutureBuilder[/+]goderbauer commentedon May 2, 2023
Making them required sounds reasonable.
This depends on whether the change makes any customer tests fail... if it doesn't we can just make the change.
github-actions commentedon May 16, 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.Make `future` and `stream` required arguments in their respective bui…