There’s a similar principle of congruence in information visualization, stated in Animated Transitions in Statistical Data Graphics by Heer & Robertson as: “Maintain valid data graphics during transitions. To ensure viewers’
mental models are congruent with the semantics of the data, we
suggest that, as much as possible, intermediate interpolation states
remain valid data graphics.” https://idl.uw.edu/papers/animated-transitions
Thank you. I don’t want to commit to a public timeline on the web editor yet, but rest assured it is a top priority, and we also value the convenience of a web editor, instant collaboration, and community!
We’re interested in adding a TypeScript cell mode, probably first with type stripping rather than validating types. I was hoping for a pure JavaScript implementation; maybe we’ll try https://github.com/bloomberg/ts-blank-space? I’ve also been looking at https://github.com/val-town/codemirror-ts for the editor, but it’s a lot of machinery.
but this approach stalled because it doesn’t implement validation of TypeScript: the TypeScript annotations are simply ignored. I felt this defeats the point of using TypeScript. We probably need to use tsc instead of esbuild to get type checking. Hints welcome!
In what way are these free open-source tools “locked-in” to Observable? Observable Plot is a vanilla JavaScript library that is released under the ISC license and can be used with any style of web development (e.g., React, Svelte, whatever). And likewise Observable Framework is released under the ISC license and you’re able to self-host projects anywhere and develop locally?
Thanks for the feedback. We have a PR open to make it easier to register new interpreters (without needing to fallback to .sh or .exe); it’ll let you specify the interpreter associated with a given file extension (e.g., .kts for Kotlin). https://github.com/observablehq/framework/pull/935
As for inputs-driving-data-loaders, that does go against the grain a bit since Framework favors static data snapshots so that the built site is self-contained and performant. But a technique that works well is to generate Parquet files in data loaders representing the superset of data that you want to interact with, and then using DuckDB/SQL in the client to extract the subset you want to visualize. This tends to perform well, though obviously it’s dependent on the size of the superset you want to interact with.
We’re planning to allow changing the default options for blocks (either per-page in front matter or across an entire project using the project config); you could then make `js run=false` the default and `js run` to opt-in to live code as you wish. But we chose to make live code the default since that’s our primary use case.
I still haven’t quite figured out how to make D3’s implementation robust, though. Volodymyr Agafonkin’s robust-predicated would probably help…
https://github.com/mourner/robust-predicates
That “More from Observable creators” is just a standard footer we put across the site for signed-out users to showcase community content across Observable. It’s not part of the notebook. You can ignore everything below the “Appendix”.
See Leland Wilkinson’s The Grammar of Graphics. He describes the difference between a chart typology (a fixed set of chart types with a fixed set of configuration options) and a grammar of graphics (a set of orthogonal primitives that can be composed in arbitrary ways).
If you’re developing the models locally, perhaps Framework’s preview server could work: it watches local files and automatically pushes updates to the browser when files change. This enables reactive updates for data loaders, but also works with static files. So you could visualize the models as they are being generated — meaning as some external process writes local files.
But in general the use case we’re targeting is a shared data app, dashboard, or report. Not something just for you individually, or something ephemeral (that you look at in real-time during training). For example, Framework would work well for sharing a report or dashboard evaluating the performance of the latest models you’ve built with your team.
Right, conceptually it’s static files, but we could develop a hybrid approach where the server does additional data processing on-demand. We already offer access control, but we could also serve different data snapshots to different users, or even filter the data snapshots based on the user. It still has to be fast, though.
We generally recommend stacked bar charts over pie and donut charts, so we haven’t prioritized those. But you can already implement them using custom marks, and there’s even a hacky way of doing them using Plot’s map projection system.
I don’t understand your comment about the “D3 example.” If you’re looking for Plot examples, you can find them linked from the Plot documentation and the gallery:
Plot is designed to be extended with JavaScript (rather than a non-JavaScript DSL such as Vega-Lite), such as for custom marks and data transforms. So you might occasionally see other libraries being used together with Plot.
We plan on downloading the imported libraries during build so that they are self-hosted, so it’s effectively another way to install them without having to run `npm install`. We also plan on supporting importing libraries from node_modules. And you can already import local modules so you can install libraries by manually downloading them, too.