☂️ Upstream Dart issues affecting Zulip

This tracking issue collects notes on potential work in Dart upstream that would benefit the (new) Zulip mobile app. See also:

1077

Some of these are much more important to us than others. They're organized by where the work would happen, not by importance.

Dart standard library

Dart needs a way to make code using DateTime.now be testable: https://github.com/dart-lang/sdk/issues/28985
(TODO upstream issue) Dart needs a way to make code that uses the local timezone be testable. An upstream thread nearly on-point for this is: https://github.com/dart-lang/sdk/issues/44928 and see also the DateTime.now thread mentioned above.
(TODO upstream issue) It seems sometimes the Future for an HTTP request remains uncompleted indefinitely (hours at least). This would likely be a bug in HttpClient (from dart:io) or some layer beneath it. Needs debugging to pin down. https://github.com/zulip/zulip-flutter/issues/514#issuecomment-2433558556

`dart:convert` / JSON decoding

https://github.com/dart-lang/sdk/issues/35693 Zulip impact: Potentially would save on the order of 10–50ms CPU time, and some memory, when loading server data. (The status quo is chunked so shouldn't drop frames; but we could move on from the loading screen a few frames sooner.) Some measurements of status quo here: #972

`dart pub`

(TODO upstream issue) Running just dart pub get (or flutter pub get) can cause dependencies in pubspec.lock to change, in particular for the "supporting libraries" like collection that are bundled in the Flutter SDK. That's perhaps OK in itself (modulo the desire for pinning Flutter, listed separately above) — but it should really print some kind of message explaining why. I (Greg) was confused by this for months, and I bet it confuses lots of other Flutter developers too:
85

Dart linter

We'd like to catch when a future is accidentally discarded that should be awaited. There's a lint rule called discarded_futures, but it doesn't accomplish that: it flags many cases where the future isn't discarded at all. Upstream issue, at Greg's comment explaining our view of the problem: https://github.com/dart-lang/sdk/issues/58889#issuecomment-2486708511 This is a frequently-requested feature in the community, as illustrated there. Corresponding thread in our own tracker: #731

`package:http`

(For issues in this section, the right answer may be to abandon the pure-Dart package:http in favor of package:cronet_http on Android and package:cupertino_http on iOS. See https://github.com/zulip/zulip-flutter/issues/461#issuecomment-2177588523 . In particular it seems like we've run into a couple of issues where the upstream answer for missing features in package:http is that package:http is not the future and people should use those packages instead.)

(TODO upstream issue) package:http should respect HTTP cache-control headers, at least optionally. https://github.com/zulip/zulip-flutter/issues/950
(TODO upstream issue) package:http should have the option to trust additional CAs.
- Then ideally the Flutter embedding for Android would gain the ability to read the app's "network security config" XML file and respect a setting there by making package:http trust any additional CAs the user has added in system settings.
- We would set that setting in our Android "network security config"; or pending that Flutter feature, would use the package:http option directly.
- https://github.com/zulip/zulip-flutter/issues/461 https://github.com/zulip/zulip-flutter/issues/461#issuecomment-2177588523

zulip / zulip-flutter