Animate cards in boardgame-card-stack

[jkomoros]

Card collection views handle animations.

Cards have a unique ID that is used by the collection to keep track of which one's which.

The render-view has a direct child of . Call Mark() right before databinding to capture a snapshot of where cards are, then Animate() right after databinding is (synchronously) done. Will go through and find all collections rooted below, and note where differences are and animate. (How do we get spacers in to animate? maybe just use margin-right on the card to the left, with no element in between)

Related to #347

TODO: figure out how to handle cards that transition from face down to face up

[jkomoros]

The collection should take a stack and optionally print out all of the elements themselves (but how would you pass the element to use for front of card?)

collection takes the stack, each card takes the expanded component

[jkomoros]

https://react-overdrive.now.sh/

https://aerotwist.com/blog/flip-your-animations/

[jkomoros]

• [x] boardgame-cards have an id property (expandState might need to be udpated)
• [x] boardgame-card-collections have a IdsLastSeen property
• [x] all boardgame-card-collections have a singleton state where they register themselves and reregister on connected/disconntected callbacks, so that the animator singleton can instantiate one and then read that magic property
• [x] Create the animation coordinator singleton
• [x] Implement coordiantor.prepare()
• [x] Figure out how to get the pre-transformed value, as well as a practical transform to animate to
• [x] Implement coordinator.animate()
• [x] Fix the bug where animations aren't happening. I think the problem is that there are multiple state sets immediately after one another and the no-op ones are stamping on the in-progress ones. (If transform is 0,0, don't transform... although we do need to do transform to measure...) (SEE COMMENT BELOW)
• [x] create an animation controller debug rig view that manually manages state clientside with things like move card back and forth between these two collections, for easier debugging
• [x] do the transitions not get set in the style engine until nex tmicro task?
• [x] fix bug in debuganimations where the cards are rotated to what they were set to BEFORE the animation.
• [x] cards that animate flipped property show item before and after flip (have a property like no-content, which, if true, will show stamped alt content instead (but the real template needs to exist still so future wise it will work...)
• [x] make sure that if multiple moves are applied quickly that the content-before-flip is still shown (we shouldn't clear out the info map in animator each time prepare() is called) (this is visible in memroy cards flipping back over)
• [x] consider renaming old-front to no-content
• [x] what happens when the no-content item that's cloned is a custom element? Does state drop out?
• [x] when you first create a new game from create-games, the first render fails (either completely, or in memory, the cards aren't rotated correctly)
• [x] test cards moving from a fan to a stack
• [x] If the card is not flipped up during prepare, don't bother cloning the content (performance). Alternatively, we only need to copy over the content once since it can't change (wait, that's not true, there could be dynamic values that change)
• [x] Document the patterns to use oldFront to signal the special behavior (as well as ids, LastSeenIds)
• [x] cards that flip as they move between stacks should work
• [ ] cards shouldn't double flip on first state set (e.g. debug animations)
• [x] verify that memory animates as expected
• [x] coordinator handless animating cards to stacks where it's only in IdsLastSeen
• [x] cards who go from a known location to being in a stack at unknown location (e.g. PolicyLen) works (be careful that a shuffle where the oldStack is same as newStack doesn't play that animation)
• [x] test hand animate
• [x] test moving from fan to stack animate
• [x] When cards move from fan rotation for all should animate to their new rotations instead of jumping. The ones AFTER the card that moves actually animate correctly The cards BEFORE don't. Due to databinding, the cards before ar eliterally the same cards, the cards after are actually different physical cards, which is causing the oddity somehow.
• [x] Add a way to toggle the layout styles of the to/from stack in animations
• [x] Cards that animate from one stack to another should appear to come from the right z-index in the containing card (this is really, really hard)
• [x] test shuffle within hand animate
• [x] coordinator.animate() handles cards going to visible stacks
• [x] put in spacers that animate out of existence
• [x] Flipping of cards in e.g. memory works currently... but the front side disappears when the state is updated because the new state does not contain that value. Hmmmm. Could have the global coordinator keep track of the inside element associated with that id, and if there isn't one provided, then just use the last one we've seen.
• [x] Time the work to animate to verify it's not too expensive (doesn't devtools console have some start/end timer thing?)
• [x] animation for card flip and card movement within collections should be a css var
• [x] Could be a bug where faux cards etc aren't actually instantiated by the time databinding returns... there is a way to force them to databind right then, though
• [x] Support items that are not the same cards technically flipping as they move through the air
• [x] Test that if a hidden hand order is shuffled it works
• [x] Test that if a VISIBLE hand order is shuffled it works
• [x] animate from known to hidden (be careful shuffle in same stack doesn't trigger)
• [x] animating cards aren't being removed from stack when done
• [x] also flip card when going from known stack to unknown stack
• [x] cards should get faux content
• [x] also animate opacity when animating to unknown stack
• [x] figure out why card is positioned in middle when flying from known to unknown
• [x] instead of calculating offsets from faux card, calculate from stack as before... and then add defaultMargin if it exists.
• [x] animate fro hidden to known
• [x] position should be from the second-to-last stack when coming from stack (the current one is us)
• [x] set properties about scale and opacity for the from condition
• [x] animation from unknown to known still starts too far to right of stack it's coming from
• [x] make sure shuffle in same stack doesn't trigger the animation
• [x] animate from hidden to hidden
• [x] animate shuffle (this is captured in another issue I think) (yes, number #379)
• [x] pacakge doc

[jkomoros]

There's a global animation coordinator element that all of the boardgame-card-collections work with. The game-view is responsible for creating it; all other boardgame-card-collections know that it exists because someone else created it.

Before setting the state, the coordinator calls Prepare(), then does databinding, then calls Animate().

When Prepare() is called, we go through each boardgame-card-collection, find all cards with Ids in it, and keep track of their:

• Top, left, width, height via getClientBoundingRect() (be careful to not cause layouts in this phase)
• Rotation of card (e.g. messiness rotation, rotation in the layout)
• Whether it's flipped or not.
• innerHTML of its front, just in case in the next state that card doesn't have one

Then the databinding happens, then animate() is called. We then basically do exactly the same thing as before, but setting transforms to unflip them all and animating to new locations--all via transforms.

If the boardgame-card-collection the card went to doesn't have an actual card, we create a stub to animate fade out and scale down as it flies, and when the animation is done we delete it.

At all times, be caerful that only one layout is done after databinding is done, so all of the many getClientBoundingRects only cause a single layout

[jkomoros]

Part of the problem we're having is that there are a lot of state transitions, and at each one we are measuring and setting transformations. In the memory case it's replacing a real animation with what is effectively a no-op animation.

Part of the problem is that to get the right getClientBoundingRect, we ahve to turn off transformations of the element to measure (thus breaking the animation), so even if we don't need to do a transformation in the end we've already messed with it.

There are two possible fixes: 1) Cards and components don't have any rotations applied (for example messy); that would be applied to the . 2) use offsetTop calculations, normalized for scroll (or up to common parent) and do the translate transformations based on that.

I think the second option is probably preferable, because I can imagine a lot of cases where the rotation really should be on the element itself. Also, we only need to walk up until we find the offsetParent they both share (but wait, we won't know that until after the animate() at which point the info is gone...)

[jkomoros]

We've now moved all of the remaining tasks to other bugs, so this is done!