Move block animation code to a new file and rebuild #1787
Conversation
There was a problem hiding this comment.
I think this is a step in the right direction to support scratch-blocks use case, but I want to make sure we think about whether this makes animations harder in the future. e.g. if we introduce this class here, do we have to keep it and the resulting api (disconnectUiStop, disconnectUiEffect, connectionUiEffect etc.) forever? Looks like everything is now marked package or private so maybe not? Were all these methods package and private before? e.g. is Blockly games calling any of them such that we're going to have to change them to public :) Let me know if those thoughts aren't coherent... haven't quite hit the right balance of coffee/food/water post redeye :)
|
I don't think this adds anything new, because everything is package or private. |
| var svgGroup = block.getSvgRoot(); | ||
| workspace.getAudioManager().play('delete'); | ||
|
|
||
| var xy = workspace.getSvgXY(svgGroup); |
There was a problem hiding this comment.
how come you can drop the type annotation? I guess I don't quite know why it was needed before.
There was a problem hiding this comment.
It was a cast before (from the perspective of closure-compiler). getSvgRoot is already annotated to return the correct type.
It might eventually need a cast inside it, but that's out of scope for right now. It gives warnings, not errors.
The basics
The details
Resolves
None
Proposed Changes
Move code for block animations to a new file.
Reason for Changes
Simplify merges with scratch-blocks. Generally make it easier for forks to override our animations without merge problems.
Test Coverage
Rebuilt, then checked that dispose, connection, and disconnect animations all play properly in the playground (uncompressed) and code demo (compressed).
Additional Information
See scratchfoundation/scratch-blocks#1449