[Feature Request] Global default(s) for expansion cap

[MaxLatey]

Description

It's super annoying, when exploring a graph or making a visualisation to have to individually set the expansion edge count for each node, and for each edge type. But particularly for each node.

In a large visualisations or explorations, this could mean dozens unnecessary clicks.

Preferred Solution

It would be great to have a global configuration setting which would replicate the functionality of the node-wise expansion, but apply it to all expansions in the current exploration / visualisation i.e. on double click rather than just expanding to 10 neighbours, the expansion would be to X no. of neighbours (X set at global config.), or X neighbours of type Y (X and Y set at global config.).

Additional Context

The requested feature is present in TigerGraph graph explore; its absence will be noticed by people coming with TigerGraph experience.

Related Issues

No related issues that I could find.

[kmcginnes]

Thanks @MaxLatey.

I like this idea. We could treat it essentially as a default value for expansions across the app.

What level would you consider appropriate for your use cases? I could imagine these options:

• Session level where you can set the default for your active session, but it returns to 10 once your session ends (refresh page, change connections, etc)
• Connection level where each connection can have its own expansion default value
• App level where the user has a single default expansion value for all connections

[MaxLatey]

Kris, thanks for the quick response! I was thinking per connection.

• Per session: too annoying when you refresh for some other reason then have to re-set it
• Per app/user: too annoying when you forget you set it high last time (say 100+) then double click for a different graph or different exploration and the expansion takes ages and you have to set it lower again

Kind of Goldilocks: per connection feels just about right.

[kmcginnes]

I tend to agree.

The only drawback I can think of is that with a typical Neptune setup 3 connections are created, one for each query language. They all connect to the same database. So it would be a bit painful in that scenario to apply the same default to each connection.

But that's only applicable if the user switches between these connections. I'm not sure how common that is.

[beebs-systap]

@kmcginnes The vast majority of Neptune customers use only one of the query languages with their cluster and rarely switch.

[MaxLatey]

Please note: compared to having a global cap, the how is definitely not as important. Maybe the answer is just: whichever is most straight-forward :-)

Many thanks for considering this feature.