Bounds for interactivity

[thomasp85]

This issue is a discussion ground for what we think of regarding interactivity to sharpen our thoughts before we begin to design it. Interactivity is a spectrum and we are not aiming at the freedom D3 brings - but where are we aiming then?

I have strong feelings around the proper "grammar" api when it comes to interactivity but I'm not sure ggsql is for that (it does require an element of interpreted programming language to really work). As I write this I think for ggsql there are 3 main interactive areas to address which will cover the magic 80% of use cases (or more):

• Filtering
• Hovering tooltips
• Zoom and pan

These are all in the bucket of cookie-cutter interactivity that I dread but realistically it is perhaps what we should aim for

[thomasp85]

Sort of related to this. There may be different modes of interactivity when embedded.

• Constant database access. Every filter etc is a new db query
• Fetch full layer data to local DuckDB and query that (but still on the server)
• Fetch full layer data end embed in wasm process

All three have merits and should be able to be switched between

[simonaubertbd]

Hello,

My two cents here :
-Tooltip is probably the most urgent here since it allows to carry a lot of information that would overload the viz itself.

-I love the idea of several modes. It's the better way to deal with all the cases : big databases, files, etc. Because you don't want to load 2 billions rows on your machine and you don't want either to query a csv every time

Best regards,

Simon