What is the idiomatic way to turn off selective animations?

GoJS
1

I’m curious what the intended way is to disable specific animations for something like subgraphs expanding/closing?

I found this snippet in the AnimationManager api, but unless I misunderstand how the animationReasons api is supposed to work, this doesn’t seem like it would do what it says it does.

myDiagram.animationManager.canStart = function(reason) {
    if (this.animationReasons.contains("Expand Tree")) return false;
    return true;
}

I was under the impression that animationReasons was basically an immutable enum property of animation manager that enumerates all possible reasons, so wouldn’t it always contain “Expand Tree”?

I tried to write something like both this (both in the same canStart override):

var disabledAnimations = ["Expand SubGraph", "Collapse SubGraph"];
if (disabledAnimations.includes(reason)) 
    return false;
return true;

and

if(this.animationReasons.contains("Expand SubGraph") || this.animationReasons.contains("Collapse SubGraph"))
    return false;
return true;

and neither seems to create the behavior I want (disabling the “slide in” animation on subgraph expand/collapse).

I can just disable the animation manager entirely and then I see the expand/collapse instantly like I’d like, but I lose the zoomToRect animations that I’d like to keep.

Am I misunderstanding the way to disable animations?

2

The collection might be immutable to you, but its values are changing frequently as the diagram or model changes state.

Your second code snippet looks correct, so I cannot explain why that did not work for you. Can you confirm that it is returning false at the times you expect?

3

It does not, which may have been why I suspected part of that snippet was wrong. As far as I can tell animationReasons is always empty.

‘reason’ is set correctly though, I can see “Expand SubGraph” and “Model”/“Layout” at what seem to be appropriate times.

The only relevant (I think) setting on my diagram that’s on is “animationManager.isInitial”: false

In my first snippet (where I test the reason against my own list) that returned false when I would expect, but seems to not be the right paradigm.

4

Hmmm. Maybe I’m wrong. We’ll investigate.

5

OK, the documentation is wrong. Sorry about the confusion.

When we greatly improved the support for general animation in version 2.1, we exposed and modified some of the long-existing implementation, such as AnimationManager.canStart, as well as adding some new stuff, such as AnimationTrigger.

The animationReasons property should not have been documented. We’ll remove it for the next release. Your canStart override can be pretty simple:

myDiagram.animationManager.canStart = function(reason) {
    return (reason !== "Expand SubGraph" && reason !== "Collapse SubGraph");
}

That should work in all 2.1 releases: past, current, and future.

6

Okay so that looks pretty similar to the first attempt I had at it, but that hasn’t worked either.

I don’t know for sure, but when I breakpoint on that function I see it called once with “Collapse”/“Expand”, and then again afterwards with “Layout”.

If I leave layout out of that function (so it allows the animation for that reason), then I see the expand collapse and zoom animations both still play.

If I add Layout, so that it suppresses both expand/collapse and layout reasons, then I lose both the expand/collapse and zoom animations, like I had set animationManager.isEnabled to false.

Do I need to change something with the way I’m triggering the events (zoom/layout/expand/etc) to ‘separate’ those events more? The way I’m triggering everything doesn’t leave enough granularity to separate the animations or something?

7

It is quite normal for a collapse or expand of a group or a tree to cause a layout to happen. Checking for a “Layout” reason should prevent the layout animation from happening. But if the result of a transaction both moves/hides/shows nodes and scrolls too, I’m not sure it how to control some node animations but not others.

8

I’m doing the layout of the diagram manually with an invalidateLayout(), because I am switching categories when the expand happens, and the new group subgraph isn’t laid out correctly otherwise, so I know that’s the source of the second ‘Layout’.

Actually, I think that’s the issue, now that I think about it, because right now the trigger order is:

doubleClick triggers expand and zoom -> expandedChange listener triggers category change and layout.

The zoom is happening before the layout has totally redrawn the nodes, so the zoom’s animation is getting halted by the layout I bet.

I think I’m going to have to reorder the way these events all get triggered and rethink my group templates to handle it.

9

The hard part is going to be that I have two ways of “expanding” the subgraph groups, one that zooms and one that doesn’t, and I’m not sure how to figure out in the ExpandedChanged listener which was which, so I know whether to zoom or not.

10

Ah, I didn’t know about the category/template change. Yes, that makes things more complicated, as does the different circumstances of doing an expansion. I think you are experienced enough to make some progress, and you can ask more questions when you have them.

Sorry again for the confusion with the documentation. That didn’t help you.

11

Haha, no problem.

Thanks again for your guy’s support.
It makes this product incredible to work with, and I’m sure all of us who use it appreciate it immensely!