[beta branch] Migrate animation sample

[RedBrogdon]

• Ups the SDK minimum for /animations to 2.12.0-0
• Migrates all the code
• Changes the animated list sample from using indexes to identify records to using IDs.
• Updates pubspec.(yaml|lock)

Comments especially welcome on the changes for migration.

[domesticmouse]

I'm curious how nulls could be inserted this animation.

[RedBrogdon]

While doing the conversion, this was a weird part for me as well. ColorTween is a glorified version of Tween<Color?>, which does allow for a null Color value:

https://github.com/flutter/flutter/blob/7c0300a3588d91542366d9efadda26fa2c9d9224/packages/flutter/lib/src/animation/tween.dart#L355

I thought about switching to Tween<Color>, but that would cause us to lose the Color-specific lerp function provided by ColorTween.

In the case of this example, I don't expect the tween to ever produce a null value, but it looks like MaterialButton is perfectly happy to accept one and just use the default color in response:

https://github.com/flutter/flutter/blob/88809aa24720705d1cd8de0bfc46faf932fe0b6e/packages/flutter/lib/src/material/material_button.dart#L180

[johnpryan]

Oof, the docs for Tween call this out:

  /// See the constructor for details about whether this property may be null
  /// (it varies from subclass to subclass).
  T? begin;

ColorTween and most subclasses allows null intentionally:

  /// We recommend that you do not pass [Colors.transparent] as [begin]
  /// or [end] if you want the effect of fading in or out of transparent.
  /// Instead prefer null. [Colors.transparent] refers to black transparent and
  /// thus will fade out of or into black which is likely unwanted.

To me, this seems weird for users, but at least it's explicit now.

[johnpryan]

Oof, the docs for Tween call this out:

  /// See the constructor for details about whether this property may be null
  /// (it varies from subclass to subclass).
  T? begin;

ColorTween and most subclasses allows null intentionally:

  /// We recommend that you do not pass [Colors.transparent] as [begin]
  /// or [end] if you want the effect of fading in or out of transparent.
  /// Instead prefer null. [Colors.transparent] refers to black transparent and
  /// thus will fade out of or into black which is likely unwanted.

To me, this seems weird for users, but at least it's explicit now.

[johnpryan]

What's weird about this is that it doesn't seem to be possible to implement a Tween with a non-nullable T:

class TypewriterTween extends Tween<String> {
  late String _begin;
  late String _end;

  TypewriterTween({String begin = '', String end = ''}) : _begin = begin, _end = end;

  @override
  String get begin => _begin;
  @override
  String get end => _end;
  @override
  set begin(String s) => _begin = s;
  @override
  set end(String s) => _end = s;

  @override
  String lerp(double t) {
    var cutoff = (end!.length * t).round();
    return end!.substring(0, cutoff);
  }
}

But I can't seem to reproduce this in DartPad. This sample works just fine:

void main() {
  var b = B('foo');
  print(b.s);
}

class A<T> {
  T? s;
}

class B extends A {
  String _s;
  B(String s) : _s = s;

  String get s => _s;
  set(String s) => _s = s;
}

[RedBrogdon]

Yeah, this threw me a bit, as you probably saw. Tween takes a single type param, and then defines begin and end with the nullable version of that type parameter.

[johnpryan]

Yeah T? is a subtype of T so it's not clear to me why this isn't working

[RedBrogdon]

I thought the subtype relationship was the reverse (String is a subtype of String?). I'm going to go read the null safety guide again. 😄

[RedBrogdon]

@johnpryan Thanks, and PTAL! I believe I've addressed all the actionable comments.