You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in JS land, this library tries to follow the same API to trigger plotting as it uses on the JVM. i.e. For a plot, accept some "context" via a given and plot the chart as a side effect.
If you're driving this in JVM-land, this makes sense. plotting is a side effect whether you're putting it on a screen or printing to a file. As part of UI (in say a browser), the api wants you to feed the chart a div (as a given) and then plots immediately inside it. There are some issues with that around timing, but it can be made to work and I'm using it quite a bit. It doesn't really make sense though.
Further, the current API doesn't acknowledge the need to respond to chart interactions or have any potential to update driven by other UI or state changes. The "stuff it in a div and forget" paradigm assumes that we'll never want to update chart data, but will always redraw from scratch.
Where this idea starts to get really attractive, is that responding to or propagating signals from/into the chart is nothing more or less than JS promises. because vegas api is all callback based.
That should mean in turn, that publishing strongly typed helper libraries for, say Laminar and Calico... actually doesn't look like it would be too hard.
Have a method (or a bunch of methods) that returns a vega view for the constructed chart. That could be neatly wrapped into your scalajs framework of choice (e.g. calico, laminar, raw JS)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently in JS land, this library tries to follow the same API to trigger plotting as it uses on the JVM. i.e. For a plot, accept some "context" via a given and plot the chart as a side effect.
dedav4s/core/jvm/src/main/scala/viz/PlatformShow.scala
Line 21 in f6bff4b
If you're driving this in JVM-land, this makes sense. plotting is a side effect whether you're putting it on a screen or printing to a file. As part of UI (in say a browser), the api wants you to feed the chart a div (as a given) and then plots immediately inside it. There are some issues with that around timing, but it can be made to work and I'm using it quite a bit. It doesn't really make sense though.
Further, the current API doesn't acknowledge the need to respond to chart interactions or have any potential to update driven by other UI or state changes. The "stuff it in a div and forget" paradigm assumes that we'll never want to update chart data, but will always redraw from scratch.
Vega has a great solution to these problems;
https://vega.github.io/vega/docs/api/view/
Scalably typed facades, get really complex for vega... but a little handcrafted one that wrapped a small % of it's API, could actually be very effective. It's started here;
https://github.com/Quafadas/dedav4s/blob/main/core/js/src/main/scala/viz/vega/facades/VegaView.scala
Where this idea starts to get really attractive, is that responding to or propagating signals from/into the chart is nothing more or less than JS promises. because vegas api is all callback based.
That should mean in turn, that publishing strongly typed helper libraries for, say Laminar and Calico... actually doesn't look like it would be too hard.
Sketch ;
dedav4s/core/js/src/main/scala/viz/PlatformShow.scala
Line 26 in f6bff4b
https://vega.github.io/vega/docs/api/view/#view_data
Beta Was this translation helpful? Give feedback.
All reactions