You could make the _AnimatedChildSwitcherChildEntry implement AnimatedChildSwitcherLayoutData and then just pass the actual _AnimatedChildSwitcherChildEntry in instead of copying the data over.

Oooh! Nice!

presumably this should be final?

or at least, just a getter?

Nope, should be final.

If you do the thing above with the abstract class bla bla, you'll probably want it to be a getter in this interface, and a mutable field in the concrete subclass.

Signature for builders used...

Done

ditto

Done

strike "essentially"

though then this reads a bit weird, since you are sometimes saying they're the same and sometimes saying they're different.

Done, essentially. :-)

probably not a UniqueKey. That would likely trigger the same bug you saw earlier.

maybe only mention valuekey.

constructor docs are out of date

also constructor docs should say what it does

Done

talk about the default, and maybe something about the contract here?

Done.

ditto

Done.

looks like _currentChild can never be false, since we set it in initState, so you can remove the ?

unless you change the semantics as suggested above

in which case you could just make this _currentChild != null

then you could use it directly in addEntry

Yeah, I updated it to the new semantics.

missing docs

this class should have an opinion about whether widget can be null. if it can, this should be documented with emphasis, since that is likely to cause null derefs.

May be better to not call the callbacks when there's a null child?

addEntry's logic is a bit wrong for the case of _currentChild.widget == null. We should probably consider moving to a world where if widget.child is null, we set _currentChild to null rather than setting its widget to null and still creating a (useless) animation controller.

Fixed.

this should be in didUpdateWidget

why isn't this just a list of Widgets?

something else we need to do here is make sure we put keys on each of these children, otherwise the animations will get all messed up -- e.g. if you have animations A, B, and C running, then A ends and you take it out, without keys, B will be synced with A, C will be synced with B, and all of them will lose the state of any descendants.

OK, but how can I do that if the transition builder is the one creating the children? I can add it in the default, but not enforce it.

Should I use "KeyedSubtree" to do this?

Yeah, KeyedSubtree. (Or pass the key to the child and require the contract to be that they must use the key, which is what AnimatedCrossFade does iirc, though that makes the API less nice.)

OK, I did it with KeyedSubtree to make it cleaner.

you need to update _currentChild.widget to the new widget.child if you don't add an entry.

you either need an extra comma after "previously" or to remove the comma after "is", otherwise the sentence becomes "{Represents a child that is} or {was previously set on the [AnimatedChildSwitcher.child] field that needs to be laid out using a [AnimatedChildSwitcherLayoutBuilder]}.", which makes no sense.

Fixed.

wait, i'm confused. I thought this was the interface you had to pass to the transition builder, but actually you only use it for the layout builder. Why not just pass the layout builder a List<Widget>?

Because the layout builder might need to see all of the animations too in order to do its layout. The default one doesn't, but that doesn't mean that another layout won't want to animate them.

Either add the magic null factory constructor here (see the chip pr i submitted) if you want this to be an interface, or add a const constructor with the const constructor boilerplate if you want this to be a superclass (then use "extends" instead of "implements" below).

Done.

please keep the arguments, asserts, and fields in the same order.

Sorry, got a little messed up there... Done.

trailing comma

Fixed.

this paragraph is now moot

Removed.

unlikely that a UniqueKey is what one wants

Oh? Why? Isn't it going to generate a unique key each time, which is what the user might sometimes want here? I can see cases where it might be onerous to collect all of the "values" and decide if the widget is different visually, and instead they just put a UniqueKey on it each time they swap it out.

Edit: I see from below why (fading when rotating, etc.).

This should be a ValueKey<int>(count). Otherwise, rotating the phone (for instance) would cause the text to fade.

OK.

+= 1

You need a blank line before the list.
Also, only indent the bullet by one, so that the text is indented by 3.

Fixed, and below.

Convention for State vars is to make them _private.

Ok. I didn't think that mattered as much in a private class. Done.

The duration of the transition from the old [child] value to the new one.

Done.

The animation curve to use when transitioning in [child].

Done, thanks for catching these.

The animation curve to use when transitioning the previous [child] out.

Done.

It would be more helpful to say what this builder function is for: A function that wraps the new [child] with an animation that transitions the [child] in when the animation runs in the forward direction and out when the animation runs in the reverse direction.

Done.

It would be more helpful to say what this builder function is for: A function that wraps all of the children that are in the midst of transitioning out and the [child] that's transitioning in, with a widget that lays all of them out.