☂️ Upstream Dart issues affecting Zulip

[gnprice]

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

• ☂️ Upstream Flutter issues affecting Zulip #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:
  Code that uses DateTime.now is untestable dart-lang/sdk#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:
  Add support for running tests in multiple timezones dart-lang/sdk#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.
  Consider overall timeout for long-poll requests #514 (comment)

Native assets / FFI

• Ship binaries for Dart unicode-org/icu4x#4689
  We'll want ICU data for:
  Sort channel names the same way as Zulip web #1165
  autocomplete: In @-mention results, match insensitively to diacritics #237
  For emoji autocomplete, match insensitively to diacritics #1067
  Add locale-aware sorting #1399

dart:convert / JSON decoding

• JSON: support custom encode/decode without intermediate objects dart-lang/sdk#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: api: Use streaming UTF-8 + JSON decoding for the response #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:
  pubspec.lock sometimes doesn't work as a lockfile #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:
  Possible false positive in discarded_futures lint dart-lang/sdk#58889 (comment)
  This is a frequently-requested feature in the community, as illustrated there.
  Corresponding thread in our own tracker: Lint on unawaited futures #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 #461 (comment) . 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.
  Make use of caching headers on server emoji data #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.
  • Trust user-added CAs on Android #461
    Trust user-added CAs on Android #461 (comment)

[gnprice]

(Posting a first comment, to have the option to edit it as a home for related information in the future.)