Curiosity: How does the Observable web page render to React components?

Feedback
1

Looking at the list of open source code used for the Observable web page (https://beta.observablehq.com/open-source), there is quite a few React and React-related modules. This leads me to conclude that the Observable web page is made using React.

This leads me to my core question - does the Observable webpage also use React to render visualizations?

I ask because visualizations in the notebooks I’ve seen returns various HTML Elements and not React Components. E.g. the return value from the chart code in Mike Bostock’s Seattle Weather Notebook is an SVGSVGElement. This is a standardized reference for manipulating SVG elements (https://developer.mozilla.org/en-US/docs/Web/API/SVGSVGElement), but not a valid React child.

This means that, if Observable does indeed use React to render visualizations, a conversion from various HTML elements takes place. What is your strategy for doing this?
Do you use a generic React component that exposes said component’s DOM node akin to ReactDOM.findDOMNode?
Do you use a fake DOM akin to react-faux-dom, updating a generic React component’s props, triggering the component to render?
Or perhaps you use a different strategy?

I am really curious about this, so I hope you can shed some light on this for me, even if just briefly :slight_smile:

2

Hey Matthias,

Yep, Observable’s user interface heavily uses React - it’s a lovely way to build applications. But React isn’t involved in rendering visualization output in any way: there are essentially two levels to the application:

  • The top frame, beta.observablehq.com, which is where you edit code, create notebooks, and so on. This uses React, CodeMirror, lots of good modern JavaScript flavors
  • The worker frame, matthiasneilsen.static.observableusercontent.com, which doesn’t use React, or for that matter, any other application framework: it’s a very simple JavaScript application that receives events, reacts to them, and manages the output of the notebook.

We do want to improve support for notebooks that themselves use React + JSX - by transpiling JSX, automatically calling ReactDOM.render when a cell value is a react component, and/or some other perks, but by default, we want notebook output to be as pure and simple “JavaScript creating a webpage” as possible, so there isn’t any chance that overeager magic makes notebooks harder to debug or understand. Plus, the worker that renders notebook output is dense, but not complex enough to justify running another React application within the existing React application.

4 Likes
3

Thanks for your reply, Tom! And for gratifying my curiosity :slight_smile:
Apologies for the late reply - I’ve been travelling most of the week…

Your future plans regarding JSX sounds intriguing, yet I understand that you wan’t to keep notebooks plain - it’s a great feature that Observable notebooks are explorable and manipulable using just JavaScript.
I look forward to following the continued development of Observable!

4

Great work on Observable! Very exciting to see you all moving forward and innovating so fast!

Just wanted to +1 on this: I’m really looking forward to “improve support for notebooks that themselves use React + JSX” I think these improvements would lead to an even more rapid adoption of Observable due to the massive community of React devs looking for a great way to collaborate on code and design.