tophtucker
Joined 16 years ago
Joined 16 years ago
Since there was a lot of interest in this thread, Mike added a page to the docs with an ECharts example: https://observablehq.com/framework/lib/echarts
There are two pieces of that example code specific to Framework: the html`` tagged template literal creates a DOM element (see https://github.com/observablehq/htl, also usable outside Framework), and the display function inserts it into the document above the code block (see https://observablehq.com/framework/javascript/display). Note that, whereas Observable Plot takes an options object and returns a DOM element, ECharts instead takes a DOM element and mutates it — but in general they should be equally easy to use in Framework.
Like Plot (and Vega-Lite, another great option), ECharts is also now one of Framework’s built-in “recommended libraries” (see https://observablehq.com/framework/javascript/imports#implic...), meaning that if you reference `echarts` Framework will lazy-load it for you. Adding that was a two-line diff: https://github.com/observablehq/framework/pull/811/files#dif.... But I wanna emphasize that Framework doesn’t have to explicitly “support” a given library for you to use it. “Supporting” in this case just means the convenience of saving you a one-line import statement. But don’t wait for our blessing!! Use whatever.
When I first started working at Observable I explained reactivity to my now-wife as “when one thing changes, other things that depend on it update automatically.” She was at an asset management job at the time working in Excel all day, which of course is also reactive in that sense. But she interpreted my statement differently; she said “Oh that’s terrible! If a number changes I want to know.” E.g. if the estimated budget for a project had ballooned, she wanted to hear about it so she could check why, ask other people about it, try to contain the damage, warn others, make other decisions differently, etc. “Automatic” would be harmful, like in your Go example. She was also thinking about coarser-grained data than I was — a single very impactful number, not a stream of mousemoves or pageloads or ad clicks or whatever.
1. It’s just JavaScript so you can fetch stuff dynamically too (see https://observablehq.com/framework/lib/duckdb). But yeah, only client-side. (Though see https://github.com/observablehq/framework/issues/234.)
2. Sure, it’s all open source, I bet you could make that work. Or `yarn deploy` to Observable and configure sharing there (though it wouldn’t let you charge others).
3. Yup. Which is part of the appeal of model of running data loaders at build time: you can query some private data and viewers would only be able to see the final result set. (The lack of something like this has always been a huge problem for Observable notebooks. You’d make some great query-driven charts and then couldn’t make it public without some awkward manual dance of downloading and re-uploading a file to a fork of the notebook.)
4. I wish I knew! It’s being tracked here https://github.com/observablehq/plot/issues/1711. Lately there’s been a lot more work on Framework naturally but now that that’s out…
5. Another good question. We’re definitely interested in tailoring it more to this sort of use case but lots is TBD!
It’s kinda cool to think about the shearing layers of reactivity. Reactivity is what originally drew me to Observable. But the way notebooks have to be recomputed live for every viewer every time makes them feel silly for, like, a BI dashboard that changes daily at most. Like they only have one pace layer. Like they’re trying so hard to be _live_ that they can’t be _fast_! Idk. I guess even a chalkboard is reactive on the timescale of “someone noticing some information and telling it to someone who writes it down” lol.
What I personally like most about Plot is that it’s purely JavaScript (/ TypeScript); it doesn’t try to be serializable as JSON and portable to Python etc. So whereas Vega-Lite has to have its own expression language (https://vega.github.io/vega/docs/expressions/):
"transform": {
"calculate": [{"field": "b2","expr": "2*datum.b"}],
"filter": "datum.b2 > 60"
},
…in Plot you’d use plain JavaScript: y: d => 2 * d.b,
filter: d => d.b2 > 60
…which I find easier and more powerful. (But I don’t need VL’s portability; others may.)Mike Freeman made a helper function that adds that sort of animation (data gradually coming in) using D3 atop Plot: https://observablehq.com/@mkfreeman/plot-animation
You could upvote this incremental rendering issue: https://github.com/observablehq/plot/issues/328
Or this one for adding a “time channel” to do data-driven animation (for which there’s an old draft PR): https://github.com/observablehq/plot/issues/166
- rich tooltips (coming soon in Plot)
- interactive pan & zoom
- multiple panels with shared scales? (like for marginal distributions; you can combine with HTML of course, but it’s not easy/built-in in Plot)
One bizarre workaround right now is to abuse the geographic projections: https://observablehq.com/@observablehq/pie-to-donut-chart
In general, you can do a lot of customization, including plugins (though that’s not well-documented yet), so you could make it work… see https://observablehq.com/@fil/radial-transform, https://observablehq.com/@observablehq/plot-radial-line for other approaches to hacking radial stuff into Plot.
You can do Cartesian tree diagrams in Plot, e.g. https://observablehq.com/@observablehq/plot-tree-flare, https://observablehq.com/@observablehq/plot-custom-tree-layo...
If you want to make a chord diagram like that “Müsli Ingredient Network” example, you could try one of these D3 examples: https://observablehq.com/@d3/chord-diagram, https://observablehq.com/@d3/hierarchical-edge-bundling/2