Slowly but steadily I’m making progress and one of the key driver is the quality of the observable and d3 projects. Good code is like good wine, its value increase with time and I’m a lucky guy to share it with a generous and supportive team. You make praising easy. Thank you.
Ok, so now that I can make some (reactive) notebooks and integrate them cell by cell or as a whole in an external website, I’m faced with doing some theming.
In https://observablehq.com/@observablehq/downloading-and-embedding-notebooks you suggest tachyons as a great css framework and I would like to give it a try. But then when I export a whole notebook, many of the exported DOM elements have a predefined class that I certainly could use for theming but my question is how do I leverage the tachyons’s atomic classes power ?
Is there a way, or I should rather say, how do you go about adding classes to the already defined .observablehq--{cellname, key, function, inspect, ...} DOM elements ?
…But is that where I should also add my tachyons classes. If so, It means I should write my own inspector, as also suggested by Jeremy
Is that correct ?
Edit: A few minutes later
Looks like I should go further into Inspector.into(container)'s documentation.
Edit: After reading the Observable Runtime documentation
I’m starting to understand that an Observable notebook is like a spreadsheet interface where you can put JavaScript, or MarkDown in the cells. While the Observable Runtime is like a set of JavaScript macros to generate programmatically the spreadsheet. Hence, it’s what is used to reproduce the Observable notebook in an Observable module. Please correct me, if I’m incorrect !
If not, I’m starting to wonder how close is Observable to React.js ? But maybe the answer is for my next edit as I was planning to do React’s main tutorial today
Solution: After reading the Inspector/index.js code
I get that this is the place were I should add the tachyons’ classes as I wish. Notabene: Since I’ll have a customized class Inspector I’ll need to change the imports from the example:
import {Runtime, Inspector} from "https://cdn.jsdelivr.net/npm/@observablehq/runtime@4/dist/runtime.js";
to something like
import Runtime from "https://cdn.jsdelivr.net/npm/@observablehq/runtime@4/dist/runtime.js";
import Inspector from "/path/to/modified/index.js";
Observable’s inspector is written with very particular, prefixed classes which don’t line up with tachyons. The reason for this is that we intend for the inspector to behave like a browser’s developer tools: it should be largely unaffected by absolutely anything that someone does in a notebook. If you create a red class in your notebook content, for example, it should always affect your notebook content but never accidentally modify the inspector, which should look and behave the same way always.
The inspector’s own stylesheet is included in its repo, though, if you’d like to modify it. It’s a pretty nitty-gritty detail, but if you do want to reuse tachyon’s values, we use the –preserve-variables option of tachyons-cli so that its variables are usable everywhere – so elsewhere on the page we can say var(--red) as a value for a CSS property, and it takes the exact same value as it would if we used the .red or .bg-red class.
If not, I’m starting to wonder how close is Observable to React.js
I wrote a bit about the relationship in this previous thread: Curiosity: How does the Observable web page render to React components? - #2 by tom - the business parts of the Observable application are written with React, but the special notebook interface & behavior is low-level code (open sourced as observablehq/runtime), and the concept of ‘reactivity’ is implemented as an invisible part of the language rather than as a library that you include.