| commit | 4d86f5d00d8deb06c1e779a1646ca678b2f1c416 | [log] [tgz] |
|---|---|---|
| author | Casey Rogers <caseycrogers@berkeley.edu> | Tue May 02 01:03:02 2023 -0700 |
| committer | GitHub <noreply@github.com> | Tue May 02 08:03:02 2023 +0000 |
| tree | 05343120c7f0fae80d8a638a5f39a9debde81068 | |
| parent | 7907f931f572d8886f2316872d634e3582758e0d [diff] |
Make `future` and `stream` required arguments in their respective builder widgets (#125838) 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].*
Flutter is Google's SDK for crafting beautiful, fast user experiences for mobile, web, and desktop from a single codebase. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
For announcements about new releases, follow the flutter-announce@googlegroups.com mailing list. Our documentation also tracks breaking changes across releases.
The Flutter tool may occasionally download resources from Google servers. By downloading or using the Flutter SDK, you agree to the Google Terms of Service: https://policies.google.com/terms
For example, when installed from GitHub (as opposed to from a prepackaged archive), the Flutter tool will download the Dart SDK from Google servers immediately when first run, as it is used to execute the flutter tool itself. This will also occur when Flutter is upgraded (e.g. by running the flutter upgrade command).
We think Flutter will help you create beautiful, fast apps, with a productive, extensible and open development model, whether you're targeting iOS or Android, web, Windows, macOS, Linux or embedding it as the UI toolkit for a platform of your choice.
We want to enable designers to deliver their full creative vision without being forced to water it down due to limitations of the underlying framework. Flutter‘s layered architecture gives you control over every pixel on the screen and its powerful compositing capabilities let you overlay and animate graphics, video, text, and controls without limitation. Flutter includes a full set of widgets that deliver pixel-perfect experiences whether you’re building for iOS (Cupertino) or other platforms (Material), along with support for customizing or creating entirely new visual components.
Flutter is fast. It's powered by the same hardware-accelerated 2D graphics library that underpins Chrome and Android: Skia. We architected Flutter to support glitch-free, jank-free graphics at the native speed of your device. Flutter code is powered by the world-class Dart platform, which enables compilation to 32-bit and 64-bit ARM machine code for iOS and Android, as well as JavaScript for the web and Intel x64 for desktop devices.
Flutter offers stateful hot reload, allowing you to make changes to your code and see the results instantly without restarting your app or losing its state.
Flutter works with any development tool (or none at all), and also includes editor plug-ins for both Visual Studio Code and IntelliJ / Android Studio. Flutter provides tens of thousands of packages to speed your development, regardless of your target platform. And accessing other native code is easy, with support for both FFI (on Android, on iOS, on macOS, and on Windows) as well as platform-specific APIs.
Flutter is a fully open-source project, and we welcome contributions. Information on how to get started can be found in our contributor guide.