forked from firka/flutter
4d86f5d00d
cc'ing existing conversation participants: @domesticmouse @srawlins cc'ing to request review: @goderbauer This PR makes the following constructor arguments required: 1. `FutureBuilder.future` 2. `StreamBuilderBase.stream` 3. `StreamBuilder.stream` This fixes: https://github.com/flutter/flutter/issues/83081 https://github.com/flutter/flutter/issues/125188 (dupe of 83081) This obviates: https://github.com/dart-lang/linter/issues/4309 (I suggest we skip straight to merging this PR as this should be a low impact breaking change-assuming few to no devs are intentionally using the builders without their relevant arguments, however we could always merge 4309 first and then this) https://github.com/flutter/flutter/pull/83101 (The above PR required that at least one of future and initial data be non-null, this is undesirable as there are plenty of valid reasons to have both arguments be null) See above issues for a deeper dive, but here is a summary: It is very easy for a developer to forget to specify `future` or `stream` when using the respective `*Builder` widgets. This produces a non-obvious failure where the UI sits in a "no data yet received" state. It is easy for a dev to misinterpret this as the async work backing the future/stream hanging and they thus waste a lot of time trying to debug the async work. As such, we should require these two constructor arguments to make it impossible/much harder for devs to make this time-wasting mistake. This is a breaking change. However, it should break only a small number of active projects given that using a builder without specifying `future` or `stream` seems highly niche. The only place I've found non-accidental examples of this is in widget tests where you're calling `pumpWidget` with and without these arguments to test `*Builder.didUpdateWidget`'s behavior. In this and similar cases, it is a trivial fix to add `future: null`/`stream: null`. *If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*