"Extra" objectHighlighted event emitted during updateDate...?

[aSqrd-eSqrd]

I'm chasing a bit of logic to allow me to close the details panel in vizceral-example and yet keep the selected node highlighted without the detail panel popping back out on the next update/render cycle that propagates through.

I thought I had found the perfect existing signal to simple add on as a second argument to be emitted whenever the objectHighlighted event is emitted, which was force found in the highlightedObject function found in trafficGraph.js.

But there is one hick-up. When the updating cycle is going and there is new traffic data call stack works out to be:

updateData (vizceral.js) -> updateGraph (vizceral.js) -> setState (trafficGraph.js) -> emitObjectUpdated (trafficGraph.js) -> which emits the objectHighlighted event

As these functions return the setState call completes and the next piece of updateGraph executes:

updateData (vizceral.js) -> updateGraph (vizceral.js) -> validateLayout (trafficGraph.js) -> updateView (trafficGraph.js) -> highlightedObject (trafficGraph.js) -> which emits the objectHighlighted event for the 2nd time since updateGraph was called.

It is that the objectHighlighted event is fired twice that is causing me trouble. The highlightedObject function always So my questions is,

• Why does the second "path" to emitting the objectHighlighed event in updateGraph (i.e. the validateLayout call), call the highlightedObject function since setState seems to have already taken care of that?

Hmmm, now that I've read my own question I think it isn't the best question. This one is probably the better question.

• Why does the setState of trafficGraph.js even need to emit the objectHighlighed event? So far, I haven't found a situation where the state of a "graph" object is more than the traffic data, e.g. nodes, connections, render, layout, updated, etc. and possibly an entryNode key.

Or should I do something totally different. Chasing this rabbit trail stems from trying to be able to single-click a node in the vizceral-example to open the detail panel, then close the detail panel but keeping the clicked node highlighted. This works fine until the traffic data updates and ultimately causes the objectHighlighted events to fire in vizceral.js.

Thoughts? Suggestions?

[jrsquared]

How we have it setup, if someone has deep linked into a view of vizceral, vizceral tells the container which object is highlighted. We have a very tight coupling of the surrounding chrome (detail panel) and the graph itself (as is seen in the vizceral-example), and we hook into the objectHighlighted event to update the details on the contextual panel as the details change. I'm not saying this is a great pattern (or even a good one), it's just the reason it is the way it is.

A possible 'fix' without needing to modify vizceral: Store the highlighted node in a state outside of vizceral, then if you get the same objectHighlighted event for the same node, and the panel is closed, ignore the update event?

Or a fix would probably be to rethink the way it works in vizceral, maybe two different events? One event for when it's a new object that is highlighted, and one event for when the currently highlighted one gets updated?

[aSqrd-eSqrd]

Ummm, you lost me. You are saying that the "...deep linked into a view... tells the container..." of your real running setup is a close match to the vizceral-example's connection to vizceral? By "deep link" are you referring to how the callback executed by the emission of the objectHighlighted event propagates all the way down from vizceral-example?

So what happens on your real running setup if you do the following steps: (1) you single-click (select) a service in the region view, (2) close the details panel using the 'X', not by deselecting or selecting another service, (3) with the selected service still highlighted your data updates.

For me (with my top-level interface being based on vizceral-example), the details panel will reappear.

As always, thank you for the help and all the work you've put into vizceral and managing its OSS repos.

[jrsquared]

Apologies for being unclear.

In our running vizceral app, you can navigate to vizceral/nodename?highlighted=foo to highlight an object and show the details panel for that object. If we close the details panel, it de-highlights the object. We have a tight coupling between the highlighted object and the details panel so we never had to think about separating the logic.

Does that make more sense?

[aSqrd-eSqrd]

Ok, that's the difference. Using the public open-source vizceral with vizceral-example (and vizceral-react), when the details panel closes it doesn't un-highlight the node. The detail panel closes and that is all.

For clarity/context, what I'm typically doing when this situation comes up is... Something has happened and drawn my attention to a node at the region zoom level. I click on it to get the details, but not to zoom in, i.e., vizceral/regionname?highlighted=foo via single-click, not direct URL setting (not that it matters as it doesn't effect the behavior using the open-source code). I take a look through the details and then close the details panel. Here is where what I want and what happens diverge.

What I want is to just watch that node and its connected peers to see what happens as time keeps on ticking along. If it has been a while and/or I've forgotten, I want to click on the highlighted node again so I can see the details panel again. What actually happens is that on every update of the traffic data the details panel reappears.

I want to see the region view as clearly as I can by not giving up any space for the details panel while still keeping the highlighting.

So just to for my own peace of mind. When you close the details panel at the vizceral/regionname?highlighted=foo zoom level, the selected node is un-highlighed, right? There is not a means or wasn't supposed to be a means for highlighting a node and its connected peers via click, only hover?

[jrsquared]

Correct, that is the current behavior. I could see why this would not be desired and would definitely welcome a PR to change the behavior.