Closed danielabar closed 8 years ago
Don't forget code-designing and testing for cleanly halting an animation-in-progress when a countering one has been initiated at its midst. E.g. user selects node, then unselects it, while it's still animating (or other way around, or a sequence of select/unselect/select). I guess each animation library has its own idiomatic way for handling that. This would be a huge confirmation for GSAP :)
I have the feature working, now thinking about how to unit test a custom element including dom manipulation.
Had a look at this post, but doesn't seem to load the template.
May need the Aurelia equivalent of this library to compile the aurelia template and make it available to the test.
Maybe get advice in the gitter channel...
For the testing, keep an eye on this issue
Regarding or regardless of automated testing, if you were to slow down the animation for a test, and then:
Key test case ― does it leave the node in visual limbo? does it skew its state for the next hover effect or does the next hover happen equally well? Just typical pitfalls with animations...
:smiley_cat:
Actually the animation is triggerred on click, not hover. I thought that's how it used to work but maybe I'm mistaken. Basically user can click any number of nodes to select them, and the border animates in so user can see which ones they've selected. Clicking again deselects and runs the animation in reverse to remove the border.
Found another blog post on unit testing custom elements with dom manipulation
I had started this before as part of #31 but turned out to be a little more complicated due to data binding via Aurelia vs GSAP modifying the values, so it required a little more thought.
Also take this opportunity to determine whether animation, or at least the expected final state of a transition can be unit tested. Again, during #31 I had noticed it was relatively easy for the animation to be broken, for example if an invalid selector was passed to
TweenMax
. And the only way to confirm was via manual navigation of the app. This won't scale as it grows, and could make it difficult to have multiple contributors, so it would be good to have automated testing for this.The karma html to js preprocessor may be helpful for this.